Existen algunas pautas sencillas para estimar la velocidad inicial de tu equipo Scrum antes de completar la primera iteración (consulta las preguntas frecuentes a continuación), pero a partir de ese momento, debes utilizar métricas históricas comprobadas para la planificación de funcionalidades. En poco tiempo, la velocidad suele estabilizarse y proporciona una base sólida para mejorar la precisión y la fiabilidad de la planificación a corto y largo plazo de tus proyectos ágiles. Entrega ágil Los ciclos son muy cortos, por lo que la velocidad emerge rápidamente y puede validarse muy pronto en un proyecto, para luego utilizarse como referencia para mejorar la predictibilidad del mismo.
¿Es la velocidad realmente tan simple?
sí lo esNo intentes complicar demasiado el concepto de velocidad; en realidad es un concepto sencillo y gran parte de su valor reside en su simplicidad inherente. Muchos gerentes y equipos nuevos en métodos ágiles Suelen sobreanalizar el concepto de velocidad y añadirle demasiada complejidad. Tras unos meses de experiencia en proyectos ágiles, la mayoría tendrá una revelación sobre la velocidad, liberándose de cualquier prejuicio que tuvieran al respecto y apreciando su simplicidad y valor intrínseco.
Gráficos de velocidad
Junto con los gráficos de avance de iteraciones y lanzamientos, medir la velocidad de los equipos ágiles ha demostrado ser una herramienta muy útil para comprender el progreso y el estado de los proyectos. Un gráfico de velocidad muestra la suma de las estimaciones del trabajo entregado en todas las iteraciones. Por lo general, la velocidad se estabiliza durante la vida útil de un proyecto, a menos que la composición del equipo varíe considerablemente o la duración de la iteración cambie. Por lo tanto, la velocidad puede utilizarse para la planificación futura. Si bien suele ser fiable para las próximas iteraciones, teniendo en cuenta que las prioridades, los objetivos y los equipos pueden cambiar con el tiempo, y por ende, el nivel de confianza en una iteración futura, la velocidad puede utilizarse para planificar lanzamientos a largo plazo.
Inicialmente, los equipos que se inician en el desarrollo ágil de software deberían simplemente comenzar y seleccionar una velocidad inicial utilizando las guías e información disponibles. La velocidad se puede medir y ajustar rápidamente (tan pronto como en la siguiente iteración). La velocidad, junto con características específicas (como historias de usuario, backlog, requisitos, etc.) y estimaciones generales o relativas (en puntos, días ideales o incluso horas), simplifica y acelera enormemente todo el proceso de planificación, estimación, seguimiento del estado y elaboración de informes del proyecto.
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 las 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 funcionalidades, ya sean puntos de historia, días, días ideales u horas que el equipo Scrum entrega; todas estas unidades se consideran aceptables.
¿Cómo se estima la velocidad de la primera iteración?
Para la primera iteración de un equipo ágil, una recomendación general es planificar una velocidad inicial equivalente a un tercio del tiempo disponible. Si se estima el tiempo ideal de un programador, esto incluye reuniones, correo electrónico, diseño, documentación, retrabajo, colaboración, investigación, etc. Por ejemplo, con seis programadores e iteraciones de dos semanas, se dispone de un total de 60 días-programador (6 programadores x 10 días). En este caso, un buen punto de partida sería planificar el equivalente a 20 días ideales de trabajo en la iteración. Si se utiliza el tiempo real, se debe incluir un margen suficiente para cubrir los gastos generales habituales del proyecto y la posible imprecisión en las estimaciones. Además, es importante recordar que la velocidad se definirá rápidamente durante la primera iteración. Si se subestima, la velocidad en la primera iteración aumentará a medida que se incluyan nuevas funcionalidades; y si se sobreestima, la velocidad disminuirá a medida que se eliminen funcionalidades. Para la segunda iteración, el equipo Scrum debe utilizar la primera iteración como referencia.
¿Se incluyen las reuniones, las llamadas telefónicas y los correos electrónicos en la medición de la velocidad?
Esto depende de si estos elementos se estiman y se incluyen en el planes de iteraciónNormalmente no se incluyen; uno de los objetivos de la velocidad es la consistencia y la predictibilidad relativas entre iteraciones en términos de la capacidad de un equipo ágil para realizar entregas.
¿Debería acumularse la velocidad en todos los equipos o proyectos de desarrollo ágil?
La velocidad es una medida muy localizada. Además de las distintas personalidades de los miembros del equipo, los proyectos suelen tener características únicas en cuanto a técnicas de estimación, procesos detallados, tecnología, participación del cliente, etc. Por consiguiente, esto puede hacer que los análisis a nivel organizacional sean muy imprecisos. Si, por el contrario, todos sus equipos estiman, desarrollan, prueban y realizan el seguimiento de la misma manera, entonces, sin duda, usted podría ser la excepción.
¿Qué ocurre si la velocidad fluctúa?
La velocidad normalmente fluctuará dentro de un rango razonable, lo cual es perfectamente aceptable. Si la velocidad fluctúa ampliamente durante más de una o dos iteraciones, el equipo Scrum podría necesitar reestimar y/o renegociar la velocidad. plan de lanzamiento.
¿Cuánto tiempo tarda la velocidad en estabilizarse?
Para la mayoría de los equipos de desarrollo ágil, la velocidad normalmente se estabilizará entre 3 y 6 iteraciones.
¿Cómo puedo estimar las iteraciones futuras?
Las iteraciones futuras utilizan el historial comprobado del equipo para determinar su capacidad. Por lo tanto, la velocidad es la medida adecuada para planificar las iteraciones futuras.
¿Cómo puedo estimar la velocidad si los equipos de proyecto cambian de tamaño?
La velocidad depende de la consistencia del equipo para ser realmente valiosa. Si tu equipo ágil cambia, usa el sentido común al planificar las iteraciones futuras. Si el 20 % del equipo no está disponible durante un par de iteraciones, reduce la velocidad planificada en un 20 % aproximadamente. Si esto incluye a miembros clave, en particular a un cliente que podría tener menor disponibilidad, reduce la estimación aún más. Solo la duración de la siguiente iteración te permitirá comprender mejor qué puede entregar el equipo y, por lo tanto, su nueva velocidad.
¿La velocidad máxima implica la productividad máxima?
En absoluto. En un intento por maximizar la velocidad, un equipo puede lograr justo lo contrario. Si se le pide que maximice la velocidad, puede descuidar las pruebas unitarias o de aceptación, reducir la colaboración con el 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 esto podría ofrecer una mejora a corto plazo (si es que se le puede llamar así), tendrá un impacto negativo a largo plazo. El objetivo no es maximizar la velocidad, sino lograr una velocidad óptima a lo largo del tiempo, lo cual considera muchos factores, incluida la calidad del producto final.
¿Cómo medimos la velocidad si cambian las longitudes de nuestras iteraciones?
No, al menos no tan fácilmente. El valor de la velocidad reside en su consistencia inherente. Una duración fija de iteración ayuda a mantener un ritmo fiable en el proyecto. Sin este ritmo, se está constantemente revisando, reestimando y conciliando, y la capacidad de predicción se reduce al mínimo debido a la inconsistencia de los resultados. Si, por otro lado, casi todos van a estar ausentes una semana por las vacaciones o un par de días por reuniones de toda la empresa, entonces, por supuesto, basta con usar el sentido común y adaptar las fechas de iteración o la velocidad en consecuencia. Como la mayoría de las prácticas ágiles, estas son directrices, no reglas.
