case study how eliminate flaws waterfall
Modelo híbrido de cascada ágil
El modelo Waterfall ha sido la opción ideal para el desarrollo de software. En este modelo, una idea se convierte en software utilizable en un proceso secuencial que pasa en cascada por las etapas de Inicio, Análisis, Implementación, Pruebas y Mantenimiento.
Pero el modelo Waterfall tiene algunas desventajas.
El desarrollo de software ágil evolucionó para eliminar los problemas que tiene el modelo Waterfall. Tiene un marco completamente nuevo. Mientras que el modelo Waterfall tiene un diseño secuencial, el modelo Agile siguió un enfoque incremental.
Cuando los clientes que solían seguir el modelo Waterfall cambiaron a Agile, la transición trajo muchos problemas. La razón es la inadaptabilidad a un enfoque diferente para el desarrollo de software. El producto final resultó ser un desastre.
Por lo tanto, ha evolucionado una nueva metodología, que puede denominarse 'híbrida', para garantizar un producto final robusto al elegir las ventajas de los modelos Agile y Waterfall.
Primero, conozcamos los modelos de desarrollo Waterfall y Agile y luego pasemos al 'Modelo híbrido Agile Waterfall' con los pros y los contras de cada uno.
Lo que vas a aprender:
- Modelo de cascada
- Modelo ágil
- Modelo colaborativo (híbrido)
- Modelo híbrido de cascada ágil - Aprenda con el ejemplo - Estudio de caso
- Cómo eliminar las fallas de los procesos de desarrollo en cascada y ágil mediante un modelo híbrido:
- Conclusión:
- Lectura recomendada
Modelo de cascada
El modelo Waterfall es un enfoque para desarrollar software que divide un proyecto en fases finitas. Uno debe pasar a la siguiente fase solo cuando se revisa y verifica su fase anterior.
En el modelo de cascada, las fases no se superponen.
=> Lea más sobre el modelo de cascada aquí.
La Figura 1 muestra el modelo Waterfall:
Ventajas del modelo de cascada:
- Simple y fácil de entender y usar.
- Modelo rígido: cada fase tiene entregables y procesos de revisión específicos.
- La documentación y los artefactos se mantienen meticulosamente.
- Adecuado para proyectos donde se comprenden bien los requisitos.
Desventajas del modelo Waterfall:
- No apto para proyectos en los que los requisitos corren el riesgo de cambiar.
- El costo de reparar defectos es muy alto cuando se detecta en una etapa posterior.
- No es un buen modelo para proyectos largos y complejos.
- No se produce ningún software que funcione hasta tarde durante el ciclo de vida.
Modelo ágil
Wikipedia define el modelo ágil como 'un grupo de métodos de desarrollo de software basados en el desarrollo iterativo e incremental, donde los requisitos y las soluciones evolucionan a través de la colaboración entre equipos autoorganizados y multifuncionales'.
El modelo tiene sus propios principios que tienden a llevar los procesos a un segundo plano.
=> Lea más artículos sobre metodología ágil aquí.
(Haga clic en la imagen para verla ampliada)
Ventajas del modelo Agile:
- Implicación del cliente en el proceso.
- Alto retorno de la inversión ya que el software de trabajo se entrega con frecuencia.
- Incluso los cambios tardíos en los requisitos pueden adaptarse fácilmente.
- Mejora continua tanto del producto como del proceso.
Desventajas del modelo ágil:
- Falta de énfasis en el diseño y la documentación.
- El equipo debe ser estable y capacitado.
Modelo colaborativo (híbrido)
El modelo colaborativo tiene como objetivo combinar ambos modelos: Waterfall y Agile. Aprovechar tanto el enfoque Waterfall como Agile asegura el éxito del proyecto. Elimina las desventajas de ambos modelos; al tiempo que reúne las ventajas de ambos.
El modelo colaborativo se puede implementar en un proyecto ejecutando:
Por lo tanto, el modelo colaborativo se puede representar en forma de diagrama de la siguiente manera:
Ventajas del modelo híbrido
- Combina los beneficios de los procesos Agile y Waterfall.
- El diseño de alto nivel está preparado para aplicar principios de cascada.
- La codificación y las pruebas se realizan utilizando una metodología ágil.
Modelo híbrido de cascada ágil - Aprenda con el ejemplo -Un caso de estudio
La empresa de software 'ABC Software Service' proporciona servicios a un cliente, una Universidad llamada 'Universidad XYZ' para desarrollar, probar y mantener su software (soporte de producción en vivo).
Las principales características de la cuenta son:
- ABC Software Services tiene que actualizar las aplicaciones de XYZ University. La base de datos debe actualizarse y todas las aplicaciones deben volver a desarrollarse con la última tecnología disponible en el mercado.
- Hasta ahora, todos los proyectos manejados por ABC Software se ejecutaban en modelo Waterfall.
- Se había programado volver a desarrollar dos de las aplicaciones de tráfico pesado y de alta prioridad. El primero es 'Registros en línea', el segundo es 'Exámenes en línea'.
- Client XYZ University ahora quería que se trabajara en estas aplicaciones utilizando el modelo Agile de desarrollo de software.
El primer proyecto en un modelo ágil para ABC Software fue Registros en línea. Luego de la ejecución de este proyecto, se pudo constatar en una serie de retrospectivas que existían muchas fallas en los procesos seguidos.
Estas fallas se solucionaron durante la ejecución del segundo proyecto 'exámenes en línea' y, por lo tanto, se ejecutó en modelo híbrido.
Cómo eliminar las fallas de los procesos de desarrollo en cascada y ágil mediante un modelo híbrido:
Analicemos estos en detalle uno por uno.
# 1. Sin documentación:
Uno de los principios ágiles en el manifiesto ágil establece que: Ágil da más valor al 'software de trabajo que a la documentación completa'. La metodología ágil cree que la documentación debería ser 'apenas lo suficientemente buena', y se le da más énfasis a enviar un software que funcione. No se hace mucho esfuerzo en la documentación, pero para cuentas como la Universidad XYZ, con un equipo de soporte dedicado para trabajar en los defectos encontrados en proyectos en vivo, este hábito puede resultar un obstáculo si lo analizamos a largo plazo.
A lo largo de los años, cuando los proyectos se ejecutaron en el modelo Waterfall, los documentos se mantuvieron y actualizaron para que el equipo de soporte los entendiera y trabajara en consecuencia. El diseño de la solución, el diseño técnico, los documentos paso a paso, etc. fueron algunos de los documentos preparados. Una vez finalizado el proyecto, el mismo se transfirió al equipo de soporte.
Pero en el caso del proyecto de 'registros en línea', no se prepararon esos documentos y resultó costoso. Cuando el proyecto se puso en marcha, los usuarios finales generaron muchos tickets y el equipo de soporte no tenía ni idea de cómo trabajar en ellos. El equipo no tenía ningún documento al que hacer referencia.
Esta fue una gran lección aprendida y para el próximo proyecto se redactaron documentos de 'exámenes en línea' y se hicieron la transición de manera efectiva.
=> Lea más aquí por qué la documentación es importante.
#2. Sin pruebas UAT / de extremo a extremo:
En el modo ágil de desarrollo de software, los probadores obtienen las compilaciones para probarlas en incrementos. Estas compilaciones se siguen integrando hasta que la compilación final está completamente construida. Los probadores prueban los requisitos cubiertos en cada sprint y siguen haciendo pruebas de regresión de la compilación que sigue sumando.
Pero después de que se completen todos los sprints y la compilación final esté lista y todo integrado, el evaluador debe probar el sistema completo y debe realizar pruebas de extremo a extremo. Esto debería hacerse en un entorno completamente nuevo.
=> Prueba de extremo a extremo en un proyecto en vivo.
Esto tiene sus propios beneficios:
la etapa del ciclo de desarrollo de software en la que se realiza la programación es:
- El sistema completo se implementa en un nuevo entorno y el probador prueba el flujo completo.
- Genera confianza porque, en última instancia, la compilación debe implementarse como un todo en un entorno en vivo.
Cuando se probó el proyecto de registros en línea, se realizó en el entorno de prueba. Después de probar el sistema y volver a probar todos los defectos, se declaró para su aprobación. Idealmente, esto no se promovió a otro entorno para otro ciclo de prueba del sistema. (Idealmente, UAT ocurre después de la prueba del sistema , pero en este caso, los miembros del equipo de UAT participaron en el primer ciclo de pruebas, por lo que no se programó un segundo ciclo)
Cuando comenzó el proyecto de exámenes en línea, se realizó SIT (System Integration Testing) y el código se promovió a un entorno UAT donde se realizó el segundo ciclo de pruebas. Resultado: se capturaron y resolvieron todos los defectos de alta prioridad. La compilación era estable antes del lanzamiento en vivo.
# 3. Sin Scrum Master:
los Scrum Master es responsable de asegurarse de que un equipo viva según los valores y prácticas de Scrum. El Scrum Master se considera un entrenador para el equipo al ayudar al equipo a hacer el mejor trabajo posible. El Scrum Master también se puede considerar como un dueño del proceso para el equipo.
El equipo de registros en línea se formó sin un Scrum Master. La importancia de tener un Scrum Master dedicado no se consideró importante. Eso dio como resultado que muchos problemas no se resolvieran a tiempo y, a su vez, el tiempo para terminar el proyecto a menudo cruzaba la fecha límite.
Sin embargo, un Scrum Master dedicado estuvo involucrado en el proyecto de Exámenes en Línea. El Scrum Master se encargó de los problemas y desafíos del proyecto. Se prepararon los informes del proyecto / sprint y el equipo pudo ver su progreso.
Además, se llevaron a cabo reuniones adecuadas de planificación de sprints y reuniones retrospectivas de sprint para cada sprint que mejoraron el rendimiento del equipo. El equipo solo se estaba concentrando en su trabajo y completando las tareas asignadas para ese sprint. Toda la limpieza adicional fue manejada por el Scrum Master.
# 4. Conversión de documentos de proyecto a la cartera de pedidos del producto:
Los documentos iniciales del proyecto que se preparan en un modelo en cascada son Especificación de requisitos comerciales (BRS), Diseño de alto nivel, Diseño funcional, etc. Estos documentos deben transformarse en una cartera de productos para ejecutar las etapas de codificación, prueba e implementación en modo ágil. Este es un paso muy importante.
La cartera de productos es el punto de partida de un proyecto ágil. La acumulación de productos es una lista priorizada de requisitos que se mantiene para un producto. Consiste en características, correcciones de errores, requisitos no funcionales, etc. Es un documento en crecimiento que se hace más grande y mejor en función de los comentarios de los clientes, los requisitos cambiantes, etc.
Al ser el primer artefacto de cualquier proyecto, es más importante enumerar los requisitos y asignarles prioridades. La conversión de los documentos del proyecto en cascada en la acumulación de productos es una gran tarea en sí misma y requiere una lluvia de ideas de todo el equipo junto con el cliente / interesado.
Una vez que el cliente enumera y acuerda todos los requisitos, la siguiente tarea es priorizarlos para recogerlos en los sprints.
# 5. Matriz de trazabilidad:
Otro artefacto importante que generalmente se mantiene en el modelo de cascada es la matriz de trazabilidad. Por lo tanto, para garantizar que no se pierda ningún requisito; También se debe diseñar y mantener una matriz de trazabilidad. . Por lo general, en ágil no se diseña tal matriz.
Esta es una buena práctica en cualquier proyecto. Se debe preparar una matriz de trazabilidad en paralelo a la cartera de productos. Y se debe comparar con los casos de prueba ejecutados durante las pruebas de aceptación del usuario / pruebas de extremo a extremo (esta etapa se explica en el siguiente punto). Incluso si se omite algún requisito, se puede incorporar fácilmente incluso en las últimas etapas de desarrollo, ya que ágil proporciona esa flexibilidad y adaptabilidad adicionales.
Después de que el proyecto de registros en línea se puso en marcha, los usuarios finales (estudiantes que querían registrarse) accedieron a la aplicación. Se enfrentaron a muchos problemas en la aplicación. Esto resultó en una gran cantidad de tickets enviados al equipo de soporte de producción. Los tickets recaudados se pueden clasificar como incidencias, problemas o cambios. Se resolvieron muchos problemas, anticipando que la aplicación se estabilizará. Pero incluso entonces, se planificaron más de una docena de solicitudes de cambio / mejoras en las versiones posteriores. Estas mejoras estaban destinadas a estabilizar la aplicación y mejorar la experiencia del usuario final.
Entonces, en última instancia, el costo del proyecto se disparó en muchos sentidos. Por lo tanto, si un proyecto no se transfiere adecuadamente a ágil, puede hacer que el presupuesto se sobrepase. Esto es muy necesario para planificar una transición completa de un proyecto a Agile. Además, la planificación debe realizarse en la medida que el proyecto necesite para que se ejecute en modo ágil. Deben diseñarse modelos híbridos adecuados para un proyecto en particular.
Antes del inicio del proyecto Exam Entry, este aspecto estaba bien cuidado. Se pensó en un modelo híbrido y se decidió que la fase de análisis de requisitos y la fase de diseño de alto nivel se ejecutarían en modelo en cascada y el resto de etapas en modelo ágil.
El modelo híbrido adoptado se puede representar gráficamente de la siguiente manera:
Conclusión:
Es evidente que tanto el modelo Waterfall como el modelo Agile tienen sus propias desventajas. Entonces, es bastante realista optar por un modelo híbrido, que es un enfoque para aprovechando lo mejor de ambos mundos.
El aspecto más importante del inicio de cualquier proyecto es decidir el modelo que va a adoptar el equipo. Esto requiere una planificación extensa. Factores como el presupuesto, el tiempo, la utilización de recursos, la complejidad de los requisitos, etc. deben considerarse al adoptar un modelo de software.
El modelo híbrido aún se encuentra en una etapa incipiente. A medida que más y más empresas lo adopten, aprenderemos más sobre este concepto.
El manifiesto Agile nos pide que valoremos:
- Individuos e interacciones sobre procesos y herramientas
- Software de trabajo sobre documentación completa
- Colaboración con el cliente sobre la negociación del contrato
- Respondiendo al cambio sobre seguir un plan
Considerando que, el modelo híbrido no se adhiere a este 100%. Sugiere que todos los aspectos son de igual importancia. Depende de los clientes / gerentes de proyecto decidir qué aspectos valorar más y qué aspectos no valorar.
Sobre el Autor: Este es un artículo invitado de Harshpal Singh. Tiene más de 7 años de experiencia en pruebas manuales, de bases de datos, de automatización y de rendimiento y actualmente trabaja como líder de equipo en una importante multinacional. Ha trabajado en muchos proyectos de QA siguiendo los modelos de desarrollo Waterfall, Agile e híbrido.
¿Tiene alguna experiencia trabajando en este modelo híbrido de desarrollo y prueba? Discutamos en los comentarios.
Lectura recomendada
- Cascada Agile Vs: ¿Cuál es la mejor metodología para su proyecto?
- ¿Qué es el modelo de cascada SDLC?
- Revisión de la herramienta de gestión de pruebas empresariales Zephyr: cómo utilizar los activos del modelo de cascada en una herramienta ágil
- Modelo en espiral - ¿Qué es el modelo en espiral SDLC?
- 4 pasos hacia el desarrollo de la mentalidad de pruebas ágiles para una transición exitosa a un proceso ágil
- Tutorial ágil de JIRA: cómo utilizar JIRA de forma eficaz para gestionar proyectos ágiles
- Fases, metodologías, procesos y modelos de SDLC (ciclo de vida de desarrollo de software)
- Manifiesto ágil: comprensión de los valores y principios ágiles