An Evening with… Agile MetricsArkho Innova Meetup Series

• Un espacio para compartir experiencias y conocimiento

• Un espacio para hacer relaciones entre equipos con intereses afines

• Un espacio para pasarla bien

Gracias por su asistencia!!!

1. Hacía el contexto ágil 2. Estado del arte ágil 3. Definiciones básicas sobre las métricas 4. Mapa de métricas 5. Las métricas en el contexto ágil

Nuestro viaje para hoy…

Hacía el contexto ágil

¿Qué busca el método ágil?Visibilidad

AdaptabilidadValorparaelnegocio

Riesgo

Tiempo

¿Qué busca el método ágil?¿Qué busca el método ágil?

Principios ágiles1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

http://agilemanifesto.org/iso/es/principles.html

Estado del arte

Estado del arte

https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf

Sobre las métricas

Definiciones básicas

CC. David Nicolette

Es un estándar para medir y evaluar algo

Una medida es una cantidad, una proporción, o una comparación cualitativa de algún tipo

¿Qué

es?

Informacional Diagnóstico Motivacional

¿Qué esta ocurriendo? Identificar áreas para mejoramiento

Influencia el comportamientoTipos

Indi

cado

res

Leading

Tendencias o eventos futuros

Lagging

Información acerca del output de procesos

Mapa de métricas

Backlog health1. En Agile los requerimientos son progresivamente

identificados y detallados 2. Backlog health se refiere a la creación de un

backlog donde la relación entre trabajo ya detallado y trabajo futuro, es adecuada. Una medida común es 3 iteraciones futuras en detalle.

3. Usar técnicas de segregación con Epics y Stories 4. Usar el principio INVEST (Independent,

Negotiable, Valuable, Estimable, Small, Testable)

Precauciones 1. Indicadores comunes de problemas de Backlog

Health: • Stories son constantemente redefinidas • Stories rechazadas durante el review • Metas no completas del equipo, usualmente

relacionadas con Stories no descubiertas • Criterios de aceptación no determinados

Feature Progression1. Describe el estado de la iniciativa, característica

por característica en un punto del tiempo 2. Las épicas son útiles para agrupar grandes

volúmenes de características relacionadas 3. Facilita la visualización de épicas a tiempo o

atrasadas 4. Se requiere: agrupación de características, qué

tanto de la característica se ha planeado construir y qué tanto fue construido hasta el punto de análisis

5. Puede calcularse para el Sprint o el Release

Precauciones 1. No es un sustituto para una conversación: El

propósito es proveer visibilidad y un contexto para la conversación

2. Establecer un umbral adecuado para análisis del progreso

Unplanned Work1. Trabajo no planificado que hace parte de la unidad de trabajo 2. Es un tradeoff: con el trabajo planeado 3. Se suele creer que Agile puede tratar mágicamente con el

trabajo no planificado 4. Es crítico analizar la tendencia: ¿Qué tanto trabajo no

planificado se genera?, ¿Porqué? ,¿Cómo se puede reducir? 5. Un tablero visible: tamaño del backlog, esfuerzo involucrado

en consumirlo 6. Recomendado utilizar 1st Order of Ignorance *

Precauciones 1. Contar con una definición DONE es crítico 2. La priorización del backlog no es opcional 3. El technical debt y las estrategias de automatización, pueden

generar eficiencias la hora de tratar con el trabajo no planificado

* https://www.rallydev.com/blog/agile/intermission-part-3-5-orders-ignorance

Burn up/Burn down1. Un gráfico que despliega el esfuerzo en el

tiempo 2. El gráfico de burnup, despliega el

esfuerzo del trabajo completado y también el esfuerzo planificado

3. Facilita determinar visualmente impedimentos, y oportunidades de mejora de la efectividad del equipo

Precauciones 1. Es crítico contar con una definición DONE 2. En el caso de modificaciones de la

cantidad de trabajo, es más útil un burnup que un burndown

3. Los gráficos son afectados de manera importante dependiendo de la unidad de cambio

Release Predictability1. Intenta resolver la pregunta ¿qué tanto valor se ha

generado al negocio? 2. ¿Qué tan predecible es el equipo, entregando los

compromisos? • Comparar el trabajo planificado para entregar vs.

el realmente entregado 3. ¿Qué tanto valor se generó en relación a lo

planificado? • Medición de KPIs del negocio • Satisfacción de clientes

4. Ayuda a priorizar el backlog, y facilita al equipo a estimar mejor el business value

Precauciones 1. Entregar más valor, no necesariamente es entregar

mayor cantidad

Average Velocity1. Tasa de entrega de valor 2. Una medida de que tanto backlog puede un

equipo consumir en un sprint 3. Sirve para tener un idea del tiempo

necesario para completar un backlog 4. Es un promedio de Story Points

completados durante los últimos Sprints

Precauciones 1. Es crítico contar con una definición DONE 2. La métrica varia de equipo a equipo 3. La métrica se afecta por impedimentos del

equipo

Work in progress

1. Se mide para limitar cuellos de botella en un flujo continuo

2. Es usualmente utilizado en Kanban 3. El WIP es fijado y concertado previamente por el

