El método en cascada es un método lineal cuyo formato se distingue por la secuencia de sus acciones con diferencias a la metodología agile con pasos iterativos e incrementales dentro de ciclos cortos. Trato aquí de escribir una breve reseña sobre algunos puntos que observe al cambiar de un modelo a otro.
Usando un modelo en cascada
El modelo en cascada, nacido desde ámbitos rígidos como la manufactura construcción. data de los años setenta. En estos ambientes los cambios generan altos costos y en muchos aspectos son casi prohibido realizarnos.
En esos años se menciona por primera ves este modelo aplicado al software utilizando el termino “Waterfall” .
Se trata de un proceso meramente secuencial, en dónde primero se especifica completamente los requerimientos y una vez especificados se “firman” para iniciar el resto de fases. En la fase de verificación se somete el sistema a test con pruebas y en caso de encontrarse algun problema pasa a los desarrolladores para su corrección. Pasadas las pruebas se inician las etapas finales de instalación y mantenimiento.
Básicamente un modelo en cascada tradicional tiene esta forma:
Desarrollo en Cascada – Imagen de Wikipedia
En la actualidad los procesos de software han dejado de ser relativamente estables a ser altamente cambiantes o volátiles, lo que es válido hoy seguramente en pocos meses habrá cambiado. Vivimos en un entorno cambiante que convierte a este proceso en una carga muy pesada a cumplimentar.
Ventajas del modelo en cascada
La recopilación de los requisitos muchas veces logra dejar a la luz problemas operativos que pueden ser modificados antes del desarrollo, mejorando el proceso de comercialización.
Se logra profundidad en el conocimiento del negocio en los procesos repetitivos y rutinarios por parte del equipo involucrado, antes del desarrollo del software o de la nueva funcionalidad.
Este modelo es bastante sencillo de comprender, con una secuencia lógica: relevar, documentar, diseñar, desarrollar, verificar, implementar. Al ser un modelo lineal resulta simple de comprender y es fácilmente trasladable a otros procesos dentro de la organización.
Para algunos trabajos en los que la parte operativa no esta clara, resulta práctico un buen análisis que lograra documentación para su revisión posterior.
Sin embargo, en mi opinión, la volatilidad actual del software que mencionamos al principio, lo hace hoy un método inviable para ambientes complejos. En entornos simples y previsibles podría evaluarse su implementación.
Problemas habituales con el modelo en cascada
El principal problema hoy con el que se encuentra este modelo es la dificultad en la aceptación del producto terminado, en el cual habitualmente aparen faltantes que no han sido bien comprendidos, cambios comerciales ocurridos durante el transcurso de desarrollo, o mejoras (diría mejor errores) que se detectaban al iniciar el uso de la interfaz en las fases de pruebas o ya en producción.
También la necesidad de implementaciones rápidas obliga en este modelo a un mínimo testing, los casos de prueba son grandes en relación al tiempo disponible; lo que devendrá en sucesivos mantenimientos (en realidad fixes) sobre el software.
La rapidez actual de los sectores de marketing y comerciales, que necesitan soluciones a un problema pero sin saber exactamente cómo desde la perspectiva técnica, complica la comprensión de los tiempos necesarios para su desarrollo, generando ansiedad previo a la entrega. Otra complicación es la pobre visibilidad que se logra. Hay que esperar hasta las ultimas etapas para ‘ver’ algo del software.
Fue el mismo Winston Royce, a quién se lo considera como el padre de esta metodología en cascada quién dijo:
_“Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso”. _
Sigue…
“La fase de prueba que se produce al final del ciclo de desarrollo es el primer evento para el cual el tiempo, el almacenamiento, la transferencias de entrada/ salida, etc., se experimentan en vez de analizarse. Estos fenómenos no son precisamente analizables. No son las soluciones a las ecuaciones de derivadas parciales estándares de la física matemática, por ejemplo. Sin embargo, si estos fenómenos no satisfacen las diversas limitaciones externas, entonces se requiere invariablemente un importante rediseño. Un simple parche o rehacer algo de código aislado no solucionará este tipo de dificultades. Los cambios de diseño requeridos son propensos a ser tan perturbadores que los requisitos de software sobre el que el diseño se basa y que permiten la justificación de todo el resto, son violados. O bien los requisitos deben ser modificados, o se requiere un cambio sustancial en el diseño. En efecto, el proceso de desarrollo ha vuelto al origen y se puede esperar un exceso de hasta el 100% del tiempo y/ o costo.”
Esta es una comparativa realizada por Standish Group unos 11 años después de la aparición de Agile publico esta comparación en la que se observa una significativa mejoría en en la tasa de éxito del desarrollo de software.
El modelo agile (muy simplificado)
En los años noventa nacieron varios movimientos Extreme Programming (XP), Scrum, Pragmatic Programming, Lean Software Development, entre otros tantos. Estas metodologías livianas pretendían dar alternativas al modelo dominante (Waterfall), rígido y plagado para ese entonces de exceso de documentación y artefactos a cumplimentar que al final no ofrecían valor al producto final del software.
Básicamente este modelo se propone lograr un trabajo final, con entregas periódicas y cortas, de funcionalidades al cliente. Cada periodo esta fijado, por ejemplo dos o tres semanas. Para cada una de estas iteraciones se han seleccionado los requerimientos que lo conformarán y que lograrán un incremento rápido y evidente en las funcionalidades del software.
Scrum – Imagen de Wikipedia
Primer encuentro con agile Scrum
El primer encuentro con metodologías ágiles (fuera de los libros y la teoría) lo tuve al ingresar a una empresa que brinda servicios de outsourcing de software que se gestiona utilizando Scrum hace ya bastantes años atrás.
Tres elementos fueron los primeros en destacarse y que observo como claves (impresión personal):
- Alineación horizontal de los equipos
- Reuniones de estado
- Reuniones de planeamiento
- Ciclos de entrega muy cortos
- Compromiso
Alineación horizontal de los equipos:
Aunque están bien claros los roles principales, el scrum master, el product owner, el team; observo una mayor ‘horizontalidad’ dejando de lado el uso de las jerarquías.
Reuniones de estado:
Son muchas las reuniones, stand up, planning, retrospective, entre otras. Con estas reuniones la información se esparce en el equipo rápidamente y se consigue mayor colaboración y sincronización entre las personas.
En las reuniones diarias, stand up, se comenta lo que se hizo ayer, lo que se esta trabajando, que problemas se tienen y con que se podrá continuar. Se reciben recomendaciones o apoyo por parte del los miembros del equipo con soluciones para quitar los obstáculos que hayan surgido o puedan surgir.
Reuniones de planeamiento:
Recibida la lista de requerimientos prioritarios y candidatos para el sprint estos se planifican en una reunión de planning. Los analistas de negocio explican desde el punto de vista funcional y el team técnico discute sobre ellos, para luego otorgar un puntaje. Lo mas importante aquí, además de tener bien comprendidos los requerimiento (stories), es el consenso y el compromiso por los trabajos que ingresarán en el plan.
Ciclos de entrega cortos:
Los ciclos de entrega (sprints) son muy cortos, dos a tres semanas, lo que nos obliga a dividir las tareas y entregar pronto minimizando la posibilidad de cambios en ellas.
No deben modificarse los requerimientos en un sprint, aunque hay que reconocer que a veces esto sí sucede, sin embargo el impacto es mucho menor al ser tareas pequeñas.
Compromiso:
Esto es en realidad la sumatoria de los puntos anteriores. La implicación del equipo en las decisiones sobre los trabajos logra esta responsabilidad grupal.
El manifiesto Agile
- A los individuos y su interacción, por encima de los procesos y las herramientas.
- El software que funciona, por encima de la documentación exhaustiva.
- La colaboración con el cliente, por encima de la negociación contractual.
- La respuesta al cambio, por encima del seguimiento de un plan.
La confianza entre las personas y su interacción conforman la calidad del equipo. Scrum se apoya en esta interacción y la responsabilidad que todos los miembros del team asumen.
El software funcionando y entregado en cada Sprint tiene el valor que la organización necesita, por sobre cualquier documentación. La documentación es una herramienta intermadia que no aporta valor al negocio. El valor esta en el software en manos del usuario.
La colaboración con el cliente y la relación con los clientes finales y las distintas áreas de la organización es fundamental. Ninguna negociación contractual logra esta colaboración.
Scrum asegura que todos los miembros del equipo estén suficientemente informados sobre el proyecto de forma diaria y sobre cualquier necesidad de cambio para tomar decisiones que satisfagan estas necesidades de un negocio cambiante.
Conclusión
Los cambios entre un modelo y otro son significativos sobre todo en la idea de que se deben entregar periódicamente y en plazos cortos funcionalidades que agreguen realmente valor al software.
El modelo en cascada creo que resulta práctico para procesos rutinarios, sin grandes cambios y con mayor certeza en los resultados esperados.
Scrum es ideal para proyectos con mayor incertidumbre en donde el usuario necesita disponer de los cambios requeridos rápidamente, mejorando el feedback con el equipo y disminuyendo la ansiedad en las entregas.