sábado, 10 de diciembre de 2011

Estimación en un proyecto ágil, Parte I: Una estrategia pragmática

Esta figura representa lo que se denomina el "Cono de la Incertidumbre" e ilustra cómo la variabilidad en las estimaciones de esfuerzo se va reduciendo en la medida que nos adentramos en la implementación.

Este post no pretende ser un tratado de la estimación en proyectos de desarrollo de software, sino que sólo me centraré en las técnicas más populares y que parecen estar más en sintonía con los métodos ágiles. Para tener una visión global de estimaciones en proyectos de software recomiendo el libro Software Estimation de Steve McConnell y en el caso específico de métodos ágiles mi sugerencia es el libro Agile Estimating and Planning de Mike Cohn. Desafortunadamente, en la práctica aún quedan cuestiones por resolver y eso es precisamente lo que me ma motivado escribir este post.

Estimar el esfuerzo asociado cada ítem de trabajo antes de abordarlo es en sí un esfuerzo y requiere disciplina, todo lo cual debería ser rentabilizado. A continuación se indican algunos beneficios que podría ofrecer la estimación de ítems.
    • Prever decisiones, alternativas y/o desafíos asociados a dicho trabajo
    • Establecer un plan coherente en cuanto a equilibrar esfuerzo requerido versus capacidad del equipo para abordarlo en un determinado tiempo.
    • Tener un factor adicional para considerar al momento de seleccionar trabajo para abordar. Por ejemplo, realizar cuanto antes trabajo que requiera muy poco esfuerzo, o buscar el momento adecuado para llegar a cabo un trabajo que requiera mucho esfuerzo.   
    • Realizar el seguimiento del trabajo restante, contrastando el progreso del trabajo respecto de la estimación, o simplemente descontando el esfuerzo estimado de un ítem una vez éste se haya terminado.
    La estimación del esfuerzo en métodos ágiles presenta aspectos en los cuales no existe un total consenso. El equipo de trabajo debería, para CADA uno de los producto productos o servicios de los cuales está encargado, tomar una decisión respecto de los siguientes aspectos:
    1. ¿Se estimará?. ¿Es de utilidad realizar estimaciones en el ámbito de trabajo del producto o servicio?. En caso de NO ser necesario estimar, ya no hay que tomar ninguna de las siguientes decisiones :-).El contexto ideal para el agilismo es aquel donde el equipo de desarrollo tiene una estrecha colaboración con el cliente, en el cual, si existen cambios en los requisitos del producto, el cliente entiende y acepta probables modificaciones del alcance inicialmente acordado. Pues en este contexto ideal, las ventajas de estimar se diluyen puesto que si bien existen entregas frecuentes, ellas pueden modificarse sobre la marcha en cuanto a su alcance, es decir, el éxito está asegurado puesto que, acercándose a una entrega el equipo puede acordar con el cliente quitar alcance sin que esto signifique necesariamente un fracaso en cuanto a sus expectativas. El plan se transforma en una hoja de ruta sin constituir un compromiso cerrado. Por otra parte, si no se trabaja con sprints o entregas si no que el trabajo se atiende según va llegando (priorizándolo respecto del trabajo pendiente), tal como se propone en el método Kanban, la necesidad de estimar se hace menos necesaria.
    2. Debe seleccionarse la unidad de medida para el esfuerzo, las más usadas son Tallas (S,M,L,XL), Puntos, y Horas Ideales (horas de trabajo sin interrupción). En cada cada, la elección conlleva que la capacidad del equipo deberá establecerse usando la misma unidad. En ese mismo orden, estimar con Tallas es lo más sencillo y rápido, en el otro extremo una estimación en Horas Ideales exige una reflexión más detenida respecto de qué trabajo debe realizarse al abordar el ítem. En cuanto al seguimiento, usar Tallas ofrece muy poco respecto a conocer cuánto es el trabajo restante en términos de suma de esfuerzo. El el caso de los Puntos si bien pueden sumarse para establecer, por ejemplo, que quedan X puntos de trabajo restante, se trata de una medida discreta, es decir, los puntos de un ítem no se restan hasta que el ítem está terminado, no tiene sentido hacer cálculos de cuántos puntos le quedan a un ítem una vez empezado. Las Horas Ideales sí que permiten dicha actualización de tiempo restante para terminar un ítem ya empezado. Otro elemento a considerar es la reconocida presión que ejerce sobre el equipo el tener que estimar en Horas Ideales y las típicas malas interpretaciones en cuanto a que no se corresponden con el tiempo cronológico ni contractual. Estimar en Tallas o Puntos evita dicha presión. Finalmente, 
    3. En caso que la unidad elegida para estimar sea Puntos u Horas Ideales, si además interesa llevar un seguimiento diario del esfuerzo restante, debe decidirse si dicho esfuerzo restante se irá registrando directamente (tal como se sugiere en Scrum), o si el esfuerzo restante se calculará en base a la diferencia entre la estimación y el esfuerzo invertido. En el primer caso, cada día el equipo debe actualizar el esfuerzo restante de todas los ítem que están empezados y no terminados. En el segundo caso, cada ítem tiene estimación y a esta se le resta el esfuerzo invertido para obtener el esfuerzo restante. En este último caso además hay que detectar cuándo la estimación inicial ya no es válida y re-estimar. El esfuerzo restante se presentaría en una Gráfica Burndown
    4. Debe decidirse si la estimación se llevará sólo a nivel de los cambios acordados con el cliente (p.e. Historias de Usuario) o también se computará a nivel de tareas de programación (unidades en las cuales el equipo de desarrollo puede descomponer dichos cambios, usualmente asociado a trabajo en partes de la arquitectura interna del producto). En términos generales sugiero NO dividir los ítems en unidades o tareas, normalmente tampoco es necesario puesto que si los ítems son pequeños pierde sentido el dividirlos aún más. Podría ser interesante usar tareas cuando un ítem sea grande (una Épica) y se haya decidido mantenerlo así, previendo que varias personas trabajarán en él en el momento de implementarlo. Trabajar con dos niveles de estimación resulta demasiado complicado en cuanto a su gestión, especialmente cuando el número de ítems y/o tareas es alto.
    5. Debe decidirse si se la estimación se hace para el ítem de trabajo como un todo (p.e para la Historia de Usuario) o para sus actividades (p.e. Programar, Testear, etc.). Siendo minimalista, cada ítem deberá ser Definido, Programado y Testeado (me refiero a pruebas de aceptación), o visto de otra forma, deberá ser Preparado (mientras está en el Backlog) e Implementado (cuando está en el sprint). Las actividades específicas que se realicen sobre el ítem dependerán del producto o servicio y del equipo, sin embargo, desde la perspectiva de la estimación, nos basta con disponer de estimación de las actividades que se realizarán durante el sprint (incluso de sólo algunas de ellas). Además, es interesante al menos hacer una separación de la estimación de Programación y de Testeo (pruebas de aceptación) pues lógicamente deberían hacerla diferentes miembros del equipo. 
    Una cuestión que parece estar consensuada es que en el contexto ágil la estimación se hace mediante "el juicio del experto", es decir, la decide el desarrollador, de forma individual o consensuada con todo el equipo de desarrollo (p.e. usando la técnica Planning Póker cuando la unidad utilizada es Puntos).

    Si bien la literatura asociada a estimación es bastante extensa, como es de esperar, no existen recetas generales. Para aquellos productos o servicios en los cuales sí que nos interesa gestionar el esfuerzo hemos tenido que abordar desafíos para que dicha gestión sea rentabilizada y se integre de forma apropiada dentro del método de trabajo del equipo. En este sentido en nuestra herramienta Tune-up hemos incluido toda la funcionalidad que hemos necesitado, permitiendo que cada producto tenga su propia estrategia de gestión del esfuerzo.

    Este post continua en "Estimación en un proyecto ágil: Parte II, Algunas diferencias respecto de estimación tradicional".

    Patricio Letelier

    linkedin.com/in/letelier
    agilismoatwork.blogspot.com
    www.tuneupprocess.com

    5 comentarios:

    1. Hola Patricio,
      Excelente post! Quiero escribir aqui porque tal vez pueda ayudarme. Actualmente estamos por comenzar un proyecto nuevo y nuestro cliente quiere un estimado a gran nivel (en semanas) de cuanto puede tardar el proyecto. Inicialmente le hemos comentado que nosotros trabajamos con metodologías ágiles, pero su respuesta fue: "Yo no conozco nada de eso. Por favor, traeme una estimacion de cuanto tiempo demorará el proyecto con todos estos requerimientos". Entonces, estoy en una situación en la que quisiera saber que opciones tengo para proveerle una estimación a alto nivel, basado en los requerimientos que me ha enviado.

      Que te parece que sea la mejor forma? Sinceramente, no quisiera invertir mucho esfuerzo en ver uno por uno los items en detalle para estimarlos en horas y obtener un número. Nosotros los hemos revisado y ahora estabamos listos para hacer un poker planning y definir los puntos, pero no tendré una forma de pasarlo a horas, dias y luego semanas, hasta que no pasen algunos sprints para que pueda saber cual es nuestra velocidad...

      Que me recomiendas para estos casos?

      Gracias desde ya!

      Jay

      ResponderEliminar
      Respuestas
      1. Hola Jay,

        Para un equipo ágil lo ideal (casi utópico) sería que no le pidan plazos y que sea el cliente, a lo largo del desarrollo, quien decida cuándo parar o suspender el trabajo. Sin embargo, no contar con ese escenario ideal no debería ser un problema insalvable.

        La clave está en que al principio del proyecto (y durante todo su desarrollo) tu Backlog esté ordenado, así los ítems que pronto vas a implementar estarán en los primeros lugares. Estos ítems deberían estar detalladamente especificados (ya que se implementarán en breve) y con lo cual para ellos no debería ser un problema el dar una estimación bien argumentada. Además esos primeros ítems del Backlog deberían a su vez ser los de más valor para el cliente y los de mayor riesgo para el equipo. A partir de allí el resto de ítems NO deben ser especificados en detalle hasta que no lleguen a ser los primeros en el Backlog. Aún así debes atreverte a dar una estimación para esto ítems posteriores, asumiendo una la incertidumbre por no tener una especificación detallada. Sin embargo, dado que estos ítems no serán los de mayor valor y/o riesgo su impacto en cuanto al posible error en la estimación no debería afectar el alcance del proyecto. Cuando los ítems vayan alcanzando las primeras posiciones del Backlog deberán ser especificados en detalle y en ese momento hay que revisar su estimación por si hubiese una diferencia respecto de su estimación inicial.

        La gestión de alcance hay que hacerla continuamente en el contenido del Backlog que sigue estando comprometido en los plazos del proyecto, con lo cual es vital que los ítems que se añadan al Backlog inmediatamente se ordenen y estimen.

        Finalmente, es recomendable que en la estimación de cada ítem no se sobreestime para tener cierta holgura, sino que existe un buffer a nivel de proyecto que permita gestionar de forma más eficiente los errores en la estimación de los ítems. Para esto te recomiendo mi post http://agilismoatwork.blogspot.com.es/2017/04/buffer-de-capacidad-para-proyectos.html.

        Un saludo y suerte!!

        Eliminar
    2. Gracias Patricio! Excelente información!
      Una preguntita más en cuanto a la estimación inicial que tengo que proveer, conoces alguna técnica que me permita realizar esa estimación de alto nivel?
      Gracias nuevamente,
      Javier

      ResponderEliminar
    3. Hola Jay,

      Mi recomendación para dicha estimación inicial es basarla en la especificación detallada de lo que se cogerá primero del Backlog y para el resto, que estará menos o nada especificado, basarse en la experiencia y comparación con datos de trabajos semejantes si se tienen. En cualquier caso entiendo que tendrías que conseguir un cálculo de Horas Ideales (por ejemplo centrándose en horas de programación) y contrastarlo con vuestra Capacidad teórica para conseguir el plazo previsto. Por ejemplo, si el proyecto se estima en 800 Horas ideales de programación y la Capacidad del equipo es de 200 horas de programación por mes, y considerando un buffer de 20% para absorber posibles cambios, el plazo propuesto sería de 5 meses. Para las estimaciones de las horas ideales de programación recomiendo hacer un planning póker con los desarrolladores, pero en este caso usando horas ideales de programación en lugar de puntos.

      Un saludo,

      ResponderEliminar
    4. Fantástico! Gracias Patricio! Ha quedado muy claro

      ResponderEliminar