Descubrí cómo hacer una estimación ágil.
El equipo debe basar sus estimaciones en la realidad en lugar de suposiciones o ilusiones.
En los últimos meses recibí muchas consultas sobre qué herramientas conviene utilizar para realizar una estimación ágil y conversando con estas personas su principal inquietud venia dada que en sus planificaciones no estaban teniendo éxito con el cumplimiento de los objetivos que planteaban. Al indagar un poco mas sobre cómo lo iban haciendo descubrí que si bien utilizaban prácticas conocidas el problema venía por QUIENES las estaban realizando. Es por esto que decidí compartir este patrón conocido en el mundo de la agilidad muy útil para mejorar las estimaciones.
La principal premisa en que se basa la estimación ágil es el conocimiento y la experiencia del propio equipo (frente a otros métodos de estimación que se basan en la experiencia de otros equipos o expertos sobre un tema). Por ejemplo el marco Scrum se auto-denomina empírico y por ahí va la cosa.
A veces, cuando se llega un nuevo trabajo, un líder puede querer proteger al equipo del trabajo de estimarlo, y puede tomar la iniciativa de estimarlo él mismo. Al equipo le tomará bastante energía deshacer una estimación así, particularmente si un líder, el Product Owner u otra persona con autoridad o con poder sobre el equipo, impone la estimación al equipo.
Es posible que un equipo no se sienta responsable del trabajo atrasado cuando otros determinan las estimaciones, por lo tanto…
Dejar que las personas comprometidas con el trabajo real hagan la estimación. En el sentido de Scrum, son los cerdos los que estiman, no las gallinas.
Los términos cerdos (personas del equipo de desarrollo) y gallinas (todos los demás) nacen de la siguiente broma:
Una gallina y un cerdo están juntos cuando la gallina dice: “¡Empecemos un restaurante!”. El cerdo lo piensa y dice: “¿Cómo llamaríamos al restaurante?”. La gallina dice: “¡Jamón y huevos!”. El cerdo dice , “No, gracias, estaría comprometido, ¡pero tú solo estarías involucrado!”
Una estimación ágil debe ser un consenso generado desde las perspectivas de todas las áreas de desarrollo relevantes. La investigación muestra que las estimaciones son mucho mejores cuando se combinan estimaciones independientes, con iteración y retroalimentación de todos los que participan en el desarrollo. Dado que los equipos de desarrollo son multifuncionales, es posible que el equipo de desarrollo cree estimaciones muy buenas juntas.
El equipo se siente comprometido por su trabajo. Esto es bueno de por sí pero también aumentará el enfoque que el equipo aporta a sus esfuerzos de estimación. Además se obtiene mejores estimaciones a largo plazo si provienen de los desarrolladores.
El equipo de desarrollo debe revisar continuamente las estimaciones a medida que surja nueva información. El equipo puede estimar los elementos del Product Backlog recién creados a medida que trabaja con el Product Owner para crear una reserva de elementos refinados y es natural revisar las estimaciones en los eventos de Refinamiento y Sprint Planning.
En la mayoría de las aplicaciones de este patrón en Scrum, la estimación es solo un pronóstico y los stakeholders no deberían verlo como un compromiso. Por otro lado, a nadie más que a “los cerdos” se le permite hablar de estimación. Nunca debería haber un motivo para cuestionar una estimación a priori. Por ejemplo, los Product Owners no pueden imponer sus deseos de entrega en el pronóstico fundamentado del equipo sobre cuánto tiempo llevará el trabajo. Las percepciones empíricas de la experiencia a lo largo del tiempo ayudarán al equipo a ajustar sus estimaciones para ser más precisos.
Bibliografía de estimación ágil:
- Ken Schwaber and Mike Beedle. Agile Software Development with Scrum, p. 35.
- Mike Cohn. Agile Estimating and Planning, p. 51.
- Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile Process, p. 123.
- Magne Jørgensen. “What we Know about Software Development Effort Estimation.ˮ, p. 37-40.
- Ken Schwaber and Mike Beedle. Agile Software Development with Scrum, p. 42.
0 comentarios