h1

Agile Estimating and Planning

08/15/2012

Wizbook [Icon By Buuf]  Libros.

Si le dices a la gente a dónde ir, pero no cómo llegar hasta ahí, te sorprenderán los resultados.

George S. Patton (1885 – 1945), General militar norteamericano.

Agile Estimating and Planning de Mike Cohn es una de las lecturas más importantes de la bibliografía ágil que todo ScrumMaster, líder o practicante debería leer. Escrito por uno de los fundadores del Scrum Alliance, este libro posee herramientas cuantitativas concretas para estimar, planear, dar seguimiento y pronosticar el avance de un proyecto ágil. Dispersos en cada capítulo, se muestran ejemplos prácticos de los temas mostrados, indicando cómo poner en práctica las técnicas descritas en un proyecto real, incluyendo consejos basados en la experiencia del autor. Finalmente, el último capítulo nos muestra mediante un caso de estudio todos los conceptos manejados a lo largo del libro, demostrando cómo funciona la planeación ágil desde el levantamiento inicial de requerimientos hasta la fecha final de entrega.

Por qué falla la planeación tradicional

El primer capítulo da en el clavo: el 66% de los proyectos de desarrollo de software sobrepasan el costo inicial; el proyecto promedio excede en 100% el calendario original y el 64% de las características del producto terminado raramente o nunca son utilizadas. ¿Por qué ocurre esto? El autor nos da algunos puntos a considerar:

• Planeamos por actividad, no por característica. La planeación tradicional se basa en la finalización de actividades individuales, en vez de considerar la entrega de funcionalidad completa. Debido a la dependencia entre actividades, si una de éstas no se termina a tiempo, la latencia se disemina al resto del plan, terminando en un retraso general.

• Consideramos el multitasking como algo natural. Nada más lejos de la realidad: está científicamente comprobado que los seres humanos sólo podemos llevar a cabo dos tareas al mismo tiempo; a mayor número de tareas, menor la eficiencia debido al cambio de contexto. Si planeamos asumiendo que los desarrolladores podrán lidiar con cinco tareas simultáneamente, nos llevaremos un chasco al darnos cuenta que terminarán hasta un 24% más de lo que tomarían realizar secuencialmente estas tareas:

Multitasking vs. Productivity


Gráfica que muestra el porcentaje de tiempo dedicado de acuerdo al número de tareas concurrentes. La máxima productividad se alcanza al realizar dos tareas a la vez; con más de dos se pierde demasiado tiempo al hacer el cambio entre una tarea y otra. De acuerdo a la gráfica, si una tarea tarda 8 horas en realizarse, dos tareas equivalentes de manera concurrente se terminarían en 14 horas. Haciendo multitasking con tres tareas al mismo tiempo el tiempo total sería de 28 horas (contra 24 de realizarse secuencialmente), con cuatro tardaríamos 50 horas (vs. 32) y con cinco tardaríamos hasta 70 horas para un esfuerzo que secuencialmente tardaría 40 horas en terminarse. (Fuente: Codefriendly.com)

• Las características del producto no son priorizadas. Un problema al realizar una planeación por capas (por ejemplo: base de datos, lógica de negocio, interfaz de usuario) es que asumimos que todas las tareas se llevarán a cabo. Si llegamos a un punto crítico durante el desarrollo, el equipo terminará por dejar fuera la funcionalidad que tardaría más tiempo en implementarse, entregando funcionalidad incompleta por características más fáciles de realizar que probablemente el usuario jamás utilizará.

• Se ignora la incertidumbre. De acuerdo al autor, “…Ignoramos la incertidumbre acerca del producto y asumimos que el análisis de requerimientos condujo a una especificación completa del producto. Suponemos que los usuarios no cambiarán de opinión, no refinarán sus requerimientos ni tendrán nuevas necesidades durante el período cubierto por el plan.” De hecho, estadísticamente hablando, el tiempo final de duración de un proyecto siempre estará desfasado entre un -40% y un +60% de la estimación inicial.

• Las estimaciones se vuelven compromisos. Muchos líderes o gerentes de proyecto proporcionan una fecha de terminación parecida a “entregaremos todo alrededor del 30 de Septiembre” dando la apariencia que TODO quedará listo para el 30 de Septiembre, cuando hubiese sido más sabio decir “terminaremos entre el 15 de Septiembre y el 15 de Octubre”.

Para adaptarse y darle la vuelta a estos problemas, en ágil un proyecto es considerado como una sucesión de nuevas capacidades y conocimiento; las capacidades son aquello que puede plasmarse como trabajo terminado mientras que el conocimiento nos permite entender acerca del producto y el proyecto en sí. Esto se traduce en mayor conocimiento acerca de la dinámica del equipo, los riesgos o las tecnologías usadas. Así entonces, al establecer y revisar los objetivos del proyecto, es importante recordar que la precisión de un plan disminuye rápidamente a medida que nos alejamos más allá de lo que sabemos en este momento. Por ello, un proyecto está en riesgo si su planificación no incluye la necesidad de levantar la cabeza, observar los cambios – ya sea porque nos dimos cuenta que una tecnología era más difícil de lo que esperábamos o una “funcionalidad sencilla” resultó ser un esfuerzo “épico” – y hacer los ajustes correspondientes. Lo que se necesita es una elaboración progresiva del plan. Los equipos ágiles logran esto mediante la planificación en tres horizontes distintos: la liberación, la iteración, y el día a día. Las relaciones entre estos horizontes de planificación (y otros) se ilustran en la cebolla de la planeación:

The planning onion


La cebolla de la planeación. Los equipos ágiles usualmente operan en las tres capas interiores: liberación, iteración y el día a día. (Fuente: informit.com)

El resto del libro se enfoca a explicar las técnicas utilizadas para llevar a cabo la planeación sobre estos tres horizontes, incluyendo conceptos tales como historias de usuario, días ideales, velocidad, priorización y técnicas puntuales como la Tasa Interna de Retorno, el Modelo Kano de Satisfacción del Cliente o la Planeación Predictiva Continua.

Conclusiones

Esta lectura es imprescindible para todos aquellos que quieran entender el qué y el cómo de conceptos tales como burndown bar chart y spike o que quieran perfeccionar sus habilidades para gestionar un proyecto ágil. Lo recomiendo ampliamente ya que sin las técnicas descritas en el libro, un ScrumMaster o líder novato puede perderse completamente al planear y llevar a cabo el correcto seguimiento de un proyecto ágil; especialmente si el resto del equipo no ha manejado una metodología de este tipo con anterioridad o el proyecto es de alta criticidad.

2 comentarios

  1. […] y el ALT + TAB se han vuelto tan populares? Multitasking es de hecho, una actividad que incrementa exponencialmente el tiempo necesario para terminar las tareas que podríamos realizar de forma secuencial, y aun […]


  2. […] recomendable aclarar con el Product Owner que este intercambio de tareas tiene un costo: el “cambio de contexto” o tiempo mínimo necesario para cambiar de la tarea A a la tarea B, puede incrementar hasta […]



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: