Recientemente comenzamos a usar puntos de historia en nuestro proceso ágil, lo cual es increíble. Debido a esto, estamos obteniendo estimaciones para ciertas tareas y teniendo una idea de nuestra velocidad.
Sin embargo, tengo curiosidad por saber si los puntos de la historia pueden o deben usarse para medir el crecimiento del equipo.
Entonces, para el ejemplo clásico, digamos que tenemos un grupo de desarrolladores que están de acuerdo en que un problema o proyecto vale 21 puntos de historia. A algunos de los desarrolladores les llevará 3 días, mientras que a otros les llevará 6 días.
En algún momento, mientras la complejidad de los problemas sigue siendo la misma, la productividad de los desarrolladores aumentará naturalmente debido a su familiaridad con el código base, etc. ¿Existe una forma efectiva de medir el crecimiento en el equipo con puntos de la historia? O tal vez esta es la forma completamente incorrecta de hacerlo.
La velocidad mide la cantidad de esfuerzo que el equipo puede realizar, en promedio, en un sprint determinado. Pueden haber muchas razones para esto. Puede ser que el equipo haya crecido en sus habilidades técnicas. Podría ser que el equipo trabaje mejor en conjunto porque han llegado a la última parte de la etapa de Formación, Tormenta, Normalización y Ejecución. Puede ser que los impedimentos organizativos se hayan resuelto, despejando el camino para que el equipo sea más eficiente. También podría ser que el equipo haya eliminado las barreras del equipo para aumentar la productividad a través del proceso frecuente de inspección y adaptación en las retrospectivas de sprint.
Si la velocidad aumenta, entonces, en teoría, se ofrece más valor en vivo a los usuarios.
Independientemente de las circunstancias exactas que llevaron al aumento de la velocidad, parece que se ha producido algún tipo de crecimiento. Puede usar la velocidad para mostrar que un equipo ha "crecido", pero no parece claro cómo podría decir exactamente qué parte del equipo ha crecido.
Además, tratar de comprender los detalles exactos podría crear problemas con la autoorganización y la propiedad de uno mismo, si la persona que intenta realizar la medición es un gerente o alguien en una posición de autoridad. Podría hacer que el equipo ceda ante el gerente o piense que está haciendo algo mal, o podría hacer que dejen de experimentar y sigan haciendo lo que sea que un gerente o una persona de autoridad identificó como la única razón para el crecimiento (incluso si no fue la única razón).
Por último, si el equipo descubre que un gerente o figura de autoridad se enfoca en su velocidad, pueden intentar jugar con esa métrica. Además, si mostramos la velocidad a los gerentes senior y a las personas en el poder que luego observan una caída de la velocidad por cualquier motivo, es más probable que interfieran con el equipo que si nunca hubieran estado expuestos a esta métrica en primer lugar. Algunos Entrenadores certificados de Scrum, como Michael James, creador de Scrum Training Series , sugieren que la velocidad se usa mejor para la previsión de lanzamientos, para mostrar cuántas funciones se pueden lanzar en un período de 3 a 6 meses o en algún momento en el futuro. Es menos probable que esto genere los mismos problemas enumerados anteriormente, ya que un buen propietario del producto podría crear un plan de lanzamiento basado en un rango en lugar de medidas exactas.
ago
jmort253
Cronax