Waterfall vs Agile ¿Qué metodología debo elegir para mi proyecto?

Al comenzar un nuevo proyecto de software, el equipo técnico y la organización deben tomar una importante decisión, cómo enfocar el desarrollo. Es decir, elegir qué metodología puede ser la más adecuada. Hoy, vamos a conocer las dos metodologías más usadas durante el Software Development Life Cycle (SDLC), Waterfall y Agile. Elegir la más apropiada puede no ser una decisión sencilla ya que cada una sigue un proceso muy diferente para llegar al éxito.

Waterfall o técnica en cascada

La más tradicional a la hora de desarrollar software, y se ha demostrado que es una técnica ampliamente beneficiosa. En él, se recogen los intereses del cliente y se diseña un plan secuencial para adecuarse a ellos. Es un enfoque secuencial que divide el SDLC en cinco fases:

• Requisitos: Se listan las necesidades que tiene nuestro cliente (por ejemplo, la interfaz que necesitan) para planificar las siguientes fases.
• Diseño
• Implementación: Donde los programadores realizan la carga de trabajo real.
• Verificación: Servirá para comprobar la calidad de nuestro trabajo y apreciar los fallos que podemos tener. Actualmente, se emplean herramientas de Insights.
• Mantenimiento: Nuestro equipo se encargará de responder y actualizar el software para satisfacer al cliente.

Cada fase solo puede continuar si la fase anterior ha sido completada con éxito. Entre las distintas fases, se espera un entregable o se firma un documento.

Las fases se pasan solo una vez. Todos los requisitos se reúnen al inicio para tener toda la información necesaria para crear la planificación, el presupuesto y los recursos necesarios.

Ventajas y desventajas de Waterfall

Ventajas de Waterfall

• Recoger las ideas desde el principio facilita la planificación y el diseño.
• Alcance del proyecto bien definido.
• Presupuesto más fácil de calcular.
• El cliente no necesita dedicar tiempo al proyecto.
• Los equipos están más organizados para trabajar en paralelo.
• El progreso se mide con metas claras y marcadas.

Desventajas de Waterfall

• Estructura menos flexible ante posibles cambios.
• No hay margen para error. Puede ser mala estrategia ante los cambios en las preferencias del cliente.
• Los proyectos de gran tamaño no son ideales: demasiado tiempo de espera.
• No hay pruebas de la solución hasta las fases finales.

Agile o método ágil

El desarrollo ágil sigue un enfoque basado en la satisfacción del cliente. Con el buscamos la entrega rápida de funcionalidades completas de una aplicación.

En esta metodología se define una fase de tiempo limitado llamada sprint con una duración normalmente establecida de dos semanas.

• Al comienzo de cada sprint, se elabora una lista de funcionalidades a entregar en el plazo de entrega previsto a partir de las peticiones y prioridades acordadas con el cliente.
• Al final del sprint, los desarrolladores y el cliente revisan y evalúan el trabajo realizado y se toman notas a tener en cuenta para futuros sprints.

Ventajas y desventajas de Agile

Ventajas de Agile

• SDLC más rápido.
• Definición de un calendario de sprints.
• Enfoque centrado en el cliente, lo que resulta en una mayor satisfacción ya que se siente parte del equipo.
• Flexible en la aceptación de cambios: el cliente puede ver el trabajo realizado, tomar decisiones y solicitar cambios.
• Empodera a los equipos para gestionar proyectos.
• Ideal para proyectos con financiación no fija.
• Posibilidad de poner en marcha una versión básica del producto que será completada con iteraciones posteriores.

Desventajas de Agile

• Requiere un alto grado de participación del cliente y no todos los clientes se sienten cómodos con este rol.
• La participación de los clientes puede llevar a nuevas solicitudes realizadas a lo largo del proyecto. Estas alargarán el tiempo y aumentarán el coste del desarrollo.
• Asume que cada miembro del equipo está completamente dedicado al proyecto.
• Un enfoque de tiempo limitado puede no ser suficiente para acomodar las entregas. Y si los plazos de entrega no se corresponden con la realidad, aumentan el coste del proyecto.

Mi experiencia personal

Hace más de veinte años que me di cuenta de que me gustaba más documentar que codificar. Por eso, pasé de ser programador a analista funcional.

Las charlas con la toma de requisitos, la elaboración de documentos funcionales con propuestas en prototipos y su presentación al cliente. Esa es la etapa del desarrollo que más podía disfrutar.

Etapa Waterfall

