Antes de entrar en materia respecto de las diferencias entre planificación ágil y tradicional hay que enfatizar que al implantar agilismo en un equipo-proyecto/producto/servicio lo primero que debería evaluarse es si efectivamente en dicho contexto específico tiene sentido planificar :-). Cuando la demanda de trabajo proveniente desde la parte cliente NO se agrupa para acordar su entrega en un plazo, es decir, si lo que se espera es que el trabajo solicitado por el cliente se entregue continuamente, en este caso, lo esencial es priorizar continuamente el trabajo pendiente, abordar el trabajo más prioritario y entregarlo en cuanto se termine (intentando cumplir con ciertos niveles de acuerdo de servicio que puedan haberse acordado). Si la dinámica de cambios del proyecto es muy alta, el esfuerzo invertido en planificación puede ser significativo y probablemente no llegue a rentabilizarse. En estos casos lo pragmático sería centrarse en generar ese buen flujo de trabajo terminado que nos lleve a avanzar hasta la finalización del proyecto. En esta situación la estimación del trabajo y su contraste con la capacidad del equipo podría ser opcional o incluso no hacerse. Lecturas recomendadas: Patrones para planificación y seguimiento ágil y ¿Kanban o Scrum? that is not the question.
Bueno, hecho ya este paréntesis previo, en el resto de este post supondré que en el contexto de trabajo al cual nos enfrentamos la planificación tiene sentido.
La imagen anterior ilustra a grandes rasgos las diferencias entre un plan ágil y uno tradicional. A continuación se detalla en una tabla algunos aspectos de la planificación que considero más destacables, pero no pretende cubrir todos los aspectos que podrían contrastarse. Así también, cada aspecto es planteado en términos de lo que usualmente se hace (o se supone que se debería hacer) cuando se aplica cada enfoque. Sin embargo, en un contexto específico para algunos aspectos de la planificación lo más apropiado podría sea una mezcla tradicional-ágil, o que algunos aspectos convenga abordarlos de una forma tradicional y otros de una forma ágil.
Aspecto de planificación
|
Enfoque Tradicional
|
Enfoque Ágil
|
Elementos del plan
|
Fases o tareas que normalmente se refieren a actividades
técnicas que realizará el equipo, no a elementos solicitados explícitamente
por el cliente. Se suele incluir tareas asociadas al inicio y cierre del proyecto.
|
Sprints que contienen ítems de trabajo. Los ítems de trabajo son
parte del resultado final del proyecto, es el cliente quien los establece. Normalmente no se incluye el trabajo asociado al inicio y cierre del proyecto, el trabajo en un sprint se centra en lo que sería la ejecución del proyecto.
|
Resultado asociado a hitos
|
El resultado de la fase o tareas, no es necesariamente una parte
del resultado final del proyecto, podría ser un resultado intermedio que no
forme parte de lo que el cliente va a explotar como resultado del proyecto.
|
Se obtiene un incremento hacia el resultado final del proyecto. Dicho
incremento “potencialmente” podría ser utilizado por el cliente, o al menos
validado (antes de finalizar el proyecto).
|
Frecuencia de hitos
|
No regular, y pueden estar bastante distanciados.
|
Regular, se intenta que los sprints tengan la misma duración. Un
sprint no debería durar más de un mes.
|
Ordenamiento del trabajo
|
Basado en el ordenamiento de las tareas técnicas y sus
dependencias. No suele intervenir el cliente en el ordenamiento de tareas.
|
Basado en priorización de ítems de trabajo. La priorización la
decide el cliente considerando principalmente el valor del ítem en el
contexto del resultado final del proyecto. Los ítems más prioritarios se
realizarán en los primeros sprints.
|
Gestión de alcance
|
Se hace una distribución global de todo el trabajo indicando
fechas de inicio y término de tareas. El alcance suele ser fijo y acorde a
él se establecen los recursos y plazos, los cuales podrían quizás irse
ajustando.
|
Se cuenta con un Backlog (una lista ordenada de todo el trabajo
pendiente). Poco antes de iniciar un sprint se cogen los ítems más
prioritarios del Backlog y se incluyen en el próximo sprint contrastando el
esfuerzo asociado con la capacidad del equipo. Los cambios se reflejan en el Backlog
modificando o añadiendo ítems, ante cualquier cambio se debe evaluar el punto
del Backlog hasta el cual se sigue considerando como alcance del proyecto. Es
decir, lo usual es fijar los recursos
y plazos, y dar la oportunidad de introducir cambios, los cuales
posiblemente dejen fuera parte de los ítems inicialmente incluidos en el proyecto
(serían ítems de menos valor para el cliente). Lectura recomendada: Gestión de alcance en un proyecto ágil.
|
Asignación de responsables y
estimación
|
Suele hacerse una pre-asignación de responsables. Tanto dicha
asignación como la estimación del trabajo no suele hacerla el equipo.
|
Se promueve la auto-gestión del equipo. El equipo realiza las
estimaciones de esfuerzo. La asignación de responsables la decide el equipo y
normalmente se posterga hasta que se va a realizar el trabajo.
|
Cambios y re-trabajo
|
Cualquier cambio en el resultado esperado del proyecto así como
la aparición de re-trabajo (trabajo que debe repetirse total o parcialmente
por detectarse algún defecto) no es bien recibido, no solo por el impacto en
el trabajo, sino por los trastornos que genera en la planificación.
|
El re-trabajo, no suele implicar mayores trastornos pues es
tempranamente detectado. Entre la definición de un ítem y su realización no
suele haber un tiempo considerable pues los ítem se detallan lo más
tardíamente posible respecto de cuando efectivamente se realizarán. Como se comentó
antes, los cambios se gestionan sin mayores inconvenientes en el Backlog,
intercambiando nuevos ítems con ítems no realizados aún, manteniendo siempre actualizado y acordado el alcance con el cliente.
|
