La columna que viene escribiendo Antonio Quirós en la indispensable revista dotNetmania, me viene sirviendo ya desde hace unos meses como excelente escusa para enfrentar la visión clásica y guiada por un plan con la visión ágil de la gestión de proyectos de desarrollo de software. Ya he ‘enfrentado’ estas dos visiones en anteriores entradas de este blog, cuya lectura recomiendo antes de abordar la lectura de este post: ¿Nos podemos caer de maduros? y Métricas mal entendidas .
Siguiendo con la tradición, voy a tocar el tema de la planificación que Antonio Quirós comentaba en el número de Diciembre de dotNetmania, desde un punto de vista ágil.
No seré yo quien menosprecie el valor de la planificación. A menudo se acusa a las metodologías ágiles, sin fundamento, de adolecer de una ausencia de planificación. Las metodologías ágiles no carecen de planificación, simplemente la abordan de una manera diferente, centrando en lo cercano, evitando caer en la adivinación.
En su artículo Antonio Quirós dice: “Con la planificación el proyecto no está hecho, pero sí tenemos una imagen que se pretende fiel de cómo irán sucediendo las cosas hasta que el proyecto se complete”. Ojalá fuese así, nuestro trabajo sería mucho más simple (y mucho más aburrido dicho sea de paso), pero pensad en los proyectos en los que habéis participado… ¿En alguno de ellos la planificación a sido una “imagen fiel” de algo?.
El plan perfecto es un mito. Un mito atractivo pero un mito al fin y al cabo. De verdad alguien con experiencia en el desarrollo de software puede creer que será capaz de conocer todas las tareas y hitos, dependencias entre estos, los recursos con los que contará, los requisitos del cliente, y además ser capaz de estimar con una precisión suficiente como para poder tratar las estimaciones como certezas… La base de la dificultad para trazar un plan perfecto se encuentra en imposibilidad de establecer un entorno predecible en el que desarrollar el proyecto: La tecnología cambia, los miembros del equipo cambian, los requisitos cambian, la legislación cambia, el negocio cambia todo cambia… esa es la única certeza con la que contamos… Todos sabemos lo que cuesta trazar un plan de proyecto clásico, horas de reuniones, estimaciones, etc… En un entorno tan cambiante no estamos trazando planes, estamos haciendo predicciones, no nos engañemos. Y cuanto más extenso sea nuestro plan, más predicciones estamos haciendo y más nos vamos a equivocar. De todos modos Rappel se equivoca cada año y sigue viviendo de eso… ¿Qué sentido tiene centrarse en seguir un plan que con seguridad se verá sobrepasado por los acontecimientos al cuarto de hora de ser desarrollado?. Si no contamos con un plan perfecto, ¿sigue teneniendo sentido centrar toda la gestión de nuestro proyecto en seguir un plan?. Puede ser, que desde el punto de vista económico, mantener esta falacia tenga sentido, pero ¿Qué es lo que buscamos como empresa?, ¿cual es nuestra primera prioridad?Asegurarnos un margen a toda costa en nuestros proyectos o lograr que nuestros clientes logren valor y por tanto esten ‘encantados’ de pagarnos. Yo tengo claro por cúal me inclino. Ya escribí anteriormente sobre este tema.
¿Significa esto que desde las metodologías ágiles se propugna que no debamos trazar planes? NO!. Simplemente se nos recuerda que nuestro principal plan debe ser ser ágiles. Estar preparados para los cambios que con seguridad ocurrirán a lo largo del proyecto. Sobre esto me encanta una cita de Eisenhower: “Durante una batalla los planes siempre son inútiles, pero la planificación es indispensable”. Debemos centrarnos en realizar una planificación adaptativa en lugar de una planificación predictiva. La planificación adaptativa consiste en realizar una planificación de alto nivel, y refinarla solo para el futuro inmediato, para el trabajo que vamos a abordar de inmediato. El futuro cercano es mucho más fácil de predecir con precisión y mucho más útil. Este enfoque nos permite además contar con la información sobre como fueron nuestros anteriores planes a la hora de planear la siguiente iteración o sprint. Este enfoque es el que proponen las metodologías más en auge hoy en día: Scrum y MSF Agile.
En Scrum, contamos con el Product Backlog como referencia que guía el desarrollo a largo medio plazo, y solo refinamos las estimaciones para los elementos seleccionados durante el Sprint Planning Meeting para ser abordados durante el próximo Sprint. En MSF Agile, es planteamiento es similar, contamos con un plan entrega y un plan de iteraciones, que desgrana que escenarios abordaremos en cada iteración, pero solo durante la planificación detallada de la iteración ser realiza un desglose detallado en tareas. Ambas metodologías reconocen que es un esfuerzo inutil el tratar de desarrollar una planificación detallada a priori.
Asumir la utilidad del enfoque adaptativo en la planificación tambien exige distinguir entre planificación y estimación. No es necesario desentrañar hasta la última tarea para hacer una estimación, siempre que seamos capaces de tratar las estimaciones como estimaciones y no como compromisos.
Para la planificación a medio-largo plazo es mucho más útil centrarse en realizar planes de entrega en lugar de planificaciones detallas. La idea de los planes de entrega es trazar una planificación de en qué orden se entregará la funcionalidad del sistema que se está desarrollando, centrándose en seleccionar la funcionalidad de mayor valor desde el punto de vista del negocio para las primeras entregas. ¿De qué sirve realizar el esfuerzo de planificar en detalle y dividir en tareas un trabajo que realizaremos dentro de seis meses? Mientras trazamos un plan detallado estamos privando a nuestro cliente de la posibilidad de ver software que funciona, que puede usar para descubrir sus necesidades o del que pueda comenzar a disfrutar para mejorar su negocio. ¿Cuántos proyectos conocéis que se han pasado meses en fases de planificación?.
Permitidme que de una nota de humor a este post con una viñeta de Dilbert, esclarecedora, sobre el tema que tratamos hoy. Especialmente interesante es el juego de leer la viñeta dos o tres veces seguidas, para ver como su caracter iterativo hace que el problema que plantea sea especialmente grave.
¡Espero vuestros comentarios y experiencias sobre este tema!