Hola Mundo
Páginas: 7 (1676 palabras)
Publicado: 6 de diciembre de 2012
-------------------------------------------------
Principio del formulario
Final del formulario
lunes, diciembre 08, 2008
Estado del proyecto : métricas ágiles
Acabo de leer el artículo que Xavi Albaladejo ha publicado en Proyectos Ágiles titulado "Métricas ágiles y cuadro de mandos balanceado para Scrum".
En mi modesta opinión, me parece una buena recopilación de métricas (algunasdifíciles de automatizar, como la del resultado de las retrospectivas, pero no por ello de menor valor. Me atrevo a preguntaros, ¿qué 5, 6 ó 7 métricas usarías para que el cliente tuviera una visión resumida del estado del proyecto? Vamos, ¿cómo construiríais el "cuadro de mandos" para vuestros clientes?
Vale, como está feo tirar la piedra y esconder la mano, ahí van las mías:
* Velocidad delequipo (para cada sprint)
* ROI. Cada historia de usuario debe tener un valor de negocio asignada por el Dueño del Producto y, por tanto, podemos saber cuánto valor de negocio se ha convertido en cada sprint.
* Las tres métricas de calidad que Xavi resalta: Satisfacción del cliente o usuario, Incidencias o defectos detectados por los usuarios, Defectos detectados por el equipo dedesarrollo.
* Tiempo de puesta en producción después de cada sprint. (Esta métrica no la incluye Xavi, pero a mi entender serviría para, de alguna manera medir parte de las "Lecciones aprendidas")
Me gustaría también ser capaz de ofrecer al cliente alguna medida del riesgo que se está asumiendo y cómo va afectando éste durante la vida del proyecto, pero sinceramente no sabría bien cómo hacerlo. Quizásuna buena referencia para esto (en inglés) sería este artículo que enseña a estimar el riesgo con una hoja de cálculo.
No estaría mal mostrar el "panel de control" como una "radar chart" para poder comparar de un vistazo varias métricas de un sprint a otro, p.ej.
¿Sería diferente el cuadro de mandos del cliente y el del ScrumMaster o jefe de proyecto? Hombre, el corazón me dice que deberíanser iguales por eso de que "somos un equipo", "la transparencia con el cliente", y todo eso..., pero la razón me dice que a cada uno le interesa una perspectiva diferente del proyecto:
* al cliente es algo más económico, de valor de negocio, de rentabilidad de la inversión en marcha,
* mientras que al ScrumMaster le interesa más bien los impedimentos que se pueden estar acercando parapoderse adelantar a su aparición.
Por eso creo que deben ser diferentes. ¿Cuáles serían vuestras métricas para el ScrumMaster?
Las mías, creo que serían:
* Velocidad del equipo. Sí, también, de hecho, con más razón incluso que para el cliente. De esta métrica se pueden sacar muchas conclusiones que contrastar en las retrospectivas con el equipo. Es muy importante averiguar a qué pueden serdebidas las variaciones en la velocidad: estimamos mejor, hemos eliminado un impedimento que puede volver a surgir, ha surgido un impedimento que nos retrasa...
* Las líneas de código. Sí, sé que es un poco llamativo y
"anticuado", pero me parapeto detrás de un excelente artículo de James
Shore (autor de "The Art of Agile Development") sobre cómo medir la deuda técnica.
* Felicidad delequipo. Bfff, esto es dificil de explicar, pero la actitud que tiene el equipo después de cada retrospectiva es importantísimo en el desarrollo del siguiente sprint. Recomiendo leer sobre el "Niko-niko calendar", y si alguien lo pone en práctica, estaría encantado de conocer sus impresiones.
* Desviación en las estimaciones. Me parece importante ofrecer este feedback al equipo (porque el"cuadro de mandos" creo que debe ser para todo el equipo), y por ello creo que el ScrumMaster debe ser capaz de recopilar esta información y manejarla con cuidado porque puede afectar mucho a la credibilidad del equipo (incluso para ellos mismos).
* Calidad del código: cobertura, complejidad ciclomática y las reglas de calidad acordadas que podamos automatizar con herramientas como Checkstyle,...
Principio del formulario
Final del formulario
lunes, diciembre 08, 2008
Estado del proyecto : métricas ágiles
Acabo de leer el artículo que Xavi Albaladejo ha publicado en Proyectos Ágiles titulado "Métricas ágiles y cuadro de mandos balanceado para Scrum".
En mi modesta opinión, me parece una buena recopilación de métricas (algunasdifíciles de automatizar, como la del resultado de las retrospectivas, pero no por ello de menor valor. Me atrevo a preguntaros, ¿qué 5, 6 ó 7 métricas usarías para que el cliente tuviera una visión resumida del estado del proyecto? Vamos, ¿cómo construiríais el "cuadro de mandos" para vuestros clientes?
Vale, como está feo tirar la piedra y esconder la mano, ahí van las mías:
* Velocidad delequipo (para cada sprint)
* ROI. Cada historia de usuario debe tener un valor de negocio asignada por el Dueño del Producto y, por tanto, podemos saber cuánto valor de negocio se ha convertido en cada sprint.
* Las tres métricas de calidad que Xavi resalta: Satisfacción del cliente o usuario, Incidencias o defectos detectados por los usuarios, Defectos detectados por el equipo dedesarrollo.
* Tiempo de puesta en producción después de cada sprint. (Esta métrica no la incluye Xavi, pero a mi entender serviría para, de alguna manera medir parte de las "Lecciones aprendidas")
Me gustaría también ser capaz de ofrecer al cliente alguna medida del riesgo que se está asumiendo y cómo va afectando éste durante la vida del proyecto, pero sinceramente no sabría bien cómo hacerlo. Quizásuna buena referencia para esto (en inglés) sería este artículo que enseña a estimar el riesgo con una hoja de cálculo.
No estaría mal mostrar el "panel de control" como una "radar chart" para poder comparar de un vistazo varias métricas de un sprint a otro, p.ej.
¿Sería diferente el cuadro de mandos del cliente y el del ScrumMaster o jefe de proyecto? Hombre, el corazón me dice que deberíanser iguales por eso de que "somos un equipo", "la transparencia con el cliente", y todo eso..., pero la razón me dice que a cada uno le interesa una perspectiva diferente del proyecto:
* al cliente es algo más económico, de valor de negocio, de rentabilidad de la inversión en marcha,
* mientras que al ScrumMaster le interesa más bien los impedimentos que se pueden estar acercando parapoderse adelantar a su aparición.
Por eso creo que deben ser diferentes. ¿Cuáles serían vuestras métricas para el ScrumMaster?
Las mías, creo que serían:
* Velocidad del equipo. Sí, también, de hecho, con más razón incluso que para el cliente. De esta métrica se pueden sacar muchas conclusiones que contrastar en las retrospectivas con el equipo. Es muy importante averiguar a qué pueden serdebidas las variaciones en la velocidad: estimamos mejor, hemos eliminado un impedimento que puede volver a surgir, ha surgido un impedimento que nos retrasa...
* Las líneas de código. Sí, sé que es un poco llamativo y
"anticuado", pero me parapeto detrás de un excelente artículo de James
Shore (autor de "The Art of Agile Development") sobre cómo medir la deuda técnica.
* Felicidad delequipo. Bfff, esto es dificil de explicar, pero la actitud que tiene el equipo después de cada retrospectiva es importantísimo en el desarrollo del siguiente sprint. Recomiendo leer sobre el "Niko-niko calendar", y si alguien lo pone en práctica, estaría encantado de conocer sus impresiones.
* Desviación en las estimaciones. Me parece importante ofrecer este feedback al equipo (porque el"cuadro de mandos" creo que debe ser para todo el equipo), y por ello creo que el ScrumMaster debe ser capaz de recopilar esta información y manejarla con cuidado porque puede afectar mucho a la credibilidad del equipo (incluso para ellos mismos).
* Calidad del código: cobertura, complejidad ciclomática y las reglas de calidad acordadas que podamos automatizar con herramientas como Checkstyle,...
Leer documento completo
Regístrate para leer el documento completo.