En un proyecto ágil se fija el tiempo que dispone la organización para conseguir los objetivos. No se calcula plazo estimando el tamaño de los requisitos, el trabajo que supondrían y lo que tardarían los recursos disponibles. No puede hacerse así porque no se conocen los requisitos en detalle suficiente. En lugar de calcular un plazo del proyecto, se toma este plazo como una restricción del negocio. Se hace una planificación inicial en la que se acaban sabiendo los requisitos de alto nivel, el plan de entregas, las restricciones de plazo, etc. Así planificamos inicialmente el cronograma y también el coste, pues un equipo continuo durante un plazo concreto tendrá un coste determinado.
Un proyecto de 12-24 meses, por ejemplo, suele dividirse en 4-6 fases de 3-4 meses cada una. Cada una de estas fases puede gestionar a su vez como un proyecto o fase, teniendo en cuenta los 49 procesos del PMBOK, si es preciso. En proyectos software, estas fases suelen denominarse "releases" porque tienen el objetivo de entregar a los usuarios finales una funcionalidad terminada. Al proceso de planificar una release se le denomina "release planning" y consiste en determinar en equipo las historias más importantes de la release y asegurarse de que se pueden entregar. Teniendo en cuenta la velocidad del equipo, que suele medirse en historias por iteración, puede calcularse el número de iteraciones, que deben tener una duración fija durante toda la release (concepto de time-box: las iteraciones ágiles siempre terminan en fecha, normalmente duran entre 1-4 semanas, pero si se decide 2 semanas, por ejemplo, esto no se debe cambiar hasta la siguiente release).
El alcance se va planificando en detalle a medida que la release avanza. El resultado del "release planning" suele denomiarse "release backlog", que es propiamente un subconjunto del "product backlog". Al principio de la release, en el release backlog tenemos historias muy grandes (deberían denominarse épicas, mejor que historias) y deben irse descomponiendo y refinando gradualmente. El Product Owner es el encargado de mantener refinada la planificación de las historias del release backlog, especialmente aquellas planificadas para la siguiente iteración. Las historias pueden cambiarse, los cambios son bienvenidos porque ocurren en el product backlog. No debe cambiarse, sin embargo, el trabajo que ha entrado en la iteración, en el que ya está trabajando el equipo de desarrollo.
En la ceremonia llamada iteration planning, el equipo de desarrollo planifica la iteración descomponiendo las historias en tareas que deben ir procesando para ser completadas antes de que finalice la iteración. Típicamente se usan tableros kanban con columnas to-do, doing, done, para visualizar cómo va el trabajo del equipo durante la iteración.
Cada día, en el daily standup, los miembros del equipo informan unos a otros de lo que han hecho desde el último daily, lo que se proponen hacer durante el día, y los impedimentos que les dificultan trabajar al ritmo que esperaban.
Es decir, en un proyecto agile, si se ejecuta siguiendo el marco Scrum, se planifica el día, la iteración (2 semanas), la release (3-4 meses), el proyecto (12-24 meses)...
La planificación suele quedar como reflejo fiel a los trabajos ejecutados, no hay scope creep, no hay padding, etc.
¿Podríamos decir que en un proyecto ágil, si se gestiona bien, se dedica más esfuerzo a planificar que en un proyecto predictivo?
Por Jose Barato, PMP, PMI-ACP, vocal de PMI-Madrid
As a leader or manager, this feels great. As a friend, it feels great. As a human being who loves to help others along the way, it feels great.
The bad news is that sometimes (OK… often) my ideas don’t stand up well to the Strategy Stress Test (SST). In fact, last year, I was cut-off from any new ideas unless it was given the OK by my coach and by my wife/business partner. From that day on, I had to include these two individuals in my own SST.