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).

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