Velocidad ágil

Existen algunas pautas simples para estimar la velocidad inicial de su equipo de scrum antes de completar la primera iteración (consulte las preguntas frecuentes a continuación), pero después de ese punto, debe usar medidas históricas comprobadas para las funciones de planificación. En poco tiempo, la velocidad generalmente se estabiliza y proporciona una base excelente para mejorar la precisión y la confiabilidad de la planificación a corto y largo plazo de sus proyectos ágiles. Los ciclos de entrega ágiles son muy pequeños, por lo que la velocidad emerge rápidamente y se puede validar muy temprano en un proyecto y luego confiar en ellos para mejorar la previsibilidad del proyecto.

¿Es la velocidad realmente tan simple?

sí lo es. No intente no complicar demasiado la velocidad: realmente es un concepto sencillo y gran parte de su valor reside en su simplicidad inherente. Muchos gerentes y equipos nuevos en métodos ágiles tienden a analizar demasiado el concepto de velocidad y a acumular demasiada complejidad a su alrededor. Después de unos meses de experiencia en proyectos ágiles, la mayoría de las personas experimentarán un momento de "aj ja" con velocidad, despojándose de cualquier carga que hayan asociado con él y apreciando su simplicidad y valor intrínseco.

Gráficos de velocidad

Junto con release y los gráficos de trabajo pendiente de iteración, que miden la velocidad de los equipos ágiles, han demostrado proporcionar una gran perspectiva/visibilidad del progreso y el estado del proyecto. Un gráfico de velocidad muestra la suma de las estimaciones del trabajo realizado en todas las iteraciones. Por lo general, la velocidad se estabilizará a lo largo de la vida de un proyecto, a menos que la composición del equipo del proyecto varíe mucho o cambie la duración de la iteración. Como tal, la velocidad se puede utilizar con fines de planificación futura. Si bien suele ser confiable para un par de iteraciones, si acepta que las prioridades, los objetivos y los equipos pueden cambiar con el tiempo y, por lo tanto, el nivel de confianza de una iteración en el futuro lejano, la velocidad puede usarse para planificar releases mucho más lejos en el futuro.

Inicialmente, los equipos nuevos en el desarrollo de software ágil deben sumergirse y seleccionar una velocidad inicial utilizando las pautas y la información disponibles. Muy rápidamente (tan rápido como la próxima iteración), la velocidad se puede medir y ajustar. Velocity, junto con características granulares (p. ej., historias de usuarios, trabajo atrasado, requisitos, etc.) y estimación de alto nivel y/o relativa (en términos de puntos, días ideales o incluso horas), simplifica y acelera enormemente toda la planificación del proyecto. , estimación, seguimiento de estado y proceso de informes.

Preguntas frecuentes sobre Agile Scrum

¿Cómo es la velocidad de un desarrollo ágil equipo calculado?

La velocidad es la suma de las estimaciones de características entregadas (es decir, aceptadas) por iteración.

¿Qué unidad se utiliza para medir la velocidad?

La velocidad se mide en las mismas unidades que las estimaciones de características, ya sean puntos de la historia, días, días ideales u horas que entrega el equipo Scrum, todos los cuales se consideran aceptables.

¿Cómo se estima la velocidad de la primera iteración?

Para la primera iteración de un equipo ágil, una pauta general es planificar la velocidad inicial en un tercio del tiempo disponible. Si está estimando el tiempo ideal del programador, esto representa reuniones, correo electrónico, diseño, documentación, reelaboración, colaboración, investigación, etc. Por ejemplo, con seis programadores e iteraciones de dos semanas, un total de 60 programadores-días (6 programadores x10 días) están disponibles. En esta situación, un buen comienzo sería planificar 20 días ideales de trabajo en la iteración. Si usa el tiempo real, incluya una cantidad suficiente de un búfer para tener en cuenta el proyecto estándar 1) los gastos generales y 2) la inexactitud de la estimación. Además, recuerde que la velocidad surgirá rápidamente durante la primera iteración. Si se subestima, la velocidad en la primera iteración aumentará a medida que se incluyan nuevas características; y si se sobreestima, la velocidad disminuirá a medida que se eliminen las características. Para la segunda iteración, el equipo de scrum debe usar la primera iteración como guía.

