Mtricas Agiles

Qu busca el mtodo gil?

Visibilid
ad

Valor para el
negocio

Adaptabilid
ad

Ries
go

Tiemp
o

Principios giles
1.

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 tardas 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
ms 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 ejecucin del trabajo.

6.

El mtodo ms eficiente y efectivo de comunicar informacin al equipo de desarrollo y entre sus miembros es la
conversacin 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 atencin continua a la excelencia tcnica y al buen diseo 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 diseos emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a continuacin ajustar y perfeccionar su
comportamiento en consecuencia.

Sobre las mtricas

Indicadores

Tipos

Qu es?

Lder

Definiciones bsicas

Es un estndar para medir y evaluar algo

Una medida es una cantidad, una proporcin, o una

comparacin cualitativa
de algn tipo

Informacional

Diagnstico

Qu esta
ocurriendo?

Identificar reas
para
mejoramiento

Leading
Tendencias o eventos
futuros

Motivacional
Influencia el
comportamiento

Lagging
Informacin acerca del
output de
procesos

La compaa, Scrum Management considera tres fondos de escala, o de zoom con

los que se puede medir el trabajo
Desarrollo y gestin de la solucin tcnica.
Gestin de proyecto.
Gestin de la organizacin.
En el primero se puede medir, por ejemplo, la proporcin de polimorfismo del
cdigo de un programa.
En el segundo, el porcentaje de trabajo realizado.
En el tercero, tambin por ejemplo, el nivel de satisfaccin laboral.

Mapa de mtricas

Backlog health
1.

2.

3.
4.

En Agile los requerimientos son

progresivamente identificados y
detallados
Backlog health se refiere a la
creacin de un backlog donde
la relacin entre trabajo ya
detallado y trabajo futuro, es
adecuada. Una medida comn
es 3 iteraciones futuras en
detalle.
Usar tcnicas de segregacin
con Epics y Stories
Usar el principio INVEST
(Independent, Negotiable,
Valuable, Estimable, Small,
Testable)

Precauciones
5. Indicadores comunes de
problemas de Backlog Health:
Stories son constantemente
redefinidas
Stories rechazadas durante el

Feature Progression
Describe el estado de la iniciativa,
caracterstica por caracterstica en
un punto del tiempo
2
Las picas son tiles para
.
agrupar grandes volmenes de
3
caractersticas relacionadas
.
Facilita la visualizacin de
4 picas a tiempo o atrasadas
.
Se requiere: agrupacin de
caractersticas, qu tanto de la
caracterstica se ha planeado
5 construir y qu tanto fue construido
hasta el punto de anlisis
.
Puede calcularse para el Sprint o el
Precaucion
Release
es
1 No es un sustituto para una
conversacin: El propsito es
.
proveer visibilidad y un contexto
para la conversacin
2
Establecer un umbral adecuado
.
para anlisis del progreso
1
.

Unplanned Work
1.
2.
3.

4.

5.
6.

Trabajo no planificado que hace parte de

la unidad de trabajo
Es un tradeoff: con el trabajo planeado
Se suele creer que Agile puede tratar
mgicamente con el trabajo no
planificado
Es crtico analizar la tendencia: Qu tanto
trabajo no planificado se genera?,
Porqu? ,Cmo se puede reducir?
Un tablero visible: tamao del backlog,
esfuerzo involucrado en consumirlo
Recomendado utilizar 1st Order of
Ignorance *

Precauciones
7. Contar con una definicin DONE es
crtico
8. La priorizacin del backlog no es opcional
9. El technical debt y las estrategias de
automatizacin, pueden generar eficiencias
la hora de tratar con el trabajo no
planificado

Burn up/Burn down

Un grfico que despliega el
esfuerzo en el tiempo
El grfico de burnup,
despliega el esfuerzo del
trabajo completado y
tambin el esfuerzo
planificado Facilita
determinar visualmente
impedimentos, y oportunidades
de mejora de la efectividad del
equipo
Precauciones

Es crtico contar con una

definicin DONE En el caso
de modificaciones de la
cantidad de trabajo, es ms
til un burnup que un
burndown
Los grficos son afectados
de manera importante
dependiendo de la unidad
de cambio

Release Predictability
1.

2.

3.

4.

Intenta resolver la pregunta qu

tanto valor se ha generado al
negocio?
Qu tan predecible es el equipo,
entregando los compromisos?
Comparar el trabajo planificado
para entregar vs. el realmente
entregado
Qu tanto valor se gener en
relacin a lo planificado?
Medicin de KPIs del
negocio
Satisfaccin de clientes
Ayuda a priorizar el backlog, y
facilita al equipo a estimar mejor el
business value

Precauciones
1. Entregar ms valor, no
necesariamente es entregar mayor
cantidad

