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, sólo me centraré en las técnicas más populares y que están más en sintonía con el enfoque ágil. 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. Si bien estos libros son muy interesantes, considero que en la práctica aún quedan cuestiones por resolver, y esto es precisamente lo que me ha motivado escribir este post.

Estimar el esfuerzo asociado cada ítem de trabajo antes de abordarlo es en sí un esfuerzo y debería ser rentabilizado. A continuación se indican algunos beneficios que podríamos obtener de la estimación de ítems.
    • Establecer un plan coherente en cuanto a equilibrar esfuerzo requerido versus Capacidad del equipo para abordarlo en un determinado tiempo.
    • Prever decisiones, alternativas y/o desafíos asociados a dicho trabajo. Al estimar siempre, en alguna medida, estamos adentrándonos en el conocimiento del ítem.
    • Tener un factor adicional para considerar al momento de seleccionar trabajo. Por ejemplo, realizar cuanto antes un trabajo porque requiere muy poco esfuerzo, o buscar el momento adecuado para llegar a cabo un trabajo que requiere 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. 
    Siguiendo un enfoque ágil, para la estimación del esfuerzo tenemos varias alternativas. El equipo de trabajo, para CADA uno de sus líneas de trabajo, debería elegir la alternativa de estimación que mejor se ajuste. A continuación se comentan algunas alternativas o aspectos que deben considerarse.
    1. NO estimar. Si no existe compromiso de entrega o si éste es flexible podemos permitirnos no estimar el trabajo. El contexto más sencillo para el el enfoque ágil es aquel donde el equipo de tiene una estrecha colaboración con el cliente, y cuando se presentan cambios en los requisitos, el cliente entiende y acepta las modificaciones respecto de lo previsto. En este contexto ideal, las ventajas de estimar se diluyen puesto que, si bien pueden existir entregas frecuentes, ellas pueden modificarse sobre la marcha en cuanto a su alcance, plazos o recursos. Así, el plan se transforma en una hoja de ruta sin constituir un compromiso cerrado. Por otra parte, si no se trabaja en el marco de Sprints o Proyecto sino que el trabajo se aborda según va llegando (priorizándolo respecto del trabajo pendiente), la necesidad de estimar se hace prescindible. En caso de NO estimar, ya no hay que tomar más decisiones al respecto :-).
    2. Estimar "a ojo". Si existe un compromiso flexible se puede hacer una estimación superficial del esfuerzo en conjunto del trabajo que se pretende abordar. Correspondientemente, dicho esfuerzo intuitivo puede contrastarse con la capacidad del equipo (percibida informalmente). Esto básicamente es preguntarse si podemos o no abordar un cierto conjunto de trabajo para un determinado tiempo de entrega. Si bien esta alternativa no ofrece una argumentación cuantitativa para establecer un compromiso, para un equipo experimentado puede ser bastante certera. Buscando siempre la sencillez, si esta alternativa es suficientemente efectiva no habría que descartarla.
    3. Estimar usando alguna unidad de medida para el esfuerzo. Las unidades más usadas son Puntos, y Horas Ideales. La unidad de estimación del esfuerzo debe ser la misma que se utilice para medir la Capacidad del equipo. Los Puntos son una medida de tamaño relativa entre ítems de trabajo, es decir, se establece un ítem de referencia con ciertos Puntos y el resto de ítems se valoran en Puntos comparándolo con el ítem de referencia. Los Puntos son una valoración global del tamaño asociado a un ítem de trabajo, es decir, no diferencian esfuerzo en las diferentes actividades que deben realizarse sobre un ítem. Las Horas Ideales son horas ininterrumpidas de trabajo, no coincidirán con las horas cronológicas u horas de contrato. Por ejemplo, 8 horas ideales puede que se realicen en varios días de trabajo, aunque la persona encargada por contrato trabaje 8 horas diarias. Un programador con un contrato de 40 horas por semana, posiblemente no llegará a programar mucho más de 30 horas netas por semanas, con lo cual éstas serían su Horas Ideales de programación por semana. Las Horas Ideales, a diferencia de los Puntos, conviene que se asocien a un determinada actividad. Usando Horas Ideales, la Capacidad de un equipo se puede medir, por ejemplo, en Horas Ideales de programación por semana. Así pues, si tenemos un conjunto de ítems de trabajo que se estima que suman 500 Horas Ideales de programación, y tenemos un equipo con una Capacidad de alrededor de 200 horas de programación por mes, podríamos afirmar que dicho trabajo se podría abordar en alrededor de 3 meses (considerando un margen de holgura de medio mes). Cuando se usan Horas Ideales podríamos tener estimaciones para cada actividad por la que pasará un ítem, por ejemplo, análisis, diseño, programación, pruebas, etc. Correspondiente mente la Capacidad del equipo podría estar descompuesta en cada una de dichas actividades. Sin embargo, el esfuerzo asociado a conseguir este detalle probablemente no aportará mayor precisión ni utilidad. Mi recomendación es centrarse en una actividad (o poco más), aquella que suela ser la más limitante en el proceso de los ítems, en aquella que suele faltar capacidad del equipo. Por ejemplo, en desarrollo de software recomiendo usar de partida la estimación y la Capacidad referida a la actividad de Programación. 
    4. Seguimiento basado en estimaciones. Una vez iniciado el trabajo, las estimaciones nos pueden ayudar a monitorizar el progreso del trabajo. La pregunta clave del seguimiento es ¿llegaremos a cumplir nuestro compromiso?, y en cualquier momento el equipo podría responderla contrastando la estimación del trabajo restante con su Capacidad desde ese momento hasta la fecha de entrega. En caso de utilizar Puntos el esfuerzo restante es la suma de Puntos de todos los ítems no terminados. Hay que destacar que en este caso los Puntos de un ítem se descuentan solo cuando el ítem está terminado, es decir, no se hacen descuentos parciales. No tiene sentido preguntarse cuántos Puntos quedan para terminar un ítem. En caso de usar Horas Ideales el esfuerzo restante puede establecerse de dos formas:  a) como la diferencia entre el esfuerzo estimado y el esfuerzo ya invertido, o b) como el esfuerzo estimado restante establecido en cada momento. Por ejemplo, si un ítem se estimó en 10 Horas Ideales de programación y ya se han invertido 6 horas, se esperaría que el esfuerzo restante sea de 4 Horas Ideales de programación. La otra alternativa es que al finalizar una jornada de trabajo si se estuvo trabajando en un ítem y no se terminó, se haga una estimación de las Horas Ideales restantes para terminarlo. En cualquier caso, la re-estimación de ítems es importante, si en cualquier momento se sospecha que una estimación no es apropiada debe actualizarse. En el enfoque ágil el seguimiento cuantitativo de un compromiso de trabajo se visualiza utilizando una Gráfica Burndown
    5. Estimar ítems de trabajo y/o tareas asociadas al ítem. Debe decidirse si la estimación se llevará sólo a nivel de los ítems de cambios acordados con el cliente (p.e. Historias de Usuario) o también se computará a nivel de tareas (unidades en las cuales el equipo 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 tareas, normalmente tampoco es necesario puesto que si los ítems son pequeños pierde sentido el dividirlos aún más. Trabajar con dos niveles de estimación (ítem y tareas del ítem) complicará la gestión, especialmente cuando el número de ítems y/o tareas es alto. Además, al trabajar en estos dos niveles, debería mantenerse coherencia entre la estimación de ítem y la suma de estimaciones de sus tareas. 
    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 equipo que ejecutará el trabajo, de forma individual o consensuada con todo el equipo de desarrollo (p.e. usando la técnica Planning Póker).

    2 comentarios:

    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!!

      ResponderEliminar
    2. 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