Buscar en Gazafatonario IT

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:

15 comentarios:

  1. De colección este post estimado Lucho, quisiera ponerme en contacto contigo para escribir un libro... Pero en serio compa.. me encanta la claridad de este post.. sobre esto hay que discutir y seguir discutiendo, presentando y explicando.. por aca te dejo referencia a mi post.. gracias por citarme ... Leerte siempre es un gusto para el alma del agilista. Un abrazo

    ResponderBorrar
    Respuestas
    1. ¡Gracias Compa! Claro que sí, hay que seguir insistiendo en todo este asunto. Y gracias también por leerme :-)

      Borrar
  2. Lucho, creo que todo método es válido siempre y cuando el equipo adquiera la madures y destreza (Experiencia) en su utilización.
    Partiendo de un método X (Horas, puntos o puntos que representen tiempo o esfuerzo o lo que se quiera) por lo general las primeras planificaciones con dicho método tiende a errores (Sobre o bajo la línea del Burndown) y es con el paso del tiempo (Sprint tras sprint) en que este margen de error baja a su mínima expresión (aunque a veces te puede dar sorpresas), se obtiene estadísticas, la velocidad promedio etc, con las cuales se puede de alguna forma estimar (predecir) con base en dicha información y datos cuanto podría tardar lo que queda del backlog o de proyecto. Por lo anterior estoy de acuerdo con lucho en que "Igual que con los puntos estimar con horas no nos eximirá del error inherente a la estimación". Creo que independientemente del método la experiencia en su utilización dará buenos resultados y ojo no olviden experimentar puede que resulte que un método de estimación te de mejor resultados que otro y sea la hora de cambiar a otro ya sea de puntos a horas o de horas a puntos o a otro método.
    Un saludo lucho y gracias por el post muy interesante.

    ResponderBorrar
    Respuestas
    1. ¡Cesar, gracias por mantenerte en sintonía! En efecto, como dices también es asunto de experiencia. Después de todo, de eso se trata Scrum basado en la teoría del control empírico de procesos, aprendemos de la experiencia. Como dice el Doc Abad, "inspección y adaptación". ¡Celebro que te haya gustado el artículo!

      Borrar
  3. Yo en lo particular no recomiendo usar horas, hay mas estrés del equipo y del que tiene la tarea en hacerlo en lo que se indico en la plantación, hasta el momento en los equipos en los que he estado se han quitado y ha mejorado... el tema es que la complejidad no depende de la persona individual si no del equipo, las horas son mas concretas y son por lo general mas individualistas, el ejemplo que siempre uso es si quieres correr 1 km cuanto se demoraria cada miembro del equipo?... no todos van al mismo ritmo!!!

    ResponderBorrar
    Respuestas
    1. ¡Alexis, muchas gracias por estar en sintonía!
      No que queda muy claro el motivo por el cual dices que "las horas por lo general son más individualistas" pero creo que entramos en el ámbito del trabajo en equipo, de si este es multidisciplinario o no, entre otros aspectos. En cualquier caso, como ya he reiterado en otras ocasiones, apliquemos lo que nos sirve, experimentemos y aprendamos de los resultados. Saludos.

      Borrar
  4. Excelente articulo Lucho, rompiendo paradigmas, me queda varias cosas para el analisis, cuando hacemos el Planning utilizamos puntos y utilizamos por ejemplo Planing Poker con una secuencia como fibonacci donde la idea es que a medida que una historia sea mas grande es mas la incertidumbre y mas la probabilidad de errar la estimación y por ello el objetivo de fibonacci, al realizar estimaciones por horas deberian ser mas exactos y no se como manejariamos este tema de la incertidumbre, ademas en si mismo como realizariamos la estimación de manera colaborativa sin sesgar a personas del equipo.
    Por otro lado importante la mención que haces con respecto a los clientes que exigen estimaciones, un tema bastante complejo pero que hay que trabajar, sobre todo en ambientes donde aún los proyectos con los proveedores se estiman a costo fijo, es realmente un desafio.

    Un Saludo y gracias por el post

    ResponderBorrar
    Respuestas
    1. ¡Gracias, Carlos!
      Lo que planteas es muy a lugar. Fibonacci es muy buena práctica cuando estimamos todo el backlog o el proyecto a mediano y largo plazo. Sin embargo, recuerda que la práctica es que las historias de usuario a implementar en un sprint específico sean pequeñas y muy pequeñas lo que, entre otros beneficios, reduce la incertidumbre. Sobre este asunto de las historias puedes leer mi serie de artículos sobre Historias de usuario en bit.ly/lashistoriasdelucho. En particular, sobre el tamaño de las historias te recomiendo ampliamente mi artículo: ¡El tamaño sí importa! En este mismo Gazafatonario: http://www.gazafatonarioit.com/2016/06/el-tamano-si-importa.html
      Saludos,

      Borrar
  5. Hola Lucho. Pensando en las mejoras a largo plazo de los equipos, nos ha funcionado muy bien hacer estimación por puntos de esfuerzo, mas que por la misma estimación, por las discusiones que se generan entre los miembros del equipo cuando tratan de visualizar si una tarea es gigante, grande, mediana, pequeña, etc... Con el tiempo hemos visto que los miembros del equipo tienden a ser más analíticos y críticos a la hora de comprometerse con algún reto. Personalmente planear en horas me estresa un poco, uno por que me recuerda mi oscuro pasado jugando al vidente con los diagramas de Gantt y dos por que nos pone a pensar en que es más importante cumplir con el tiempo acordado que la solución en si. Me encanta como cierras el artículo puntualizando sobre el verdadero deber: " 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."

    ResponderBorrar
    Respuestas
    1. Interesante lo que dices, Alejandro, de cómo los miembros del equipo se han vuelto más analíticos y críticos. De eso se trata Ágil, de mejorar continuamente. Y si la forma de estimar ayuda, bienvenida. ¡Muchas gracias por la sintonía!

      Borrar
  6. Que experimentos formales han realizado para hacer tantas afirmaciones que rayan con lo absurdo? Definitivamente el movimiento ágil criollo es muy charro, nada serio, todo lo toman como si desarrollar software fuera arte o un cuenta chistes.

    ResponderBorrar
  7. Lucho digo individualista por que en el momento de estimar se penso x horas entre todos, pero cuando una persona lo adquiere o se compromete puede tardar más o menos que eso (casi siempre pasa), entonces algo estimado grupalmente al final se transforma en una ejecución relativa, inclusive, ya que realmente las personas no cogen cronometro y miden realmente cuanto tardo... Yo esto lo veo por el lado Lean y tambien por lo que he experimentado en equipos que es un desperdicio en la plantación y ejecución, inclusive retro por que nos quita tiempo hablando de como estimar mejor y no de como entregar valor

    ResponderBorrar
    Respuestas
    1. Un par de cosas me vienen a la cabeza con tu nota, Alexis: 1) el compromiso de los miembros del equipo debería ser "realizar el mejor trabajo posible, dar lo mejor de sí, en el tiempo que tienen disponibles", no el "cumplir con N historias de usuarios o P puntos de historia” o cosas así. De hecho, no es bueno usar el término “compromiso” cuando de estimaciones se trata, ese era el error que cometíamos antes, con el enfoque tradicional.

      2) Hablo de la estimación en el sprint. Una vez que hemos seleccionado con el Dueño de Producto o con quien corresponda (si no tenemos un equipo Scrum) una historia de usuario o elemento del backlog, el trabajo necesario para “construir” es elemento lo dividimos o fraccionamos en “tareas”. Por ejemplo:

      Diseñar la UX,
      Implementar la UX,
      Diseñar la base de datos,
      Implementar la base de datos,
      Integrar la funcionalidad,
      Probar la funcionalidad,
      Documentar,
      Integrar con el resto de la aplicación,
      Etcétera

      Son tareas relativamente pequeñas (de hecho ya la historia de usuario debió ser lo suficientemente pequeña como para que se pueda implementar en un sprint corto), que toman de entre algunos minutos a algunas horas. En este momento ya tenemos la suficiente y necesaria claridad sobre lo que significa la historia de usuario para realizar cada una de esas tareas. Entonces deberíamos estar en capacidad de hacer un estimado.

      Esta es la mejor forma de saber si el equipo todavía puede realizar más trabajo (seleccionar más elementos del backlog) en el sprint o si ya llegó al límite de su capacidad. Además, no veo cómo estimar por puntos cada una de estas tareas: por ejemplo, en una historia de 3 puntos, cuántos puntos corresponden a Diseñar la UX o cuántos puntos a Documentar o cuántos a programar cada uno de los métodos de los objetos necesarios para implementar los componentes.

      En breve, a este nivel de sprint, el equipo y sus miembros ya no discuten a nivel de puntos de historia o de velocidad. ¡Es tan solo un ejercicio de capacidad!

      Como siempre, enriquecedora tu participación en el foro. ¡Muchas gracias por tu contribución!

      Borrar