Dependiendo del dominio del proyecto (y del producto o servicio resultante) las actividades necesarias para desarrollarlo pueden ser muy diferentes. Sin embargo, podremos coincidir en que en términos generales al menos se realizarán tres actividades: Definición, Ejecución y Pruebas. La Definición se refiere al establecimiento de qué se quiere conseguir, corresponde a actividades de especificación de requisitos, análisis, etc. La Ejecución se refiere a la construcción de lo que se ha acordado en la Definición. Finalmente las Pruebas incluirían todas las actividades asociadas a la conformidad del resultado respecto de lo definido. Así pues, como sugiere la siguiente figura, explicaré los 3 modelos de proceso señalados centrándome en cómo se distribuirían en ellos estas tres actividades.
Proceso en Cascada
El proceso en cascada (Waterfall) es el modelo clásico por excelencia. En un proceso en cascada las actividades se secuencian en su orden lógico (Definición, Ejecución y Pruebas), intentando además, y si se dispone de capacidad, hacer cierto solape entre ellas. La siguiente figura muestra cómo sería un proceso en cascada.
Ventajas
- Es un modelo sencillo de entender por el cliente, aunque él suele estar más interesado en los plazos, costos y alcance del proyecto que en el proceso de desarrollo :-).
- Es cómodo para el cliente pues su participación tiende a concentrarse al principio y al final del proyecto.
- Tempranamente se puede acordar el alcance, costo y plazos del proyecto, (al finalizar la actividad de Definición). Esto está alineado con relaciones cliente-proveedor en las cuales se requiere fijar dichos elementos antes de comenzar la ejecución del proyecto.
Desventajas
- Se asume que no habrá re-trabajo ni cambios. Una vez que una actividad se termina no volvería a realizarse, ni para abordar nuevos requisitos ni para realizar correcciones de fallos.
- Las pruebas se concentran al final. En las actividades de pruebas es natural que se detecten fallos y que esto genere re-trabajo para corregirlos. Si el re-trabajo es significativo puede que no quede margen para que el proyecto termine dentro de los plazos o costos estimados.
- Si se desempeñan roles únicos y fijos, es difícil organizar al equipo. Por ejemplo, si se termina la definición y quienes trabajaron en ella no realizan otro tipo de actividades, deberían ser asignados a otro proyecto. Pero si se genera re-trabajo o aparecen nuevos requisitos tendrían que volver al proyecto.
Este diagrama Gantt delata claramente un proceso en cascada por la forma escalonada en la cual se distribuyen en el tiempo las actividades. Además, en general es muy difícil acertar quién y cuando iniciará y terminará de realizar una tarea (en un diagrama Gantt todas las tareas tienen un inicio y fin que se asocian con precisión a fechas del calendario).
Una crítica adicional que le haría al proceso en cascada, y en particular a la planificación que él condiciona, es que se puede perder fácilmente el foco respecto del producto o servicio que se espera como resultado del proyecto. Al intentar cuadrar las actividades que deben realizarse, dentro de las restricciones de plazos y costos, es fácil despistarse respecto de lo que debería ser mucho más importante: que el resultado conseguido sea satisfactorio para el cliente. Terminar actividades no es una buena medida del progreso del proyecto, especialmente cuando ello no conlleva una validación con el cliente respecto del resultado que se espera del proyecto. Terminar parte del resultado y validarlo con el cliente nos puede ofrecer más garantías respecto al adecuado progreso del proyecto.
Un proceso en cascada NO es adecuado para desarrollo ágil, pues además de todas las debilidades mencionadas, es contrario a dos valores esenciales que destaca el agilismo: responder a los cambios y medir el progreso con el producto funcionando (aunque aunque no esté terminado) en lugar de hacerlo con la documentación resultante de actividades.
Proceso Incremental
Un incremento en un producto o servicio es una nueva versión generada por la terminación de un conjunto de ítems de trabajo. Un ítem puede ser un nuevo requisito, una mejora en un requisitos ya incluido, o puede ser la corrección de un fallo detectado en un versión previa.
En un proceso incremental es clave contar con una lista ordenada del trabajo pendiente dado que desde allí y siguiendo el orden establecido iremos cogiendo trabajo para llevarlo a cabo. Dicha lista ordenada se denomina Backlog. Cada vez que se identifique un nuevo ítem (de cualquier tipo) debe incluirse en el Backlog en la posición que le corresponda según los criterios aplicados (Lectura recomendada: Gestión eficaz del Backlog). Así, el Backlog es el sitio donde se gestionarán los cambios, representados por nuevos ítems, modificaciones de ítems, eliminaciones de ítems o modificación de posición de ítems en la lista. Esto se ilustra en la siguiente figura:
La siguiente figura ilustra un proceso incremental. Los ítems se cogen del Backlog según orden y dependiendo de la capacidad del equipo podrían abordarse a la vez más de un ítem. Cada vez que se termina un ítem se tiene la posibilidad de generar una nueva versión e incluso entregarla al cliente (Continuous Delirvery), sin embargo, habría que evaluar si conviene en ese momento hacer una entrega al cliente ya que el costo asociado a pruebas y despliegue y/o la molestia que puede ocasionar al cliente pueden hacer recomendable NO hacer entregas tan frecuentes.
Ventajas
- Las entregas al cliente pueden ser todo lo frecuente que se desee, llegando al punto de hacerlas cada vez que se termina un ítem. Esto permite hacer validaciones más frecuentes con el cliente. Además se evita acumulación de defectos entre cada versión debido a diferentes ítems y a su interferencia. Así también es más fácil detectar defectos.
- La definición de un ítem se puede postergar hasta en momento en el cual se decide abordar el ítem. Esto favorece la resistencia al cambio, pues no se necesita hacer inversión de esfuerzo con anticipación. Mientras más tiempo hay entre la definición y la ejecución de un ítem, más riesgo existe que dicha definición caduque o que el ítem pierda prioridad.
- Si el ordenamiento del Backlog es el adecuado (lo mas importante y de mayor riesgo primero, entre otros criterios disponibles), tempranamente podremos darnos cuenta cómo progresa el desarrollo, y en caso extremo podremos cancelarlo también tempranamente.
- Durante todo el proyecto se realizan todas las actividades, con lo cual aunque los participantes sean especialistas en ciertas actividades y no realicen otras, tendrán trabajo a lo largo de todo el proyecto (pero quizás con menor intensidad por no estar concentrado).
Desventajas
- El cliente debe participar activamente a lo largo del proyecto, definiendo los ítems que se cogen desde el Backlog y probando las nuevas versiones. Esto más que una desventaja es usualmente visto como una incomodidad por el cliente, especialmente si no tiene conciencia del impacto que puede suponer su NO protagonismo en la rentabilización de su inversión en el desarrollo.
En un proceso incremental, lo ideal sería NO preestablecer el alcance y plazos, y fijar un costo por esfuerzo invertido. Es más, en determinados contextos NO es posible saber qué ítems serán abordados porque la demanda no está preestablecida. Esto ocurre en contextos de operaciones (no suele pasar en contextos de desarrollo), por ejemplo, mantenimiento cuando el producto ya está en producción, incidencias o tickets, etc. En estos casos simplemente no podemos hacer gestión de alcance, a lo más podemos tener límites para el esfuerzo invertido que de superarse lleven a renegociar o firmar un nuevo contrato.
Aún teniendo una demanda preestablecida de ítems podríamos ahorrarnos gestionar el alcance. Esto es posible si existe una relación de confianza entre el cliente y el proveedor, y se espera que a partir de una determinada versión el producto tenga madurez suficiente para entregarlo, y allí decidir si continuar o no trabajando de la misma forma, es decir, de ítem en ítem, de versión en versión. Si el cliente obliga al proveedor a comprometerse en alcance, plazos y/o costo, éste se vería obligado a disponer de una definición y estimación para al menos los ítems más protagonistas, con lo cual perdemos en parte dicha ventaja de definición postergada. Además, en este caso, durante el proyecto también nos veríamos obligados a realizar una gestión de alcance continuamente, cada vez que se produzcan cambios en el Backlog. Lectura recomendada: Gestión de alcance en un proyecto ágil.
Ventajas
Los métodos ágiles Scrum y Extreme Programming utilizan iteraciones (Sprints).
Patricio Letelier
El método ágil Kanban propone un proceso de desarrollo incremental, y sin gestión de alcance.
Proceso Iterativo e Incremental
El proceso iterativo e incremental es un proceso incremental que tiene como complemento iteraciones (Sprints). La siguiente figura ilustra este proceso:
Ventajas
- Tiene todas las ventajas del proceso incremental.
- Usando Sprints se puede conseguir un equilibrio entre tener versiones frecuentes y no invertir demasiado esfuerzo en las actividades necesarias para generar, probar y revisar con el cliente cada versión. Así, en cada Sprint en general se incluirá un conjunto de ítems, es decir, cada nueva versión no es el resultado de un solo ítem.
- Cuando los compromisos con el cliente son poco flexibles la gestión de alcance tiende a ser obligatoria. Trabajar con Sprint permite hacer una gestión de alcance más sostenible (a ritmo constante) pues aunque el período del Sprint sea breve, ofrece cierta calma respecto de los cambios que suelen aparecer al revisar una versión. Se realizaría gestión de alcance tanto a nivel de proyecto (o entrega) como a nivel de Sprint. Para la gestión a nivel de entrega, tal como vimos en el proceso incremental, se requeriría una definición y estimación para todos los ítems, con diferente nivel de detalle, discriminando entre los más ítems más protagonistas (los primeros en cogerse desde el Backlog) y los menos. En cambio para la gestión de alcance del Sprint, idealmente éste, al arrancar, debería tener definidas en detalle los ítems que se incluyen en él.
Para potenciar estas ventajas se recomienda que los Sprints sean de la misma duración para así conseguir una cadencia, un ritmo sostenible de trabajo. Scrum sugiere que los Sprints sean de a lo más 4 semanas de duración.
Desventajas
- Al igual que en proceso incremental, el cliente tiene que participar activamente durante todo el proyecto (aunque como indiqué antes esto no debería ser una desventaja). Al usar Sprints el cliente tiene un cierto "respiro" en cuanto a la frecuencia de las revisiones de versiones, pues no se realizaría al terminar cada ítem sino que al terminar cada Sprint.
Los métodos ágiles Scrum y Extreme Programming utilizan iteraciones (Sprints).
Conclusiones
- No existe un modelo de proceso que sea el mejor para todas las situaciones, sin embargo, en contextos donde se esperan cambios un proceso incremental es más apropiado que uno en cascada.
- Si disfrutamos de una relación de confianza entre el cliente y el proveedor deberíamos intentar acercarnos a un proceso incremental (no iterativo), pues así no tenemos que "distraernos" en gestión de alcance, definiciones anticipadas y cálculos de estimación.
- Cuando los compromisos con el cliente son poco flexibles un proceso iterativo e incremental es lo recomendable pues en él la gestión de alcance es protagonista, tanto a nivel de cada Sprint como del proyecto completo.
- Finalmente, es importante destacar que un mismo equipo puede ser responsable de varias líneas de trabajo, es decir, puede estar trabajando en diferentes proyectos, productos o servicios. El modelo de proceso más eficaz debe evaluarse en cada una de dichas líneas de trabajo.
Patricio Letelier
