Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Horas. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Horas. Mostrar todas las entradas

miércoles, noviembre 02, 2016

Planear sprints en horas y no por puntos


Hace algunos días nuestro amigo Carlos Jaramillo nos preguntaba a algunos colegas si estábamos de acuerdo con el legendario Mike Cohn cuando dice que los sprints deberían planearse con horas y no con puntos. Carlos se refirió específicamente al artículo Why Sprints Should Be Planned with Hours, Not Points (Por qué los sprints deberían planearse con horas, no con puntos).

Como lo dice Cohn al inicio de su artículo, para mí y creo que para muchos de los que hemos leído su libro Agile Estimating and planning (Estimación y Planificación Ágil) fue una sorpresa cuando vimos el título ya que sabemos que él es un gran referente y promotor de los puntos de historia y de su uso. Pero pasemos a la que fue mi respuesta entonces:

¡Estoy de acuerdo!

En particular, estoy de acuerdo con Mike cuando dice que “los puntos (de historia) son demasiado imprecisos para ser útiles en el corto plazo”, es decir, en un sprint de menos de un mes. También me gustaría destacar aquello de que la velocidad, aunque ligeramente, puede variar de sprint a sprint.

Además de lo que dice Cohn en su artículo algunas otras razones me llevan a pensar así:

No hay una correlación directa entre puntos de historia y el esfuerzo de implementación de la historia de usuario. Es decir, no existe tal regla o ley que señale que si un punto de historia toma H horas implementarse, N puntos de historia tomarán N x H horas implementarse (por ejemplo: si la implementación de una historia de un (1) punto toma 25 horas, entonces la implementación de una historia de 2 puntos tomará 50 horas, no).

Es probable, eso sí, que al final, después de muchos sprints, el promedio muestre tendencia hacia esos números, pero nada evita, en el escenario propuesto, que una historia de 2 puntos le tome al equipo 15 horas y otra también de 2 puntos le tome 35 horas para implementarla o cualquier otro número, incluso podríamos tener una historia de 2 puntos cuya implementación tome 10 horas o menos. En cualquier caso, eso apenas sería la tendencia natural.

Además, aun con ritmo sostenido y con entrega de valor constante en cada sprint, no es lo mismo un equipo en el primer sprint del proyecto que en el séptimo o en el décimo noveno. No es lo mismo un equipo en abril que en septiembre o en diciembre. No es lo mismo un equipo si el proyecto va bien desde varios puntos de vista, como el valor entregado, la calidad, el consumo de presupuesto, etcétera, o si va regular o mal; y no es lo mismo si el equipo y aun la organización a la que pertenece han estado mejorando continuamente o si su crecimiento personal y profesional se ha estancado por acción del proyecto.

Todos esos factores que acabo de mencionar impactan positiva o negativamente la motivación del equipo y por consiguiente, el rendimiento de los miembros del equipo. Lo que finalmente se traduce en número de horas de esfuerzo necesarias para implementar una historia, o sea, para llevarla de ‘Propuesta’ o ‘En proceso’ a ‘Terminada’.

La misma calidad y el tamaño de las historias de usuario también afectan de una forma u otra el esfuerzo requerido para su implementación. Me refiero a la calidad con que son comunicadas al equipo por el Dueño de Producto o por quien corresponda, así también perturba de manera distinta una historia de 2 puntos que una de 5 o una de 8.

Y todo esto para concluir que en cada Planificación de Sprint se debe hacer el ejercicio de, precisamente, planear por horas de esfuerzo, de eso se trata esta ceremonia inicial de Scrum después de todo. La gran diferencia con la planificación de los métodos tradicionalistas es que no vamos a planear seis meses de trabajo o un año o dos, no, se trata solo de adelantarnos a lo que va a pasar en las próximas 2 semanas de trabajo, quizás tres.

Nuestros equipos deben o deberían tener el conocimiento y la experiencia para decirle al Dueño de Producto y al mismo Scrum Master, al final de la Planificación, cómo intentarán hacer su trabajo en el sprint que comienza y eso incluye contarnos el número de horas de esfuerzo que tomará implementar una historia de usuario en particular. Se trata es de dilucidar cuando nos tomará el diseño, la programación, las pruebas, la integración, la documentación y cualquier otra actividad concerniente a la construcción de la historia. Después de todo, para eso fue que precisamente se conformó el equipo.

¡Pero hay más!

Usamos Puntos de Historia para estimar el backlog y el esfuerzo a mediano y largo plazo porque son o representan un valor abstracto. También sabemos que es posible usar otros métodos abstractos de estimación como 'tallas de camisetas', días ideales, colores, tamaño de los planetas o, incluso como dice mi amigo Jorge Abad en sus Lecciones Aprendidas, podemos usar la técnica del ‘ojo de buen cubero’, estimar con Garrapatandamandapispuntos o con cualquier otra medida cuyas convenciones sean bien conocidas por todo el equipo.

El precepto fundamental aquí es que todos estos métodos producen estimados y los estimados, sobre todo en software, están condenados al error. Casi 50 años de experiencias después de aquella remota conferencia de la OTAN en Garmisch en la que de alguna manera se dio vida a la Ingeniería de Software nos han demostrado eso.

En cualquier caso para estos escenarios de mediano/largo plazo, si un usuario o cliente está exigiendo estimar en horas un proyecto Ágil, todavía no ha entendido el enfoque y necesita guía en ese sentido. Las horas son algo concreto sí, pero solo para lo que he explicado arriba, estimar un sprint corto o muy corto, de muy pocos días a dos semanas.

Pero igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones. Así que en vez de salir corriendo detrás de las horas, deberíamos enfocarnos en habilitar y empoderar nuestros equipos para que hagan un mejor trabajo.
----------
¿Ustedes qué creen? ¿Cómo estiman los sprints? Déjenmelo saber en el foro - la sección de comentarios más abajo.


----------
Más sobre Planificación en:



El artículo de referencia de Mike Cohn lo pueden encontrar en: