¿Cómo medir el porcentaje completado en un proyecto Agile?

La idea de porcentaje completo no suele existir en un proyecto Agile.

Para las tareas, el trabajo generalmente se ve como "hecho" o "no hecho". Lo más granular que obtendría es "no iniciado", "iniciado" o "en progreso" y "terminado". Tan pronto como se realiza una tarea, obtiene crédito por ella en la iteración dada.

Para los proyectos, el propósito de las iteraciones es hacer que el progreso sea visible para las partes interesadas. En teoría, el proyecto se puede terminar después de cualquier iteración que entregue un producto que satisfaga las necesidades de las partes interesadas y pasar a otra iteración generaría menos valor del que vale la iteración.

Debe determinar qué está buscando la gerencia cuando solicitan un porcentaje completo.

Si solicitan una duración estimada antes de que finalice la acumulación, puede estimar eso si tiene una velocidad estable. Lograr una velocidad estable generalmente toma varias iteraciones, pero si puede estimar (al menos aproximadamente) el tamaño de los elementos en el backlog, entonces puede determinar cuántas iteraciones (aproximadamente) se necesitarán para completar todos los elementos.

Si quieren saber cuánto trabajo se ha realizado hasta la fecha, se puede presentar en términos de tareas completadas del trabajo pendiente o una proporción de tareas completadas a elementos que aún están en el trabajo pendiente.

Sin embargo, existe un problema con el uso de la acumulación de productos para proporcionar información. La acumulación de productos puede cambiar en cualquier momento, y agregar o eliminar elementos cambiaría sus informes. También requeriría estimar todo el backlog del producto, en lugar de solo los elementos más importantes del backlog, lo que puede no ser preciso hasta que los elementos se comprendan y definan bien.

La persona responsable del proceso (en Scrum, el Scrum Master; en Disciplined Agile Delivery, el líder del equipo) debe trabajar con las partes interesadas externas para educarlos sobre el proceso y garantizar que obtengan la información que necesitan. No habrá un mapeo 1:1 entre las métricas para monitorear un proyecto basado en un plan y un proyecto ágil, pero es probable que se puedan proporcionar una o más medidas o métricas para abordar una necesidad de información.

Algo que muchos de los ágiles en línea hacen mal es el Burn Down Chart. Es una parte esencial de la comunicación con la gerencia y le permite responder a la antigua pregunta "¿Entonces, cuándo terminará?"

La primera respuesta es una pregunta: impulsada por el alcance o impulsada por el cronograma. Ahora, dado que el alcance impulsado es muy poco común e incluso cuando sucede, casi siempre se convierte en un cronograma, nos ceñiremos al cronograma para esta respuesta.

Así que tienes una fecha de lanzamiento, digamos dentro de seis meses. Luego, ingeniería hace una conjetura (lo llamamos estimación, aunque no es más que una conjetura) sobre cuánto trabajo pueden realizar en el primer sprint. Esto luego se usa para adivinar cuánto trabajo se puede hacer en la liberación total. Por el bien de este ejemplo, lo llamaremos 500 puntos.

Luego dejamos de adivinar y comenzamos a usar informes de velocidad. Cada sprint restas los puntos de historia entregados, del lanzamiento proyectado. Esto crea una línea de tendencia que se puede usar para ver de manera muy fácil y visual si va a entregar todo el valor para la fecha de lanzamiento. También comienza a predecir esto de inmediato. No más proyectos que estén completos en un 90 % y en verde hasta que estén en rojo brillante y con tres meses de retraso.

Si su velocidad cae, entonces puede decidir si reduce el alcance o aumenta el cronograma. En ágil, la sugerencia es reducir el alcance porque siempre puede agregar más tiempo más tarde, pero nunca puede recuperar el tiempo.

Realmente debería actualizar mi alcance frente a cronograma en la presentación de diapositivas Agile para incluir gráficos Burn Down. Para ver un buen video sobre cómo proyectar hacia abajo, sugiero Product Owner Video de Henrik Kniberg . La parte '¿Cuándo terminarás?' comienza alrededor de las 11:50, aunque ver el resto del video ayuda para el contexto.

Es imposible dar un número de "porcentaje completo", pero puede dar una estimación aproximada. Cuanto mayor sea la estimación, menos precisa será. Por ejemplo, si solo le queda una semana de trabajo, es probable que esté dentro de +/- 10% de la verdad. Si parece que le quedan cuatro meses de trabajo, podría perder fácilmente un 50 %, un 100 % o incluso más.

Dicho esto, una aproximación muy aproximada es simple. Presumiblemente, tiene un trabajo atrasado, y ese trabajo atrasado está completo (es decir, tiene historias y/o epopeyas que cubren lo que está tratando de lograr). Además, presumiblemente estas historias y epopeyas tienen puntos asociados con ellas. No todos serán puntos precisos, pero son un punto de partida.

La cantidad de trabajo realizado, entonces, es el número de puntos completados dividido por el número total de puntos estimados.

Sin embargo, lo importante para recordar con Agile es que este número no está escrito en piedra. Podrías haber terminado el 50 % esta semana y el 40 % la semana que viene aunque hayas terminado las tiendas mientras tanto. Es importante recordar que Agile no está diseñado para brindarnos estimaciones precisas, simplemente sirve para agregar más transparencia y estar preparado para el cambio temprano en lugar de sorprenderse por el cambio tardío.

Para una historia de usuario no existe tal cosa como un porcentaje completo. Tiene estado binario Hecho o Deshecho. Lo cual está determinado por la "Definición de Listo". 99% completado se deshace.

Hay pocos métodos para rastrear el progreso en la perspectiva de sprint, lanzamiento o proyecto.

1. Burndown chart, tanto de proyecto como de sprint. http://www.methodsandtools.com/archive/scrumburndown.php https://www.scrumalliance.org/community/articles/2013/august/burn-down-chart-%E2%80%93-an-effect- planificación-y-tracki

2. Diagrama de flujo acumulativo. http://brodzinski.com/2013/07/cumulative-flow-diagram.html http://www.slideshare.net/yyeret/explaining-cumulative-flow-diagrams-cfd

3. EVM ágil http://www.methodsandtools.com/archive/archive.php?id=61