¿Las reuniones, las llamadas telefónicas y el correo electrónico se incluyen en la velocidad?

Esto depende de si estos elementos se estiman e incluyen en el planes de iteración. Por lo general, no se incluyen: un objetivo de velocidad es la coherencia relativa y la previsibilidad entre iteraciones en términos de la capacidad de entrega de un equipo ágil.

¿Debe acumularse la velocidad en todos los equipos o proyectos de desarrollo ágil?

La velocidad es en gran medida una medida localizada. Además de los diferentes miembros del equipo con diferentes "personalidades" del equipo, los proyectos suelen poseer características únicas en términos de técnicas de estimación, proceso de detalle, tecnología, participación del cliente, etc. Como resultado, esto puede hacer que el análisis de toda la organización sea muy inexacto. Si, por otro lado, todos sus equipos estiman exactamente lo mismo, desarrollan exactamente lo mismo, prueban exactamente lo mismo y rastrean exactamente lo mismo, entonces, por supuesto, tal vez usted sea la excepción.

¿Qué pasa si la velocidad fluctúa?

La velocidad normalmente fluctuará dentro de un rango razonable, lo cual está perfectamente bien. Si la velocidad fluctúa ampliamente durante más de una o dos iteraciones, es posible que el equipo de scrum deba volver a estimar y/o renegociar el release plan.

¿Cuánto tiempo tarda en estabilizarse la velocidad?

Para la mayoría de los equipos de desarrollo ágil, la velocidad normalmente se estabilizará entre 3 y 6 iteraciones.

¿Cómo calculo futuras iteraciones?

Las iteraciones futuras utilizan el historial probado del equipo para determinar cuánto puede hacer el equipo. Por lo tanto, la velocidad es la medida adecuada para planificar iteraciones futuras.

¿Cómo calculo la velocidad si los equipos de proyecto cambian de tamaño?

Velocity se basa en la consistencia del equipo para ser más valioso. Si su equipo ágil cambia, use el sentido común al planificar iteraciones futuras. Si el 20% de su equipo no está disponible para un par de iteraciones, reduzca la velocidad planificada en un 20% más o menos. Si esto incluye un par de jugadores clave, en particular un cliente que puede estar menos disponible, reduzca un poco más la estimación. Solo tomará la duración de la próxima iteración comprender mejor lo que el equipo puede ofrecer y, por lo tanto, su nueva velocidad.

¿Velocidad máxima significa productividad máxima?

Absolutamente no. En un intento por maximizar la velocidad, un equipo puede, de hecho, lograr lo contrario. Si se le pide que maximice la velocidad, un equipo puede escatimar en pruebas unitarias o de aceptación, reducir la colaboración del cliente, omitir la corrección de errores, minimizar la refactorización o muchos otros beneficios clave de las diversas prácticas de desarrollo ágil. Si bien ofrece potencialmente una mejora a corto plazo (si puede llamarlo así), habrá un impacto negativo a largo plazo. El objetivo no es la velocidad maximizada, sino la velocidad óptima a lo largo del tiempo, que tiene en cuenta muchos factores, incluida la calidad del producto final.

¿Cómo medimos la velocidad si nuestras longitudes de iteración cambian?

No lo haces, al menos no tan fácilmente. El valor de Velocity proviene de su consistencia inherente. Una duración de iteración fija ayuda a impulsar el ritmo confiable de un proyecto. Sin este ritmo, está constantemente revisando, reestimando y reconciliando, y la capacidad de predecir el futuro se minimiza debido a resultados inconsistentes. Si, por otro lado, casi todo el mundo va a estar fuera una semana para las vacaciones o un par de días para reuniones de toda la empresa, entonces simplemente use el sentido común y adapte las fechas de iteración o la velocidad en consecuencia. Como la mayoría de las prácticas ágiles, estas son pautas, no reglas.