El motivo e inspiración de este post viene de algún comentario a raíz del post del otro día, aquel de ¿Por qué es mejor empezar el testing antes que el desarrollo?, donde hablamos de cosas como que hay que “romper la cancioncilla del “Requisitos -> Diseño -> Codificación -> Pruebas”. Hay quien se ha liado un poco y se ha preguntado…
“¿Entonces en una gestión ágil no hay diseño (o cualquiera de los anteriores)?”
Claro que hay diseño, hay pruebas, hay codificación, etc. De la única que tengo dudas es los “Requisitos”, más bien hay gestión de necesidades del negocio (así lo he llamado), de manera diferente a la tradicional, tanto como para no decir que hay “Requisitos” y mejor decir “Gestión de las necesidades” (pero esto es otra historia, no nos vayamos).
La diferencia es que en una gestión tradicional Requisitos -> Diseño -> Codificación -> Pruebas son fases (muchas veces secuenciales) y el una gestión Ágil, véase usando Scrum, las anteriores son tratadas más como Tareas. ¿Cómo? Vamos a ello…
Fases vs Tareas
Como te puedes imaginar, definiciones, con lo ámplio que es el mundo de la “gestión de proyectos”, debe haber centenares. Para intentar ser lo más objetivo posible, vamos a ver qué definición da el mismísimo PMBOK (ya sabes, el Project Management Body of Knowledge):
Phase. See project phase. Voy…
Project Phase. A collection of logically related project activities, usually culminating in the completion of a major deliverable.
Task. A generic term for work that is not included in the work breakdown structure, but potentially could be a further decomposition of work by the individuals responsible for that work. Also, lowest level of effort on a project.
Analicemos lo anterior y unámoslo al conocimiento popular.
Las Fases son de mayor alcance que las Tareas. Las Tareas, a diferencia, son un concepto que todos entendemos que es de menor alcance temporal (más cortitas), más espontáneas, ocurren muchas más veces que las fases y raramente se planifican de manera predictiva (es decir, haciendo una predicción de qué pasará en el futuro, dentro de muchos meses, con esas fases).
Una fase puede tener dentro de sí tareas o actividades, una tarea no tiene sentido que dentro tenga fases.
Si lees la definición anterior que da el PMBOK, a la Tarea le da un nivel menor, habla del menor nivel de esfuerzo, la relaciona con trabajo individual. A la Fase le la un alcance mayor, terminan además con un “entregable”, tienen entrada y una salida.
Las Fases, normalmente, tienen un principio y una fecha fin esperada. De nuevo, volvemos al concepto de predictibilidad, relacionado con que «hoy» yo hago una previsión, una planificación, de cuándo en el futuro comenzará esa Fase y cuándo espero que termine. Eso es predictivilidad y en ocasiones las predicciones pueden ser a muchos meses. Esto, típicamente, lo puedes ver en diagramas de Gantt, que se suelen usar para dibujar esas fases y predicciones (recordarás aquel Diagramas Gantt arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto).
Gestión por Fases vs Gestión por Tareas
Dicho lo anterior, creo que ya todos tenemos clara la diferencia entre una Fase y una Tarea. Entonces… ¿por qué cuándo hablamos de gestión ágil sale tanto lo de tareas vs fases? Ejemplo tienes muchos, frase típica: en Testing Ágil las “pruebas son una tarea no una fase”. De hecho, el propio Sprint Backlog contiene, y nos vale para, auto-gestionar Tareas.
No es cuestión de repetir el post de Planificación clásica vs planificación ágil, que yo te recomendaría leer antes, pero decimos que, por ejemplo, Testing o cualquier otra (cojo el Testing porque me parece la más ilustrativa para el ejemplo) en gestión ágil es una tarea, en vez de una fase, porque…
– Siendo el Testing en Agilidad una Tarea ocurre muchas veces. Dentro de un Sprint, y en suma, dentro de los n Sprint que hagas, Testing es una Tarea que ocurre muchas veces. A diferencia de una (gran) Fase, que sólo suele haber una, única, la gran Fase de Testing.
– Siendo el Testing en Agilidad una Tarea, que se realiza varias veces dentro del Sprint, hablamos de que casi ocurre en «paralelo al resto de Tareas», destacando que ocurre, casí, en ocasiones sin el casi, en paralelo al desarrollo.
– Siendo el Testing una Tarea, la predictibilidad de la misma (ya sabes, visión de lo que pasará en el futuro) es mucho menor, normalmente se piensa solo a nivel de Sprint (unas semanas). Cuando Testing es una Fase se hace una previsión mucho mayor, del tipo, “empezará en enero y terminaremos en mitad de febrero”.
Aunque hay más diferencias y esto se podría alargar, espero que te quedase clara la diferencia de por qué en agilidad hablamos de Tareas en vez de Fases. Y la relación que esto tiene con la predictivilidad, con llevar una planificación basada en el «cambio», que difícilmente puede compatibilizarse con grandes fases y grandes “predictivilidades”.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Para mi el sprint es una fase. El proyecto lo gestiono por fases y el sprint lo gestiono por tareas
Hola @jcesarperez, ¿podrías ampliar un poco más tu respuesta? ¿Para ti el sprint es una fase a la que le sigue o precede otra fase de este tipo? Últimamente se oye mucho el concepto «sprint» de scrum usado en metodologías tradicionales en las que se hace alguna entrega previa al fin del proyecto. A mi personalmente, la palabra fase en la «cultura ágil» me resulta peligrosa 😉 un saludo