Para consolidar los conceptos vistos hasta ahora, vamos a explorar un ejemplo práctico de cómo se podría implementar un modelo híbrido en un proyecto real. Este escenario combina la planificación estructurada de la Cascada, la agilidad del desarrollo iterativo con Scrum y la eficiencia del flujo continuo de Kanban para el mantenimiento y soporte.
14.1. Escenario del Proyecto: Desarrollo de una Plataforma de E-learning
Imaginemos que una universidad quiere lanzar una nueva plataforma de e-learning. El proyecto tiene las siguientes características:
- Requisitos iniciales claros pero con potencial de evolución: La estructura básica de cursos, usuarios y pagos es conocida, pero las funcionalidades de interacción y gamificación son más inciertas.
- Fecha de lanzamiento fija: La plataforma debe estar lista para el inicio del próximo semestre académico.
- Equipo de desarrollo experimentado: Familiarizado con Scrum, pero la organización tiene una cultura de planificación más tradicional.
- Necesidad de mantenimiento continuo: Una vez lanzada, la plataforma requerirá soporte y nuevas funcionalidades de forma constante.
14.2. Planificación inicial tipo Cascada
Para abordar la fecha de lanzamiento fija y los requisitos iniciales conocidos, el proyecto comienza con una fase de planificación inspirada en el modelo en Cascada.
- Análisis de Requisitos (1 mes): Se realiza un análisis exhaustivo para definir los requisitos funcionales y no funcionales esenciales (registro de usuarios, gestión de cursos, sistema de pagos, seguridad, etc.). Se involucra a stakeholders clave (profesores, administradores, estudiantes). El resultado es un Documento de Requisitos de Software (SRS) de alto nivel y un Product Backlog inicial.
- Diseño de Arquitectura (0.5 meses): Se define la arquitectura tecnológica (microservicios, base de datos, infraestructura cloud), las principales interfaces y el diseño de la base de datos. El resultado es un Documento de Diseño de Arquitectura (ADD).
- Planificación del Proyecto (0.5 meses): Se crea un plan de proyecto detallado con hitos, presupuesto y un cronograma general hasta el lanzamiento. Se identifican los riesgos principales y se establecen planes de mitigación.
Esta fase proporciona la previsibilidad y el marco de referencia que la dirección de la universidad necesita, y asegura que el equipo de desarrollo tenga una visión clara de los cimientos del proyecto.
14.3. Desarrollo iterativo con Scrum
Una vez completada la planificación inicial, el equipo de desarrollo adopta Scrum para la fase de construcción de la plataforma.
- Equipo Scrum: Se forma un equipo autoorganizado con un Product Owner (PO), un Scrum Master y 5 desarrolladores/testers.
- Sprints (2 semanas cada uno): El desarrollo se divide en Sprints de dos semanas. El PO, basándose en el Product Backlog inicial y el feedback continuo, prioriza las historias de usuario para cada Sprint.
- Ceremonias de Scrum: Se realizan todas las ceremonias: Sprint Planning, Daily Scrums, Sprint Review (con stakeholders de la universidad) y Sprint Retrospective.
- Entrega Continua: Al final de cada Sprint, se entrega un incremento de software funcional y probado. Esto permite a la universidad ver el progreso, probar funcionalidades tempranamente y proporcionar feedback que se incorpora en los siguientes Sprints.
Este enfoque permite al equipo adaptarse a los cambios en las funcionalidades de gamificación o interacción que surgen del feedback de los usuarios, sin desviarse de la arquitectura base definida.
14.4. Soporte y mantenimiento con Kanban
Una vez que la plataforma se lanza y entra en producción, la necesidad de gestionar bugs, solicitudes de soporte y pequeñas mejoras se vuelve constante. Aquí es donde Kanban entra en juego.
- Tablero Kanban de Soporte: Se implementa un tablero Kanban separado (o un carril específico en el mismo tablero de Scrum) para gestionar el trabajo de soporte. Las columnas podrían ser: "Bugs Reportados", "En Análisis", "En Desarrollo", "En Pruebas", "Desplegado".
- Límites de WIP: Se establecen límites de WIP para cada columna para asegurar que el equipo no se sobrecargue y que los problemas se resuelvan de manera eficiente.
- Priorización Continua: El Product Owner, junto con el equipo de soporte, prioriza los ítems en el tablero Kanban en función de su urgencia e impacto.
- Integración con Scrum (Scrumban): El equipo de desarrollo dedica una parte de su capacidad (p. ej., 20%) a trabajar en el tablero Kanban, mientras el resto del tiempo se enfoca en los Sprints de nuevas funcionalidades. Los bugs críticos pueden "interrumpir" un Sprint si es necesario, pero siempre de forma controlada y visible en el tablero Kanban.
Este ejemplo demuestra cómo un modelo híbrido permite a una organización aprovechar la estructura y la previsibilidad cuando son necesarias, al tiempo que mantiene la flexibilidad y la capacidad de respuesta para adaptarse a un entorno de desarrollo dinámico.