¿El cálculo de la ruta crítica en agilidad?

No sé a ti, pero yo una de las cosas que menos puedo olvidar de cuando estudiaba la carrera de informática, en las asignaturas de ingeniería software, era aquello de los PERT y los Gantt. Al menos en mis tiempos, y creo que la cosa no ha cambiado excesivamente, la “gestión de proyectos software” que nos enseñaban se fundamentaba mucho en esas dos técnicas. Y más allá de los estudios universitarios, el tema sigue vigente ya que se trata bastante en modelos más clásicos de gestión, aplicados al mundo del software, como son el PMBOOK y el correspondiente examen del PMP.
No voy a entrar hoy en los Gantt, a los que ya les dediqué un emotivo post, aquel de Diagramas Gantt como arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto, y si que hoy quería hablar contigo de las “rutas críticas” en agilidad, o en desarrollo software en general.
Creo que en toda mi carrera nunca usé, o vi usar, aquello de la ruta crítica. La ruta crítica es lago muy de los procesos secuenciales, y son las actividades deben completarse obligatoriamente, que suelen depender unas de otras, y en las que sí hay un retraso habrá un retraso en todo el proyecto.
En el mundo de la gestión de proyectos con ciclos de vida en cascada, con fases secuenciales, era fácil “pintar” y contar que como sólo había una fase de requisitos, la siguiente fase, simplificadamente, la de diseño, dependía de la anterior, y por ello un retraso en la toma de requisitos afectaría al total del tiempo de proyecto. Y lo mismo sucedía entre la fase de diseño y la de programación. Y lo mismo entre programación y pruebas.
Salvando que el escenario anterior era bastante teórico, y difería bastante con lo que sucedía en la realidad, donde aunque no estuvieran así “pintadas” las fases de requisitos, diseño, etc., aparecían en momentos no planificados según el anterior escenario, la cuestión de hoy es… ¿Tiene aplicación aquello de las rutas críticas en un proyecto ágil? ¿en un ciclo de vida iterativo e incremental de iteraciones cortas?
Al ser en agilidad las iteraciones tan cortas, semanas, y al no fundamentarse en una predictibilidad (tener todo definido desde el principio), haciendo bienvenido el cambio y la adaptabilidad según el proyecto se va enfrentando con la realidad, pragmatismo, el concepto de ruta crítica existe pero es mucho menos fuerte y crítico, valga la redundancia.
La ruta crítica de tareas es fácil de ver ya que las las iteraciones son cortas y se trata como algo más, un tema más a comentar, durante las diferentes reuniones dentro del sprint, durante la iteración, cuando se lanzan preguntas sobre cómo se van el la iteración o que haremos al comenzarla. Pensar en la “ruta crítica” más allá de un Sprint puede ser síntoma de que el proyecto más que ágil es un cascada troceado en iteraciones.
Dicho esto, vuelvo a mencionar, que aquello de la ruta crítica tenga mucho menos peso en proyectos ágiles que en proyectos cascada, no quiere decir que no exista dependencia de tareas. Y concretamente hay una dependencia típica que cabe reseñar aquí. Una dependencia que más que de tareas es de aquellas necesidades, funcionalidades, que hay que implementar. La dependencia entre historias de usuario, que conlleva dependencia de tareas.
Hay quien dice que las historias de usuario deben ser independientes entre sí y de hecho esto de la independencia es un atributo de calidad en una buena historia. Pero la realidad dice que si vas a desarrollar un videojuego “darle al botón de comienzo” debe ir antes de “ponerse a matar marcianos”. Y de hecho existen populares técnicas para gestionar estas dependencias alejadas, obviamente, de aquellas de la ruta crítica, destacando entre ellas el uso de los “mapas de historias de usuario”, como te conté en #Agile2015 Mapas de historias de usuario, de Jeff Patton

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba