¿Qué es la estimación ágil?

Ya sea que un equipo esté desarrollando un producto o un proyecto, necesitamos responder: ¿cuándo podremos completarlo? o ¿hasta qué punto podremos entregarlo en un momento determinado? Al igual que en los modelos tradicionales de desarrollo, necesitamos estimar la carga de trabajo antes de comenzar un proyecto.

La estimación ágil tiene las siguientes tres características:

Estimación colaborativa del equipo

En Scrumel desarrollo, el equipo comparte la responsabilidad y trabaja colectivamente hacia cada Sprint. Por lo tanto, los equipos ágiles utilizan técnicas de estimación colaborativa para estimar la carga de trabajo. La estimación colaborativa suele utilizar el Planning Poker como herramienta, en la que el equipo juega un juego de estimación colectivamente. El Planning Poker se considera una de las técnicas más efectivas y atractivas para estimar el esfuerzo en ágilel desarrollo. Consiste en un conjunto de números similares a los de Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 20, 40, ?, ∞. Cada baraja incluye cuatro conjuntos de estos números de Fibonacci, diseñados para ser utilizados por hasta cuatro miembros del equipo.

Precisión de la estimación grupal frente a la individual

Un estudio sobre la precisión de la estimación del esfuerzo entre individuos y grupos en un experimento de proyecto de software reveló que 20 profesionales de software de la misma empresa estimaron por separado el esfuerzo necesario para implementar el mismo proyecto de software. Los participantes tenían diferentes antecedentes y roles, y el proyecto de software ya había sido implementado anteriormente. Más tarde, se agruparon en cinco equipos. Cada equipo discutió y combinó sus conocimientos para llegar a una estimación única.

Resultado: Las estimaciones basadas en la discusión grupal fueron más precisas que las estimaciones individuales.

Pasos para jugar Planning Poker

1. Cada miembro del equipo recibe un conjunto de cartas que contienen: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, ?, ∞ — un total de 12 cartas.
2. El Product Ownerlee la descripción de la historia de usuario o característica al equipo.
3. Los miembros del equipo discuten la característica y hacen preguntas al Product Owner si es necesario.
4. Después de la discusión, cada miembro selecciona una carta que representa su estimación y la revela al mismo tiempo.
5. Si las estimaciones difieren significativamente, el equipo discute: ¿Estamos de acuerdo? ¿Qué factores se pasaron por alto? La persona con la estimación más alta o más baja debe explicar su razonamiento antes del siguiente round de votación.
6. Después de la discusión, el equipo puede pasar por otra ronda hasta alcanzar un consenso.
7. Vuelva al paso 2 y comience a estimar el siguiente elemento de la lista de pendientes.

Estimar tamaño, no tiempo — usar estimación relativa en lugar de estimación absoluta

La estimación es simplemente una suposición fundamentada. Utilizamos todo el conocimiento y experiencia disponible para estimar cuánto tiempo tomará. En lugar de evaluar cada nuevo elemento de trabajo de forma aislada, ¿por qué no compararlo con elementos previamente completados? Los seres humanos son mejores para relacionarse con objetos de tamaño similar que para adivinar tamaños absolutos.

Por ejemplo: ¿es parecido a este objeto muy pequeño? ¿O más bien como este proyecto de tamaño medio? ¿O verdaderamente grande, como el que completamos el mes pasado? La estimación relativa no solo reduce el tiempo dedicado a la estimación, sino que también mejora significativamente la precisión.

Nuestros cerebros no son buenos para la estimación absoluta — siempre relacionamos las nuevas cosas que necesitamos estimar con lo que ya conocemos.

Estimación de puntos de historia

Estimación de velocidad — Registro y promedio de la velocidad del equipo por sprint

La velocidad del equipovelocidades el número depuntos de historiaelequipo Scrumrealmente completa en un sprint. La velocidad del equipo te indica con qué rapidez trabaja el equipo. Para un proyecto nuevo o un equipo (sin registros previos de velocidad), podemos realizar 1-2 sprints para medir y establecer una velocidad inicial. Durante la ejecución del sprint, registramos la velocidad del equipo en cada sprint para planificación futura.

Estimación de la velocidad de la historia de usuario

Estimamos el número total de puntos de historia en elProduct Backlog. Conociendo la velocidad promedio por sprint, podemos calcular cuántos sprints se necesitan para completar el proyecto — estimando así la duración del proyecto. Como se muestra en la figura a continuación.

Estimación de la duración del proyecto Scrum