Categoría: métricas

Agile White Book de AXA liberado

AXA (EMEA-LATAM Emerging Markets) ha liberado su Agile White Book, descargable en el siguiente enlace : http://www.slideshare.net/AXAEMEALA/documents

awb-axa-emeala

«Este libro es una guía de Agile que cubre los conceptos fundamentales y proporciona una terminología común para los diferentes países de la región EMEA-LATAM (aspecto importante dados sus diferentes niveles de madurez en Agile). Sirve como punto de entrada para futuros Scrum Masters que van a empezar a trabajar en Agile en AXA y esperamos que pueda servir también a otras organizaciones que están comenzando en este camino basado en personas y trabajo en equipo«.

Algunos ejemplos de contenido:

readiness-criteria

metrics-balanced-scorecard

También cuenta con varios checklists que puede ser útil consultar:

PBL-Refinement-checklist.jpg

Productividad y ejemplo de organización ágil

La mejora de la productividad está en boca de todos, pero …

¿Qué entendemos por productividad?

… ¿todos pensamos en el mismo concepto? ¿Sabemos medirla? ¿Qué alternativas tenemos a las palancas “tradicionales”?

Para conseguir grandes mejoras en productividad, no basta con eficientar lo que ya hacemos, tenemos que hacer cambios profundos en la manera en que entendemos las organizaciones.

Por otro lado, es necesario volver a las raíces:

Lo que hace ganar dinero a una empresa son los productos / servicios que proporciona a sus clientes.

Para que la cadena de valor sea efectiva, se necesita máxima comunicación en todas las personas que contribuyen a la creación, operación, servicio y soporte sobre un producto. Para ello, es fundamental hacer pivotar a la empresa alrededor de los productos que proporciona, cambiando el sistema productivo e introduciendo nuevos modelos mentales y culturales que apoyen ese cambio.

En la CAS2013 – Conferencia Agile Spain 2013  se desarrolló  una ponencia al respecto con los siguientes contenidos:

Visión de la productividad

Una visión más allá de la común “unidades entregadas” o “complejidad resuelta” por lapso de tiempo.

productividad

Factores de mayor impacto en la productividad

Factores de mayor impacto en la productividad (fruto del análisis de diversos estudios sobre centenares de proyectos) con el objetivo de hacer reflexionar sobre cuáles no se está actuando lo suficiente, qué factores son irrenunciables y qué sería conveniente priorizar en equipos y empresas.

factores-productividad

Modelo organizativo Agile – Lean para una empresa ágil.

enterprise-improvement-backlog

Framework Agile – Lean de mejora de productividad

Principios y prácticas en el marco del modelo de empresa ágil anterior.

organizacion-procesos-tecnicas
cultura-competencias-motivacion

Cuadro sencillo de métricas balanceadas

Conjunto de métricas para evaluar el efecto productido por los cambios realizados sobre los factores de productividad.

cuadro-mandos-balanceado

La presentación completa en español (con las últimas actualizaciones) se puede encontrar aquí.

Please find English version here.

CAS2013-presentacion-modelo-organizativo-productividad

El video de la ponencia, donde se explican los slides, se puede visualizar aquí.

CAS2013-agile-lean-productivity-improvement-framework-video

Artículos relacionados

Blogs relacionados

Métricas de iteración (Scrum sprint metrics)

Autor: Jordi Salvat i Alabart