equipo 4. Cuando el límite se alcance, el equipo

colaborativamente trabaja para resolver el cuello de botella

Lead Cycle Time1. Lead Time. Inicia cuando el request es hecho y

finaliza cuando es completado (es lo que el cliente percibe). Es importante desde el punto de vista del negocio

2. Cycle Time. Inicia cuando el trabajo inicia y finaliza cuando es completado. Es el tiempo que el equipo puede influenciar

3. Ejemplos de incremento en los tiempos, indican oportunidades de mejora en los procesos

4. También proporciona visibilidad del cumplimiento de los niveles de servicio (SLA)

Precauciones 1. La métrica es bastante sensible a la captura

adecuada de la información 2. Puede usarse un Cumulative Flow, para ver la

tendencia del cycle y lead time en el tiempo *

* Los CFDs también pueden ser aplicados a tracking de defectos, estados de User Stories, etc. El propósito se mantiene similar: tendencia en el tiempo

Defect Slippage1. Mide la calidad global de una fase. Slippage se

define como la cantidad de defectos creados en una fase, pero determinados hasta la siguiente

2. Es un indicador de Speed To Value por que reduce la cantidad de tiempo disponible del equipo

3. Debe ser calculado como una tendencia en distintas fases. La tendencia positiva debe ir en decremento. El caso contrario indica que el equipo se mueve muy rápido y que el tiempo disponible para workload nuevo se reduce

Precauciones 1. No es un métrica de QA, es una métrica que

influencia todo el equipo, siendo éste responsable de la calidad del producto

Technical Debt1. Refleja el esfuerzo a más largo plazo, que hace más

difícil extender o mantener un sistema. Usualmente derivado de la aplicación deficiente de estándares y prácticas

2. Las herramientas de análisis estático como Sonar, son fundamentales en este caso

3. El Tech Debt debe ser visible para el equipo 4. Medir la tendencia del Tech Debt durante el

proyecto: documentar, priorizar, refactoring

Precauciones 1. El TechDebt no es necesariamente algo malo. No

necesariamente se buscan 0 issues 2. El Tech Debt no puede ser evitado: se requiere un

balance

Build Success Rate1. Tasa porcentual de builds success en el periodo 2. Facilita al equipo crear un flujo continuo de entrega 3. Se usa comúnmente en procesos de integración

continua

Precauciones 1. Es usual contar con automatización (Q1 y Q2 por

ejemplo), en los procesos de integración 2. Es usual agregar métricas de análisis estático de

código durante el proceso de build 3. No es un indicador del performance de un equipo. Los

Failed builds pueden estar relacionados con distintas causas

Coverage1. Mide el porcentaje de características, que en un periodo de

tiempo, cuentan con scripts de automatización de pruebas 2. La automatización al 100% no es eficiente: economía de la

calidad ágil 3. La automatización es crítica en la integración continua y

para la reducción de los ciclos de retroalimentación 4. Esta métrica es relevante para comprender el Speed to

Value del equipo 5. Una estrategia de calidad ágil en cuatro cuadrantes *,

permite automatizar en al menos Q1, Q2 y Q4 (security, code analysis, unit, web functional, tdd, atdd, etc.)

Precauciones 1. La automatización no es un silver bullet 2. La automatización tiene un costo de mantenimiento alto,

especialmente en casos de automatización UI (por ejemplo web functional testing)

* http://lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/

Customer & Team Satisfaction

1. Investigar la satisfacción del equipo y el cliente 2. El método más comúnmente usado son las encuestas 3. Una forma de respuesta común es usar respuestas en un

rango 1 (strongly disagree) a 5 (strongly agree)

Precauciones 1. Importante diferenciar en hechos concretos y no opiniones 2. Determinar similitudes en las respuestas 3. Compartir respuestas con otros y compartir acciones con

los participantes

http://wiseli.engr.wisc.edu/pi/0809_Tuckman_Team_Work_Survey.pdf

Speed to Value Right Outcome, Right Value Collaboration Continuos

Improvement Reliability

Average Velocity

Defect Slippage

Feature Progression

Release Predictability

Burn up/Burn down

Technical Debt

Backlog Health

Work in Progress

Lead and Cycle Time

Unplanned work

Satisfaction

Build Success Rate

Coverage

Feature Progression Release Predictability Customer Satisfaction

Coverage Backlog Health

Unplanned Work

Lead and Cycle Time Defect Slippage

Work in Progress Burnup/Burndown Team Satisfaction

Velocity Tech Debt

Build Success Rate

Externa

Interna

Coordinación Análisis

Las métricas en el contexto ágil

Las buenas métricas ágiles…

1. Reafirman los principios ágiles 2. Evalúan tendencias no el número mismo 3. Miden el resultado, no la acción 4. El objetivo no es el número, es la acción 5. Se mide todo lo necesario, nada mas que eso (son pocas y

generan valor al equipo) 6. Promueven los hábitos de mejoramiento continuo (Kaizen) 7. Ayudan a visualizar áreas que requieren mejoramientos 8. Se usan para iniciar conversaciones, no para reemplazarlas 9. Son simples de recolectar

An Evening with… Agile MetricsArkho Innova Meetup Series