Distinga entre Agile y Waterfall

Podemos comparar Agile y Waterfall, para ello repasemos estos conceptos clave; Agile se creó en respuesta al estricto proceso lineal de Waterfall, mientras que Waterfall se apoya en la previsibilidad y trata de evitar el cambio.

Agile adopta la realidad de que el mundo, los mercados y los usuarios son inciertos e impredecibles por ello, tiene como objetivo resolver ese problema, obteniendo comentarios de los clientes más rápidamente y así asegurarse de que el equipo esté construyendo lo que el cliente realmente quiere. Parte de trabajar con una mentalidad ágil es siempre buscar formas de trabajar más eficientemente.

Para ello, agile trata de encontrar formas de agilizar los procesos sin reducir la calidad o el valor del producto y la clave para la racionalización, es reducir el desperdicio.

Por ejemplo, la documentación innecesaria es una forma de desperdicio, otra forma de desperdicio es pasar semanas o meses trabajando en una característica, solo para descubrir que los clientes, que también podrían ser usuarios o partes interesadas, no les gusta la característica después de todo.

Los tres aspectos importantes de un proyecto son; los requisitos, la documentación y los entregables.

Los requisitos

Los requisitos son condiciones que deben cumplirse o Tareas que deben ser terminadas para asegurar la culminación exitosa del proyecto. Pensemos en ellos, como el conjunto de criterios que se encuentran dentro del alcance de su proyecto, o una lista de especificaciones que deben cumplirse.

En un proyecto Waterfall, probablemente necesitará un documento de requisitos del producto, que enumera el alcance y los requisitos del proyecto. Entonces, se necesita tener varios planes de proyecto aprobados formalmente, y es posible que se tenga un equipo de personas cuyo trabajo sea solo escribir y aprobar estos planes. También se puede establecer una junta de control de cambios, una junta formal y un proceso riguroso para gestionar cualquier cambio en los requisitos.

Todo esto está diseñado para proteger al equipo de construir algo que el cliente o las partes interesadas no quieren y tiene como objetivo minimizar cualquier cambio que pueda conducir a un aumento del alcance. Los planes de proyecto aprobados formalmente funcionan bien cuando el producto final deseado se conoce y comprendido.

Un ejemplo de esto podría ser liderar un proyecto que tenga requisitos claros y metas basadas en la regulación obligatoria. Pero si ese no es el caso, un equipo de Waterfall corre el riesgo de construir un entregable completo solo para descubrir más tarde que al cliente no le gusta el resultado final.

En Agile, los requisitos se tratan como más dinámicos y se espera que cambie a medida que el equipo recibe retroalimentación y nueva información. Por lo general, hay un conjunto inicial de requisitos o presenta ideas cuando el proyecto comienza, pero esa lista de requisitos y características crece continuamente y cambiando a lo largo del proyecto.

El equipo trabaja con las partes interesadas para priorizar los requisitos, moviendo siempre los elementos más urgentes o valiosos al principio de la lista. Luego, el equipo recorre la lista, trabajando en los requisitos en iteraciones. Al recorrer la lista, el equipo puede obtener comentarios sobre su trabajo de manera rápida y frecuentemente. Al final de cada iteración, el equipo recibe retroalimentación y puede hacer los ajustes necesarios a los requisitos antes de continuar.

La documentación

Bien, el segundo aspecto es la documentación. Todos los proyectos requieren documentación, planes de proyecto, mapas de partes interesadas, cronogramas, estatutos, contratos, y la lista sigue y sigue.

Los proyectos en cascada usan mucha documentación porque hay mucha de traspasos entre fases y traspasos entre diferentes equipos dentro del proyecto.

Además, debido a que el trabajo se realiza en partes más grandes, se deberá dejar atrás más piezas de documentación en cada etapa del proyecto.

Pero en Agile, el énfasis es en las conversaciones en tiempo real, de persona a persona, y esto no significa que no haya documentación; es simplemente que esta existe en una forma diferente. En lugar de grandes documentos formales con una rigurosa gestión del cambio y proceso de aprobación, hay documentos más cortos que tienen los detalles justos para lograr su propósito.

Estos documentos están mucho más enfocados en lo que el lector necesita saber para el trabajo hecho y se escriben sólo según sea necesario.

Los entregables

Finalmente, exploremos los entregables. Un entregable es un resultado tangible de un proyecto, en los proyectos de Waterfall, a menudo no publica el entregable hasta el final.

El lanzamiento del producto final se siente como un gran evento, un gran anuncio, mucho alboroto, y a menudo es súper divertido y emocionante.

Agile es igual de emocionante, pero tiene lanzamientos más pequeños y frecuentes, así que cada lanzamiento tiene una celebración menos formal, pero se acumula para ser igual de emocionante. Cuando hay mucha incertidumbre en un proyecto, como en una nueva industria o mercado emergente, el lanzamiento constante de los entregables del proyecto permite que un equipo Agile obtenga retroalimentación y aprenda sobre la marcha.

Sin retroalimentación regular, el equipo podría terminar entregando algo que el cliente no quiere.

Entonces, con este artículo, esperemos se tenga mejor idea de algunos elementos clave de Agile que lo distinguen de Waterfall. Comprender las diferencias entre estas metodologías permite a los gerentes de proyectos seleccionar el enfoque más apropiado para sus proyectos y optimizar el éxito general del proyecto.

Tres diferencias entre estos dos enfoques de gestión de proyectos son la forma cada uno se ocupa de los requisitos, la documentación y los entregables.

Bibliografía

Google. (sf). Gestion de projet Agile. Curso .

Leave A Comment