 |
| Imagen de: rallydev.com |
Una concepción errada sobre el desarrollo ágil y Scrum es que por trabajar con alcance variable, pierden sentido las mediciones de progreso de proyectos.
Lo cierto es que aplicar desarrollo ágil no significa que las mediciones van a desaparecer, simplemente cambiaremos lo que se medirá y como.
Nos guste o no, las métricas y los reportes a los niveles superiores en las organizaciones son parte de la vida profesional.
En este artículo, presentaremos algunas sugerencias de indicadores de proyectos Scrum para presentar a la directiva. Bajo el enfoque predictivo tradicional, el énfasis está en medir el progreso del proyecto (trabajo realizado), en relación con la fecha y presupuesto comprometido originalmente, mientras que bajo el desarrollo ágil, se coloca énfasis en medir el desempeño del equipo en función de historias e items de Backlog producidos, deuda técnica y velocidad, en iteraciones de tiempo y esfuerzo fijas.
A continuación se presentan 5 métricas a utilizar en la medición de desempeño de proyectos Scrum:
Lo cierto es que aplicar desarrollo ágil no significa que las mediciones van a desaparecer, simplemente cambiaremos lo que se medirá y como.
Nos guste o no, las métricas y los reportes a los niveles superiores en las organizaciones son parte de la vida profesional.
En este artículo, presentaremos algunas sugerencias de indicadores de proyectos Scrum para presentar a la directiva. Bajo el enfoque predictivo tradicional, el énfasis está en medir el progreso del proyecto (trabajo realizado), en relación con la fecha y presupuesto comprometido originalmente, mientras que bajo el desarrollo ágil, se coloca énfasis en medir el desempeño del equipo en función de historias e items de Backlog producidos, deuda técnica y velocidad, en iteraciones de tiempo y esfuerzo fijas.
A continuación se presentan 5 métricas a utilizar en la medición de desempeño de proyectos Scrum:
1.- Valor (puntos) de Tareas en desarrollo
Un alto número de tareas en desarrollo es un mal indicador, siguiendo los principios de manufactura esbelta, según los cuales a menor trabajo en proceso mayor productividad (porque las historias se están procesando de forma optima.
Forma de cálculo: Suma del valor (puntos) de historia que están en desarrollo.
Se pueden graficar para estudiar su evolución en el tiempo.
 |
| Imagen de: Picasa Web Albums |
Más información sobre Tareas en desarrollo:
Curso Online de Scrum Master
¿Te gustaría obtener una visión general y completa de Scrum y despejar falsos paradigmas?
Inscríbete en el Curso:
2.- Tabla Burndown
Es una representación gráfica del trabajo que queda por hacer en relación con el tiempo que queda para hacerlo. La tabla se prepara para cada iteración (Sprint), en función de las historias y tareas incluidas en la sesión de planificación de la iteración. Las tareas se valoran en puntos, según las convenciones acordadas para el proyecto.
Es útil para determinar si la ejecución de la iteración transcurre según lo planeado, si se logrará completar todo el trabajo planeado para la iteración y cuando esto se logrará.
Forma de cálculo: Para cada punto de la gráfica se calcula lo siguiente:
Gráfica Burndown.
3.- VelocidadEs una representación gráfica del trabajo que queda por hacer en relación con el tiempo que queda para hacerlo. La tabla se prepara para cada iteración (Sprint), en función de las historias y tareas incluidas en la sesión de planificación de la iteración. Las tareas se valoran en puntos, según las convenciones acordadas para el proyecto.
Es útil para determinar si la ejecución de la iteración transcurre según lo planeado, si se logrará completar todo el trabajo planeado para la iteración y cuando esto se logrará.
Forma de cálculo: Para cada punto de la gráfica se calcula lo siguiente:
- Puntos o valoración de historias que quedan por desarrollar y probar (pasar a hecho)
- Puntos que deberían quedar según planificación de la iteración, lo cual se determina de la siguiente forma:
- Puntos totales planificados – Velocidad planificada de la iteración x días transcurridos
- La velocidad planificada se calcula así:
- Puntos totales planificados / días de duración de la iteración.
- Los puntos corresponden con la convención de valoración previamente establecida para las historias.
Gráfica Burndown.
Métrica del número de puntos o valor de historias que están siendo completados, bien sea por día, por semana o en toda una iteración. Es una medición de la productividad del equipo, dado que a mayor velocidad, menores tiempos para producir más funcionalidades de software.
Forma de cálculo: Número de puntos ó valor de historias completados en la iteración.
La velocidad se puede graficar para ver como aumenta o disminuye la velocidad del equipo en el tiempo.
Lectura recomendada
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
En este libro encontrarás un excelente compendio de las metodologías ágiles, sus procedimientos y artefactos. Excelentes ejemplos prácticos.
Gestión práctica de proyectos con Scrum: Desarrollo de software ágil para el Scrum Master
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
Autor: Antonio Martel.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
Una gran cantidad de casos reales y experiencia práctica para el Scrum Master en los proyectos con metodologías ágiles, como hacer estimaciones, presupuestos, lecciones aprendidas y más.
¿Interesado en otros productos y últimas novedades?
>> Visita nuestra sección de productos amazon
>> Visita nuestra sección de productos amazon
4.- Deuda Técnica
El concepto de “deuda técnica” es “trabajo que debe realizarse antes que una tarea se considere completa”. La misma surge de trabajo que es necesario hacer cuando se solicita algún cambio, por ejemplo, cuando se solicitan cambios al código es necesario modificar la documentación, o por ejemplo, cuando se exige una fecha de entrega temprana se elabora código que debe ser refactorizado posteriormente en caso de identificar incumplimiento de estándares de mantenibilidad.
Medir el volumen de la deuda técnica permite determinar cómo evoluciona la calidad del producto. Un número alto es un valor negativo, mientras que un número bajo es indicado positivo. El indicador se puede utilizar con un umbral de deuda técnica, el cual de ser superado significará volcar los esfuerzos del equipo en la reducción de dicha deuda.
Forma de cálculo: Valor total (expresado en puntos) de la deuda técnica en un momento dado.
La evolución de la deuda técnica se expresar en una gráfica de tiempo.
Más información sobre deuda técnica:
>> Scrum Metrics and Myths
>> Wikipedia Technical Debt
>> Intel Agile Best Practice(3 of 10)
Medir el volumen de la deuda técnica permite determinar cómo evoluciona la calidad del producto. Un número alto es un valor negativo, mientras que un número bajo es indicado positivo. El indicador se puede utilizar con un umbral de deuda técnica, el cual de ser superado significará volcar los esfuerzos del equipo en la reducción de dicha deuda.
Forma de cálculo: Valor total (expresado en puntos) de la deuda técnica en un momento dado.
La evolución de la deuda técnica se expresar en una gráfica de tiempo.
 |
| Imagen de: Intel Agile Best Practice 3 of 10 |
Más información sobre deuda técnica:
>> Scrum Metrics and Myths
>> Wikipedia Technical Debt
>> Intel Agile Best Practice(3 of 10)
5.- Valor de negocio entregado al cliente
Se realiza asignado a cada elemento del Backlog un "valor de negocio", determinado desde la perspectiva del cliente. Posteriormente se mide el valor de negocio asociado a cada item. Un valor alto es un buen indicador que se están atendiendo las funcionalidades que más agregan valor al negocio primero. Este indicador sirve para determinar también si el Backlog está siendo priorizado adecuadamente, es decir, que se estén elaborando primero las características que más agregan valor.
Forma de cálculo: Valor total de negocio asociado con los items entregados en una iteración.
Al igual que otros indicadores, se puede expresar en una gráfica de tiempo, en este caso por iteración (Sprint).
Más información sobre valor de negocio entregado:
>> Scrum Metrics and Myths
¿Y tú? ¿Qué opinas?
¿Cuales mediciones Agile utilizas en tus proyectos? Cual medición agregarías a esta lista? Cuéntanos en la sección de comentarios sobre una medición que no este en la lista y como se calcula.
¿Buscas más información de metodologías ágiles de desarrollo de software?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías ágiles?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Otros artículos relacionados
> Herramientas de software para gestión de proyectos dedesarrollo ágil
> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
> Los Programas de Certificación del Scrum Alliance
> Preguntas y respuestas sobre Scrum Alliance
> Metodologías de desarrollo ágil
> Herramientas de software para gestión de proyectos dedesarrollo ágil
> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
> Los Programas de Certificación del Scrum Alliance
> Preguntas y respuestas sobre Scrum Alliance
> Metodologías de desarrollo ágil
No hay comentarios :
Publicar un comentario