Los primeros quince de estos veinte años fueron con metodología Waterfall 100%. En mi salsa… generación de entregables muy detallados, esquemas, diagramas, hasta propuestas de modelo de datos a partir de la identificación de las entidades y sus relaciones.

Con ello, exposiciones y discusiones con el cliente, retoques y, cuando todo claro, el desarrollo.

Etapa Agile

Más tarde y por un cambio de empleo, llegó Agile.

“No, no, aquí no hay documentos funcionales, se crean historias de usuario en el JIRA”

Una historia de usuario es una explicación informal de una pequeña funcionalidad del software, documentada de forma independiente al resto. Se suelen documentar como tareas en aplicaciones de ticketing, como JIRA.

Me acababa de quedar sin lo que más me gustaba: Elaborar documentación detallada para tener una vista previa del producto y comentarla con el cliente antes de iniciar el desarrollo.

Pero ¿y la visión global? ¿Qué documentación podía consultar para conocer un proyecto en desarrollo?

“Tienes que buscar los tickets de las historias en JIRA y consultar ahí cada uno”

Desde mi punto de vista, una locura. Es decir, se podía decir que no había nada y para conocer el producto en desarrollo, solo quedaba preguntar y jugar al prueba y error en entornos de test.

Creo que esta moda del no documentar nada lleva a que cuando el sistema vaya creciendo se pierda el control, a que tal parte la hizo tal desarrollador o una empresa externa y no se sabe cómo lo hizo o porqué lo hizo así.

Un paso intermedio: el modelo híbrido

Tras mucho desarrollo, llegó el día en el que decidí salirme del guion y empezar a hacer documentos funcionales sobre el producto, documentos que podían abarcar varios sprints y estructurados de forma que se pudieran trocear por apartados, pudiendo limitar las funcionalidades a implementar en una iteración.

Y entonces, llegó la sorpresa. Los clientes estaban encantados de poder ver un documento que prácticamente era una vista previa de lo que podría ser un manual de usuario. Los desarrolladores también podían conocer más sobre el producto a nivel de concepto. Aparte de las necesidades de negocio para las que estaba pensado el desarrollo.

En ese momento, los tickets con las historias pasaron a tener simplemente un link al apartado concreto de un documento. Esto acotaba y detallaba la funcionalidad a implementar, un documento que en su totalidad definía lo que era el sistema o parte de él, si era un proyecto de gran envergadura.

Modelo híbrido centrado en el prototipado

Usando esta nueva versión “híbrida” de la metodología podía incorporar el uso de prototipos para que el cliente viera una idea de lo que sería el producto terminado al inicio del ciclo de desarrollo. Muchas veces, es más fácil detectar un fallo de planteamiento con una imagen de las “pantallas” que en un extenso texto.

De nuevo, por un cambio de empleo (ya en Itequia) tuve la suerte de encontrarme con una novedad en la metodología a aplicar: Darle importancia al prototipado.

Una de nuestras formas de suavizar el volumen de documentación generada inicialmente es focalizar la fase de toma de requerimientos en la generación del prototipo de lo que podría ser el producto final.

Se trata de involucrar al equipo de UX/UI casi desde el inicio, que esté presente en las reuniones de requisitos para poder tener a corto plazo las primeras propuestas a validar con el cliente.

La presentación de un prototipo con el look final que va a tener el producto e interactivo para simular las funcionalidades, le da al cliente mayor facilidad para detectar cambios necesarios respecto a lo que había podido plantear inicialmente y, además, le da la sensación de avance en el proyecto.

El prototipo se usará para introducir al equipo de desarrollo al tema, tipo y alcance de la implementación del proyecto.

Pero… ¿y mi parte favorita? ¿Qué pasa con la documentación?

Realizar el prototipado previo no sustituye a la documentación necesaria para detallar un desarrollo. Ayuda tener una visión previa para evitar múltiples versiones de los entregables y lecturas antes de la aprobación final.

En resumen, tanto Waterfall como Agile se han convertido en los estándares metodológicos. Ya que cada uno abarca una amplia variedad de proyectos y cumplen con muchos de los requisitos de la industria. Eso no quiere decir que sean los únicos existentes o necesiten cambios dependiendo de la empresa. Explora cada técnica con tu equipo, elige una como base y realiza los cambios necesarios mientras trabajéis en una aplicación o programa.

Es la mejor manera de garantizar el éxito no solo tuyo, sino de tu cliente.

Francesc Juventeny Corbero – Product Owner at Itequia