Post on 22-Jan-2018
• 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…
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
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
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 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