¡No te pierdas ninguna publicación! Suscríbete a The Softtek Blog
Cuando escuchamos hablar de estos dos términos, nuestra mente nos lleva directamente a la gestión de proyectos y podemos llegar a caer en el error, y es que muchos no conocen realmente las diferencias entre estas formas de trabajo.
Las personas que no nos encontramos dentro de los proyectos vemos desde fuera que, trabajando bajo metodología Waterfall, no llegamos a conocer toda la situación de los proyectos; y trabajando con Agile, vemos a los equipos con un tablero, muchos post-its y una reunión por las mañanas.
Por tanto, para comenzar a trabajar en cada una de las dos metodologías, debemos entender cómo es cada una de estas formas de trabajo y cómo funcionan.
Es la forma tradicional de gestión de proyectos. Posee una estructura con un orden estricto conformado por las siguientes fases: inicio, planificación, ejecución, seguimiento y control, y cierre.
Se tienen roles definidos jerárquicamente, encontrándonos al jefe de proyectos como máxima autoridad y, por debajo, a los analistas, desarrolladores, testers, QA, etc.
En este tipo de proyectos, cabe resaltar que las fases deben completarse al 100% antes de poder ejecutar la siguiente fase. Los proyectos basados en esta metodología suelen seguir un cronograma plasmado en el Project con fechas para cada fase, como podemos ver en el siguiente ejemplo:
Puede considerarse como la nueva forma de gestionar los proyectos. Se basa en una forma de trabajo colaborativa: las fases del proyecto se realizan con todos los actores involucrados desde el inicio del proyecto; y se gestiona en base a entregables. Se trata de una práctica que admite la repetición continua de desarrollo y pruebas durante el proceso de desarrollo de software.
Dentro de agile se encuentra SCRUM, que es el modelo más utilizado por las empresas actualmente y en el cual entraremos en detalle.
Es una metodología de adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer un valor significativo de forma rápida en todo el proyecto. Scrum garantiza transparencia en la comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo.
El marco de Scrum, tal como se define en la Guía SBOKTM, está estructurado de tal manera que es compatible con los productos y el desarrollo de servicio en todo tipo de industrias y en cualquier tipo de proyecto, independientemente de su complejidad. Una fortaleza clave de Scrum radica en el uso de equipos multifuncionales, autoorganizados y con poder, que dividen su trabajo en ciclos de trabajo cortos y concentrados llamados Sprints.
Por tanto, en los proyectos Scrum:
Scrum se basa en 6 principios, 19 procesos y aspectos generales propios de esta metodología.
SCRUM, como uno de los marcos de trabajo ágiles más populares, tiene como base 6 principios que orientan la gestión de un proyecto a lo largo de todas sus fases.
Los principios de SCRUM no son negociables porque su propósito es asegurar la implementación efectiva del marco de trabajo. Tanto los aspectos de SCRUM como los procesos de este framework pueden ser adaptados, o modificados, en base a la naturaleza y tipo de proyecto, mientras que principios de SCRUM son fijos.
Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto. En total, hay diecinueve procesos que se agrupan en cinco fases.
Existen dos tipos de roles en un proyecto Scrum:
a) Roles Core
Son aquellos papeles que obligatoriamente se requieren para producir el producto o servicio del proyecto. Las personas a quienes se les asignan Core Roles están plenamente comprometidas con el proyecto y son las responsables del éxito de éste.
b) Roles No Core
Papeles que no son obligatoriamente necesarios para el proyecto Scrum. No tienen ningún papel formal en el equipo y pueden interactuar con él, pero no pueden ser responsables del éxito del proyecto.
Scrum intenta iniciar la entrega de los resultados lo antes posible en el proyecto, esta entrega temprana de los resultados proporciona una oportunidad para la reinversión y les demuestra el valor del proyecto a los socios.
Dado que Scrum requiere que el trabajo se realice en incrementos durante los Sprints, ésto hace que los errores o defectos sean notados con más facilidad a través de pruebas de calidad (quality) repetitivas, y no simplemente cuando el producto final o servicio esté casi terminado. Por otra parte, las tareas relacionadas con la calidad (como las pruebas y su documentación) se completan por el mismo equipo como parte del mismo Sprint. Ésto asegura que la calidad sea inherente a cualquier entregable creado como parte de un Sprint.
Los proyectos Scrum le dan la bienvenida a los cambios mediante el uso de los Sprints cortos y repetitivos, que incorporan la retroalimentación del cliente en cada entrega del Sprint. Esto permite que el cliente interactúe regularmente con los miembros del Equipo Scrum, vea entregables a medida que estén listos y cambie los requisitos, si es necesario, antes del siguiente Sprint.
A los riesgos que pueden tener un impacto positivo en el proyecto se los conoce como Opportunities, mientras que las amenazas son riesgos que podrían afectar al proyecto de una manera negativa. La gestión del riesgo debe hacerse de forma preventiva, siendo un proceso iterativo que debe comenzar al inicio del proyecto y continuar a lo largo todo el ciclo de vida. El proceso de gestión de riesgos debe seguir algunos pasos estandarizados para asegurar que los riesgos sean identificados y evaluados. Además se debe tener un plan de acción determinado y velar para que se actúe en consecuencia.
Pues bien, como todo en esta vida DEPENDE, según el tipo de proyecto y la organización en la que se está trabajando se puede adaptar mejor uno u otro método de trabajo.
Ahora vamos a comparar estas formas de trabajo
El triángulo de la gestión de proyectos nos muestra como están estructurados estos métodos.
Según el enfoque cada método se basa en diferentes partes del proyecto
* Estilo de los procesos
Por un lado, los proyectos Waterfall requieren de un equipo estructurado con un jefe de proyecto como máximo responsable y quien se encarga de hablar con el cliente, mientras que en un proyecto Agile existe una comunicación fluida entre el equipo y el cliente.
En cuanto al proceso de desarrollo, en Waterfall se divide en fases mientras que en agile se separa el ciclo de vida de los proyectos en “sprints”.
Una de las diferencias más importantes entre la metodología de desarrollo Agile y Waterfall es su propio enfoque de la calidad y las pruebas. En Waterfall, la fase de "Prueba" viene después de la fase de "Construcción"; pero en Agile, la prueba generalmente se lleva a cabo simultáneamente con la programación o, al menos, durante la misma iteración que la programación.
Entonces dependiendo de la organización, del tipo de proyecto y de los tipos de resultados que esperamos conseguir podemos utilizar waterfall o agile.