(Esta es la traducción al castellano de mi blogpost http://jordionsoftware.blogspot.com/2009/10/simple-metrics-for-scrum.html)

 

Al terminar mi charla en la Barcelona PHP Conference recibí varias preguntas sobre las métricas que utilizamos: como construimos nuestros gráficos de burn-down, etc.

Esto es lo que estamos haciendo a día de hoy. Es una mezcla de ideas de "Scrum and XP from the Trenches", "Agile Estimation and Planning" [1], y las nuestras propias:

 

  • El Product Backlog (PBL) se estima en Story Points sin dimensión utilizando Planning Poker. Para ello hacemos por lo menos una sesión de planning poker en cada sprint. Estas estimaciones solo se usan para la planificación a largo plazo[2].
  • Antes de cada reunión de planificación de Sprint, calculamos de cuantas horas·hombre disponemos en el siguiente sprint. Después multiplicamos por un factor de foco (actualmente 55%). Hasta hace un par de sprints, utilizábamos el factor obtenido en el sprint anterior, pero eso no funcionaba bien y causaba sprints alternados de carga demasiado grande/demasiado ligera. Así que decidimos fijar un valor en la parte baja del rango y subirlo lentamente cuando tengamos confianza en que podemos hacerlo. Creo que aún no hemos terminado de experimentar en este área.
  • En cada reunión de planificación de sprint, seleccionamos (el equipo y el Product Owner) unos pocos ítems del principio del PBL, identificamos sus tareas (en post-its amarillos), y estimamos cada una en horas (horas ideales, para ser preciso). Decidimos qué (y cuantos) ítems incluir en base a estas horas: el total no debe exceder el producto calculado en el paso anterior. Los post-its para los ítems elegidos van a la columna "Pendiente" en el tablero de tareas.
  • La suma de las estimaciones de las tareas seleccionadas es el primer punto del gráfico de burn-down.
  • El equipo actualiza cada día el tablero de tareas como sigue:
    • Escribiendo dos números en cada una de las tareas en las que han trabajado: horas trabajadas en ella desde el sprint previo y horas estimadas que quedan para completarla.
    • Moviendo cada tarea completada a la columna “completada”.
    • Añadiendo un post-it azul por cada tarea que ha sido adicionada “con disposición” en el sprint. Por supuesto, sólo hacemos esto cuando estamos claramente avanzados respecto al plan (“con disposición” significando que tenemos la elección de cogerla o no, en contraste con el “forzada” que indico más abajo).
    • Añadiendo un post-it rojo (con una estimación) en la fila superior (etiquetada “fuera de sprint”) para cada tarea no planeada que ha sido "forzada" a ser introducida en el sprint. Preferiríamos evitar esto, pero el negocio necesita que cojamos algunas de ellas (son mayoritariamente tareas de valor añadido que no pueden ser planeadas por que dependen de eventos externos como ventas de campañas de publicidad). Los errores en producción también son tratados de esta manera.
    • También ponemos con un post-it rojo las tareas que deberían formar parte del sprint pero que no fuimos capaces de identificar durante la planificación, sólo que van en la fila correspondiente a su ítem de producto.
  • Después sumo la última estimación disponible para cada tarea en la parte "viva" del tablero de tareas (eso es: todas las tareas salvo las completadas) para obtener una estimación del trabajo que falta. Ese es el valor que pongo cada día en el gráfico de burn-down. La suma manual es engorrosa, pero solo me toma un par de minutos, que contribuyo contento a cambio de las muchas ventajas de usar un tablero de tareas de verdad y no una herramienta electrónica.
  • Al final de cada sprint produzco un pequeño conjunto de estadísticas que publico en la página wiki de ese sprint (indicando al lado de cada una el valor del sprint anterior para poder comparar, aunque sería mejor usar gráficos):

 

ESTADÍSTICAS INICIALES (calculadas al principio del sprint)

A. Velocidad objetivo: suma de los "story points" de todos los items del PBL inicialmente incluídos en el sprint.
B. Horas estimadas: suma de las estimaciones en todos los post-its amarillos al principio del sprint. Como he dicho antes, este es el primer valor que dibujo en el gráfico de burn-down.
C. Horas diponibles: total de horas·hombre disponibles para el sprint.
D. Factor de foco objetivo (B/C): como un %

 

ESTADÍSTICAS FINALES (calculadas al terminar el sprint)

E. Velocidad real: suma de los "story points" realmente completados en el sprint

F. Horas reales: número real de horas dedicadas al sprint (eso es: C – bajas médicas y similares + horas extras si las hubiera)
G.Total estimaciones tareas previstas en sprint completadas: suma de las estimaciones iniciales de los post-its amarillos y azules que realmente completamos. Eso es: B + post-its azules – trabajo excluído del sprint.
H. Factor de foco (G/F): como un %

J. Horas cargadas a tareas planeadas: recuento de todas las horas reportadas en todos los post-its amarillos y azules completados en el sprint. Este es el más pesado de calcular, pero no son más de dos o tres minutos por sprint, así que deja de gimotear. Incluso mi hija de 9 años puede sumar eso sin necesidad de un ordenador.
K. Horas cargadas a tareas no planificadas "dentro del sprint"
L. Error de estimación ((J+K)/G-1): como un %
M. Factor de foco real ((J+K)/F): como un %

N. Horas cargadas a tareas no planificadas "fuera de sprint": con frecuencia las descompongo en categorías tales como bugfixes, soporte, operaciones, publicidad,…

P. Total de horas cargadas (J+K+N)
Q. Error de reportado (1-P/F)

 

Son un montón de valores, y la nomenclatura de los varios "factores de foco" puede ser confusa, pero nos permiten dilucidar, cuando hay problemas de planificación, si fue por un exceso de trabajo no planificado, estimación inválida (hubo tareas que no supimos identificar), o estimación imprecisa. Los dos últimos valores (P y Q) son solo un "checksum" para alertarnos si nos ponemos vagos y dejamos de reportar las horas adecuadamente.

 

Para saber más

 

 

Métricas ágiles y valor – Resultados del sexto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • Se debe tener sólo las métricas realmente necesarias.
  • Deben estar “balanceadas”, para detectar si se está obteniendo unos resultados a costa de otros.
  • Las métricas ágiles más importantes son: el valor que se va entregando el cliente y la velocidad de desarrollo.
  • Las métricas se pueden ampliar cuando se quiere ver la evolución de un problema. Una vez solucionado, se dejan de recoger.
  • Los criterios básicos de planificación de objetivos/requisitos de proyecto son el valor y el coste, a los que se puede añadir: riesgo, integraciones y madurez.
  • La percepción del valor de los requisitos puede ir cambiando según avanza el proyecto. Esto se gestiona en la replanificación que se hace al inicio de cada iteración.

 

priorizacion-encuentro

 

Métricas básicas en un proyecto ágil
  • Se debe tener sólo las métricas realmente necesarias, dado el coste que implica tanto recoger como interpretar cualquier métrica.
  • Cuando se recoge una métrica, las personas intentan quedar bien respecto a esa métrica. Por ello, es conveniente disponer de un conjunto de métricas “balanceadas” que detecten si se está obteniendo unos resultados a costa de otros. Por ejemplo, puede ser que la productividad esté aumentando pero a expensas de un descenso de calidad.
  • Notar que las métricas también permiten tener una proactividad y detectar un posible problema antes de que se manifieste completamente.
  • Las métricas ágiles más importantes son:
    • El valor que se va entregando el cliente (Product Owner), que permite saber:
    • La velocidad de desarrollo del equipo, que permite:
      • Extrapolar la fecha de finalización del proyecto y/o saber de qué objetivo/requisitos se dispondrá en una fecha determinada.
      • Planificar un nuevo proyecto a partir de la historia anterior.
      • Medir le aprendizaje del equipo, ya que es una métrica que debería aumentar con el tiempo.
    • Métricas de calidad como el número de defectos.

graficos-velocidad-valor-coste

 
Ampliación de las métricas
  • El conjunto de métricas se pueden ampliar cuando aparece un problema a solucionar y se quiere ver su evolución. Por ejemplo:
  • Dado que la recolección e interpretación de métricas tiene un coste (no sirve de nada disponer de un gráfico de tendencia si no se hace un análisis causal de por qué se está dando esa tendencia), una vez solucionado el problema (cuando la métrica ya es estable o el equipo ya ha aprendido), estas métricas se dejan de recoger (a menos que su recolección sea automática y su observación fácilmente discriminable).
 
La métrica “valor”
 
Aunque el cliente (Product Owner) es el responsable de determinar el valor de cada objetivo (requisito, funcionalidad, feature o historia de usuario), en el encuentro también se apuntó que el equipo (o empresa ejecutora del proyecto) también valora qué le aporta el proyecto. Por ejemplo, unos objetivos determinados (o un proyecto entero) pueden tener relativamente poco retorno de inversión para el cliente, pero mucho valor para el equipo, ya que le permite adquirir conocimiento, experimentar con nuevas tecnologías, ganar algún premio o reconocimiento, etc.
En el encuentro se mencionaron diversos ejemplos sobre cómo el cliente puede indicar el valor de cada objetivo:
  • Si no se conoce suficientemente cual va a ser el retorno de inversión, para cada objetivo el cliente indica en forma de dinero el valor que le aportará o lo que pagaría por él, por ejemplo: 1500 €, 1000 €, 750 €, 750 €, 500 €, 500 €, 500 €, etc.
    • De esta manera queda de manifiesto el orden de desarrollo que necesitaría el cliente (en Scrum se planifica el proyecto a partir del valor y del coste de desarrollo de cada objetivo, construyendo la lista de objetivos priorizada o Product Backlog) y qué objetivos tienen para el cliente un valor semejante.
    • Otros criterios de planificación que también se mencionaron fueron los riesgos asociados a cada requisito, las integraciones a realizar con otros equipos y la madurez de cada requisito (de manera que se aprovechase el tiempo del proyecto para que el cliente fuese conociendo más el producto e ir aclarando los requisitos menos maduros).
    • Las metodologías ágiles hacen explícito el balance entre valor y coste de desarrollo, hace más difícil que el cliente priorice igual requisitos que tienen el mismo coste pero valor muy diferente. Por ejemplo, en una web de contenidos multimedia no priorizará igual poder reproducir vídeos (funcionalidad que dispara el número de usuarios) que poner documentos (funcionalidad que con un coste similar que apenas incrementa el número de usuarios).
  • Otra posible medida de valor es cómo se espera que cada funcionalidad contribuya a conseguir una meta de la empresa. En el encuentro se comentó que en Google se mide el valor de nuevas features o aplicaciones en función del número de usuarios que se espera que las vayan a utilizar. Para conseguir la mejor aplicación posible, así como el compromiso y la aportación de los miembros del equipo, se cobra una bonificación en función del cumplimiento de este objetivo.
  • Se mencionaron técnicas de planificación como el Priority Poker (como el Planning Poker pero con cartas del 1 al 9) y el Kano Model con la clasificación de requisitos según sean:
    • Mandatory – Requisitos necesarios que por ellos mismos no aportan valor (por ejemplo que un móvil pueda realizar llamadas).
    • Lineal – Cuantos mejor es el resultado del requisito, más valor tiene el producto (por ejemplo la duración de una batería de móvil).
    • Exciter – El usuario se encuentra con una funcionalidad que no esperaba pero que le gusta mucho.
  • En casos de priorización más complejos y/o con un número de stakeholders alto, puede ser conveniente combinar varias técnicas de priorización por valor. En este caso, puede ser conveniente minimizar el número de stakeholders que intervienen, dado que si sus intereses son demasiado diferentes harían que todos los requisitos acabasen teniendo un grado de prioridad semejante [en Scrum sólo puede haber un único representante de todos los stakeholders, el Product Owner].
El cliente debe poner los medios para ir midiendo el valor que realmente va aportando el proyecto y de esta manera ir aprendiendo cómo asignar valor en próximos proyectos.
 
Hay que notar que la percepción del valor de los requisitos puede ir cambiando según avanza el proyecto (el cliente entiende mejor qué es lo que realmente necesita, la competencia ha sacado una nueva feature al mercado que hay que desarrollar, etc.), lo cual se gestiona en la replanificación que se hace al inicio de cada iteración.
 
Se mencionó la dificultad del trabajo de Product Owner dado que debe predecir cuanto y cómo se consumirá un producto, así como tener ideas brillantes y rompedoras. Esta predicción del futuro consumo (aunque se sirva de técnicas de investigación de mercado y competencia, focus groups, etc.), en principio parece más difícil que gestionar una reunión para que sea productiva (trabajo del Facilitador o Scrum Master) o sea desarrollar una pieza del producto (trabajo del equipo). Si no hay concepto de producto, no hay inversión. Y sin dinero no hay proyecto.
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, la transmisión en directo del encuentro, los snacks y las bebidas.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
Para saber más
 

Métricas ágiles y cuadro de mandos integral para Scrum

La métrica más importante en un proyecto ágil como Scrum es el valor que se está dando al cliente. Mediante esta métrica, el cliente puede conocer la velocidad con que retorna su inversión y saber cuándo ya no es necesario seguir con el proyecto, por que los beneficios pendientes de obtener ya no compensan sus costes.

Sin embargo, cuando se mide a una persona o a un equipo de una determinada manera, sus acciones pueden desviarse en exceso hacia ese objetivo y descuidar otros aspectos también importantes como, por ejemplo, la calidad, los costes, los riesgos, la sostenibilidad de la velocidad con que obtienen objetivos, etc. Por ello, puede ser necesario utilizar un conjunto de métricas de diferentes aspectos relacionados, creando de esta manera un cuadro de mandos integral ágil (agile balanced scorecard).

graficos-progreso-scrum

 
Selección y uso de las métricas
Respecto al valor aportado al proyecto, es recomendable que esté basado en un único indicador económico clave con el que el cliente pueda medir todos los objetivos del proyecto, de forma que permita guiar la toma de decisiones y la forma de invertir en el proyecto.
Para el resto del cuadro de mandos se debe escoger el mínimo número de métricas que permita tomar decisiones sobre los resultados del proyecto y las necesidades del cliente (tras un análisis causal de los problemas que están mostrando, siempre recordando que el uso de una métrica puede condicionar la actuación de las personas). Se debe minimizar tanto el coste e impacto que se añade al trabajo ordinario del equipo (hay que ir registrando lo que sucede, cosa que puede incluso desvirtuar la métrica) como su coste de recolección, proceso y presentación. Por todo esto, cuando un problema específico esté resuelto, hay que plantear si tiene sentido seguir recogiendo las métricas asociadas.
Es conveniente mostrar en el cuadro de mandos los objetivos de la iteración, entrega, proyecto, programa u organización, según sea el ámbito del cuadro de mandos (mostrar la velocidad con que se consiguen los objetivos del proyecto o guiar e informar sobre la estrategia de la organización y su cumplimiento).
En los equipos ágiles es común que las métricas surjan ante una necesidad del equipo, como una forma de mejorarse. Por ejemplo la velocidad del equipo puede ser una herramienta para que el equipo planifique y tome compromisos, e incluso para cuantificar una mejora.
Será fundamental presentar las tendencias de las métricas a lo largo del tiempo (los valores en un momento dado pueden deberse a situaciones puntuales), con diferentes niveles de agregación en función de las necesidades: diario, iteración, etc.
 
Métricas ágiles del cuadro de mandos
La mayoría de las métricas más importantes derivan de las herramientas propias de Scrum (la lista de requisitos priorizada, la lista de tareas de la iteración y los gráficos de trabajo pendiente), por lo que el momento natural para actualizar este cuadro de mandos es tras la retrospectiva de la iteración.
Notar que en una gestión ágil de proyectos carece de sentido utilizar algunas de las métricas más utilizadas en proyectos tradicionales o en cascada, como por ejemplo:
  • El porcentaje de completitud de un objetivo o requisito: en un proyecto ágil, para poder determinar cuando se completa un requisito o entrega se utiliza concepto de esfuerzo pendiente, así como qué objetivos están completados o cuáles no (al cliente no le interesan los que están en curso ya que no puede hacer uso de ellos)
  • Los diagramas de Gantt: no aportan más información que la que aportan las herramientas propias de Scrum.
Las métricas de uso más común se muestran en negrita. Las que no aparecen en negrita se muestran como ejemplos de métricas que se pueden utilizar de manera más temporal para analizar problemas concretos.
Métricas de productividad y efectividad de la entrega
  • Velocidad con que se completan objetivos/requisitos en cada iteración. Idealmente debería aumentar con respecto al tiempo (productividad). También permite ir extrapolando la fecha de finalización del proyecto en función de cuando se vaya a completar todo su alcance.
  • Tiempo de entrega de un requisito tras su petición o Lead Time (responsividad a necesidades del cliente, Time to Market, tiempo de servicio), en función de la criticidad de la petición (urgente, etc.) y cumplimiento de los Acuerdos de Nivel de Servicio (ANS / SLA).
  • Urgencias y prioridad/valor de los requisitos completados, para comprobar si existe desalineamiento con los objetivos del proyecto y/o la estrategia de la organización.
Métricas de resultados del proyecto
  • Velocidad con que se aporta valor al negocio (desde el punto de vista del cliente).
  • Valor acumulado.
  • Requisitos completados en la iteración.
  • Próximos requisitos a desarrollar.
  • Cambios incorporados y requisitos añadidos sobre el alcance inicial del proyecto.
  • Número de requisitos completados respecto al total de requisitos (métrica que también permite observar cambios de alcance).
  • Días de trabajo ideales pendientes (métrica que permite proyectar la fecha de finalización del proyecto).
  • Desviación de resultados de proyecto respecto a planificación inicial.
Métricas de situación financiera
  • Retorno de Inversión (ROI) pendiente, el valor pendiente respecto al coste pendiente, para saber cuándo finalizar el proyecto (ver la cláusula de finalización anticipada del contrato en el artículo Un contrato ágil para Scrum).
  • Presupuesto disponible y/o presupuesto gastado.
  • Desviación financiera respecto a la planificación inicial.
Métricas de calidad
Expectativas:
  • Satisfacción del cliente / usuario, respecto a los resultados del proyecto y a la colaboración con el equipo.
  • Ambiente en el equipo
Calidad funcional:
  • Incidencias (defectos encontrados por el cliente o usuarios del producto), por estado y por criticidad.
  • Errores (defectos detectados internamente, bugs), por estado y por criticidad.
  • Cobertura de las pruebas.
  • Trazabilidad.
Mantenibilidad:
  • Días de deuda técnica.
  • % de código en SCM (e.g. GIT), motor CI (e.g. Jenkins),  herramienta de control de calidad de código (Sonar).
    • Separando las partes «nuevas / refactorizadas» del monolito.
  • Cumplimiento de estándares de codificación, normativas, regulaciones, etc.
  • Comentarios en el código.
  • Complejidad ciclomática del producto.
  • Tamaño de las operaciones.
  • Calidad de la documentación (existencia y cobertura de la documentación funcional, técnica, de pruebas, de implantación, operativa, etc.).
Métricas de riesgos, impedimentos, proceso y mejora continua
  • Riesgos (severidad y mitigaciones) e impedimentos: considerando las dependencias o sinergias con otros equipos o proyectos, la implicación del cliente, los problemas tecnológicos, el resultado de las retrospectivas, etc.
  • Lecciones aprendidas.
  • Actividades de mejora a planificar (comunicaciones, formaciones, soporte, herramientas, etc.).
  • Uso de prácticas específicas: número de integraciones, tiempo de refactorización, de TDD, revisiones expertas, etc.
  • Situaciones anómalas: sobreesfuerzo, requisitos no completados, terminaciones anormales de iteración, interrupciones, sospechas de mala aplicación del proceso (por ejemplo, si el cliente se muestra sorprendido en la demostración de la iteración), etc.
  • % de personas que no intervienen en las reuniones diarias de sincronización.
 
Conclusiones sobre el estado del proyecto
Este apartado debe contener un resumen con las métricas más importantes y las relaciones entre ellas, así como las lecciones aprendidas y próximas acciones de mejora (tras un análisis causal de problemas como, por ejemplo, el que se realiza en una retrospectiva), de manera que el cliente pueda tomar decisiones informadas y dirigir los resultados del proyecto.
Hay que recordar que muchos de los problemas detectados y disfuncionalidades de la organización ya estaban ahí antes de utilizar una gestión ágil de proyectos como Scrum, no son el resultado de aplicarla. La transparencia que proporciona Scrum los hace más visibles, lo cual ayuda a priorizar y tomar decisiones (de manera conjunta con las personas implicadas para consensuar la mejor solución). Para ello es necesario disponer del máximo apoyo de la Dirección para alinear comportamientos, recursos y resultados con la estratégia de la organización.
 
Más información