Average Velocity
Tasa de entrega de valor
Una medida de que tanto
backlog puede un equipo
consumir en un sprint
Sirve para tener un idea
del tiempo necesario para
4
completar un backlog Es
.
un promedio de Story
Points
completados durante los
ltimos Sprints
Precaucion
es
1 Es crtico contar con una
. definicin DONE La mtrica
2 varia de equipo a equipo
. La mtrica se afecta por
3 impedimentos del equipo
.
1
.
2
.
3
.

Work in progress
1.
2.
3.
4.

Se mide para limitar cuellos de botella

en un flujo continuo
Es usualmente utilizado en Kanban
El WIP es fijado y concertado
previamente por el equipo
Cuando el lmite se alcance, el equipo
colaborativamente trabaja para resolver
el cuello de botella

Lead Cycle Time

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
2
negocio
.
Cycle Time. Inicia cuando el
trabajo inicia y finaliza cuando es
3 completado. Es el tiempo que el
.
equipo puede influenciar
4 Ejemplos de incremento en los
.
tiempos, indican oportunidades
de mejora en los procesos
Tambin proporciona visibilidad
Precaucion
del cumplimiento de los niveles
es
1 La mtrica es bastante sensible
de servicio (SLA)
a la captura adecuada de la
.
2 informacin
Puede usarse un Cumulative
.
Flow, para ver la tendencia del
cycle y lead time en el tiempo *
1
.

Defect Slippage
1.

2.

3.

Mide la calidad global de una fase.

Slippage se define como la cantidad
de defectos creados en una fase,
pero determinados hasta la siguiente
Es un indicador de Speed To Value por
que reduce la cantidad de tiempo
disponible del equipo
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 rpido y
que el tiempo disponible para
workload nuevo se reduce

Precauciones
1. No es un mtrica de QA, es una
mtrica que influencia todo el equipo,
siendo ste responsable de la calidad
del producto

Technical Debt
Refleja el esfuerzo a ms largo plazo,
que hace ms
difcil extender o
mantener un sistema. Usualmente
derivado de la aplicacin deficiente
de estndares y prcticas
2
Las herramientas de anlisis
.
esttico como Sonar, son
3 fundamentales en este caso
.
El Tech Debt debe ser visible
4 para el equipo
Medir la
.
tendencia
del
Tech
Debt
durante
el
proyecto:
Precaucion
priorizar,
es
El TechDebt no es necesariamente
1 documentar,
refactoring
algo malo. No necesariamente se
.
2 buscan 0 issues
El Tech Debt no puede ser evitado:
.
se requiere un balance
1
.

Build Success Rate

1.
2.
3.

Tasa porcentual de builds success en

el periodo
Facilita al equipo crear un flujo
continuo de entrega
Se usa comnmente en procesos
de integracin continua

Precauciones
4. Es usual contar con automatizacin
(Q1 y Q2 por ejemplo), en los
procesos de integracin
5. Es usual agregar mtricas de
anlisis esttico de cdigo durante
el proceso de build
6. No es un indicador del performance de
un equipo. Los Failed builds pueden
estar relacionados con distintas
causas

Coverage
Mide el porcentaje de caractersticas, que
en un periodo de tiempo, cuentan con
2 scripts de automatizacin de pruebas La
automatizacin al 100 no es eficiente:
.
economa de la calidad gil
3
La automatizacin es crtica en la
.
integracin continua y para la reduccin
4 de los ciclos de retroalimentacin Esta
.
mtrica es relevante para comprender el
5 Speed to Value del equipo
.
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,
Precaucion
etc.)
es
1 La automatizacin no es un silver bullet
.
La automatizacin tiene un costo de
2 mantenimiento alto, especialmente en
.
casos de automatizacin UI (por ejemplo
web functional testing)
1
.

Customer & Team Satisfaction

1 Investigar la satisfaccin del equipo y el
cliente
.
2 El mtodo ms comnmente usado son
.
las encuestas Una forma de respuesta
3 comn es usar respuestas en un rango 1
.
(strongly disagree) a 5 (strongly agree)
Precaucion
es Importante diferenciar en hechos
1
concretos y no opiniones Determinar
.
2 similitudes en las respuestas
.
Compartir respuestas con otros y
3 compartir acciones con los participantes
.

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

Las buenas mtricas

giles
Reafirman los principios giles
Evalan tendencias no el nmero
mismo Miden el resultado, no la
accin
El objetivo no es el nmero, es
la accin
Se mide todo lo necesario, nada mas que eso
(son pocas y generan valor al equipo)
Promueven los hbitos de mejoramiento
continuo (Kaizen) Ayudan a visualizar reas
que requieren mejoramientos
Se usan para iniciar conversaciones, no para
reemplazarlas Son simples de recolectar