En este post vamos a comentar algunas diferencias entre Agile y Waterfall en tres aspectos relevantes en la gestión de proyectos, los requisitos, la documentación y los entregables.
- Los Requisitos. Los Requisitos de un proyecto como las condiciones que debe satisfacer o las tareas que se deben completar para dar por concluido un proyecto. También se pueden entender como el conjunto de criterios dentro el alcance, o la lista de especificaciones que se deben cumplir en el proyecto.
- En Waterfall, probablemente necesitarás un documento que enumerará el alcance y los requisitos del producto. Necesitarás un plan de proyecto y para ello deberás disponer de un equipo de gente que se encargará de escribir y aprobar formalmente esos planes. Además, deberás establecer un board para el control de cambios con un proceso riguroso para gestionar cualquier cambio que se solicite o se requiera. Todo esto está pensado para proteger al equipo de crear algo que el cliente o los stakeholders no quieran y para minimizar cualquier cambio que pueda poner en riesgo el proyecto. Los planes de proyecto aprobados formalmente funcionan bien cuando la definición de los productos finales deseados está bien acotada y es conocida de antemano. Por ejemplo, un proyecto que tiene unos requisitos y objetivos claros basados en regulación existente. Pero si ese no es el caso, un equipo Waterfall corre el riesgo de crear un entregable completo, para inmediatamente descubrir que el cliente no necesita lo que se ha desarrollado.
- En Agile, los requisitos se tratan de una forma dinámica y pueden cambiar a medida que el equipo recibe feedback y dispone de nueva información. Inicialmente, en el lanzamiento del proyecto, hay definido un conjunto de requisitos, y ese conjunto o lista (o backlog) de requisitos crece y cambia constantemente a lo largo del proyecto. El equipo tiene que trabajar con los stakeholders para establecer las prioridades de esos requisitos, de modo que empiecen trabajando por los más prioritarios, que pueden ser los que aportan más valor o los más urgentes. El equipo seguirá trabajando en esos requisitos bajando de forma iterativa en la lista de prioridad, a medida que los primeros se van entregando. Al final de cada iteración, el equipo recibe feedback rápida y frecuentemente, y puede llevar a cabo los ajustes necesarios en los requisitos que todavía están en la lista antes de continuar con la siguiente iteración.
- La Documentación. Todos los proyectos necesitan documentación: planes de proyecto, mapas de stakeholders, planificaciones, contratos, etc.
- Los proyectos Waterfall requieren muchísima documentación, porque hay muchos traspasos (handovers) entre fases y entre los diferentes equipos de trabajo del proyecto. Además, como el trabajo se entrega en lotes muy grandes, es necesario crear mucha documentación en cada etapa del proyecto.
- En Agile también se requiere documentación. Sin embargo, en Agile se da prioridad a las conversaciones entre personas en tiempo real, lo que implica que la documentación tiene un propósito diferente. Además, como el trabajo se va realizando en pequeñas partes, se necesita menos documentación en cada una de las etapas del proyecto. En lugar de laboriosos documentos formales con una gestión de cambios y un proceso de aprobación rigurosos, los documentos son más cortos y solo necesitan el nivel de detalle suficiente para su propósito. Estos documentos solo incluyen la información necesaria para que el lector conozca qué es lo que tiene que hacer para completar su trabajo, y solo se escriben si son necesarios.
- Los Entregables (Deliverables) configuran el tercer elemento. Los deliverables son los resultados tangibles de un proyecto.
- En los proyectos Waterfall los deliverables se entregan al final del proyecto. La release final del proyecto es un gran evento.
- En cambio, en Agile hay releases más frecuentes y de menor envergadura. Cuando hay mucha incertidumbre en un proyecto, como por ejemplo, en un nuevo mercado o sector Agile permite recibir feedback e ir tuneando el proyecto a medida que se va avanzando. Si se carece de ese feedback es posible entregar al final de un proyecto waterfall algo que el cliente realmente no quiere.
No hay comentarios:
Publicar un comentario