¿Es ágil más que pequeñas cascadas?

Principalmente he usado la metodología de cascada en mis proyectos, pero ahora estoy expandiendo mis horizontes en metodologías ágiles. Por lo que he leído hasta ahora, y tal vez he leído cosas incorrectas, ágil significa pequeñas cascadas. En lugar de una gran cascada que se extiende durante uno o dos años, tiene pequeñas cascadas que duran semanas o tal vez algunos meses como máximo.

¿Es correcto mi entendimiento o hay más que eso? ¿Cuáles son las filosofías ágiles?

En un nivel simple, sí. Simplemente realizar una cascada cada dos semanas no lo hace ágil , pero es iterativo (que es la mitad de ágil).

El modelo en cascada define fases: requisitos, arquitectura, diseño, implementación, verificación (prueba), validación (prueba de aceptación) y lanzamiento. En cualquier metodología iterativa, pasa por cada una de estas fases dentro de cada iteración. Puede haber superposición entre ellos, pero usted obtiene y captura los requisitos, adopta la arquitectura y el diseño del sistema para permitir la implementación, desarrolla las nuevas funciones o corrige los defectos, prueba los nuevos módulos y luego los presenta al cliente para su aceptación prueba y despliegue.

Sin embargo, hay mucho más que agilizar que solo ser iterativo e incremental. Los inquilinos de ágil se capturan en el Manifiesto para el desarrollo de software ágil . Hay cuatro puntos clave hechos en el Manifiesto:

Individuos e interacciones sobre procesos y herramientas

Involucra a personas individuales con frecuencia. Muchas implementaciones se centran en equipos autoorganizados y autodirigidos. Casi todos tienen interacciones frecuentes con el cliente o con alguien que tiene voz del cliente. En lugar de tener un conjunto formal de procedimientos a seguir y herramientas para usar, permite que las personas que trabajan en el proyecto dirijan cómo se realiza el proyecto para permitir que se realice de la mejor manera posible.

Software de trabajo sobre documentación completa

En un proyecto de software, el objetivo principal es la entrega de software. Sin embargo, en algunos proyectos, hay una producción derrochadora de documentos que no agregan valor. Scott Ambler escribió un buen artículo sobre Agile / Lean Documentation . No se trata de no producir documentación, sino de elegir documentación que agregue valor a su equipo, futuros desarrolladores, el cliente o el usuario. En lugar de producir documentación que no agrega valor, sus ingenieros de software están produciendo software y pruebas asociadas.

Colaboración del cliente sobre negociación de contrato

En lugar de definir los términos y horarios y los costos por adelantado, se convierte en un esfuerzo continuo con el cliente. Por ejemplo, puede capturar sus requisitos en forma de historias de usuarios y asignarles puntos. Después de unas pocas iteraciones, se decide por una velocidad (puntos / iteración) y puede determinar cuántas características puede implementar su equipo en una iteración. A medida que su cliente proporciona comentarios sobre qué características agregan más valor, pueden decidir cuándo se realiza el proyecto en cualquier momento. Pueden suceder muchas cosas con la entrega frecuente y la interacción con el cliente: los requisitos se han cumplido y el proyecto concluye en mantenimiento y, finalmente, el final de la vida útil, el cliente descubre que no necesita todo lo que pensaba, por lo que decide finalizar el proyecto. proyecto, el proyecto está fallando y el cliente lo ve temprano y puede cancelarlo ...

Responde al cambio sobre el siguiente plan

No tiene un diseño grande o un plan final por adelantado y tiene que realizar modificaciones cada vez que ese diseño o plan tiene que cambiar. Continuamente estima y revisa estimaciones basadas en la información que tiene. Usted elige sus métricas con cuidado para proporcionar información sobre el estado del proyecto y cuándo realizar cambios internos. Con frecuencia agrega, elimina y prioriza los requisitos con el cliente. Finalmente, entiendes que el cambio es la única constante.

Ser ágil significa centrarse en las personas y satisfacer sus necesidades mediante la entrega rápida de software de alta calidad y valor agregado. A medida que cambian las necesidades del cliente, usted se adapta a esas necesidades para enfocarse en agregar valor. Existen implementaciones específicas de metodologías ágiles, pero todas se centran en las personas, la entrega oportuna de software de trabajo y la adaptación a un entorno que cambia rápidamente.

Sí y no: el proceso real puede verse como una serie de pequeñas cascadas, pero la diferencia es que el proceso evoluciona y se mejora a partir de la aportación de todo el equipo (dev, qa, negocios, etc.), en retrospectivas, lo que debería conducir a una unidad mucho más ajustada que es capaz de reaccionar a los problemas y planificar y entregar con precisión. Estoy excesivamente simplificando aquí, hay mucho más, pero no creo que este sea un mal punto de partida.

Yo diría que es una forma simplista de decirlo. Sí, cuando te pones a ello, son pequeños flujos de agua, pero hay mucho más detrás que lo hacen funcionar. Una metodología completa que cambia la forma en que aborda los proyectos ... Sin mencionar la mentalidad necesaria para ello.

Si te tomas en serio Agile, aquí hay una buena (y larga) serie de transmisiones web que te pueden interesar:

http://autumnofagile.net/

Olvídese de Agile un minuto, piense en lo que se entiende por "cascada".

Hay una fase de requisitos, en la que todos intentan averiguar QUÉ problemas debe resolver el producto final. La gente discute sobre esto por un tiempo, y luego todos firman un conjunto de requisitos. En este punto, se define su alcance, se firman los contratos y el cliente puede desviarse y esperar a que encuentre un producto que resuelva esos requisitos definidos.

A continuación hay una (o quizás dos) fases de diseño. Los diseñadores (que pueden o no ser los desarrolladores) discuten sobre CÓMO el sistema debe unirse para cumplir con los requisitos aprobados. Pueden surgir problemas si no comprenden del todo un requisito, lo que puede significar que tienen que volver al cliente, potencialmente reabrir la fase de requisitos (y obtener otra ronda de firmas) o al menos poner en marcha la gestión de cambios . A menudo, los diseñadores simplemente hacen su mejor suposición. Pueden proponer un modelo de datos lógico y muchos UML que describan un nuevo sistema y cómo debería funcionar. Luego lo firman.

Ahora los desarrolladores pueden comenzar a codificar, según el diseño aprobado. Pueden surgir problemas si no comprenden completamente el diseño, lo que puede significar que tienen que volver al diseñador, potencialmente reabrir la fase de diseño (y obtener otra ronda de aprobaciones) o al menos poner en marcha la gestión del cambio. . A su vez, los diseñadores pueden darse cuenta de que la confusión realmente se remonta a los requisitos, lo que significa que tienen que reabrir las discusiones sobre los requisitos, las aprobaciones y una mayor gestión del cambio. A menudo, los programadores (que tienen una fecha límite inminente) simplemente hacen su mejor suposición. Hacen lo que pueden para crear código funcional. Luego lo lanzan a prueba.

Ahora se inicia la fase de prueba del sistema. Los probadores prueban según su comprensión de los requisitos y el diseño, y registran lo que perciben como defectos en un sistema de gestión de seguimiento / cambio de errores, lo que hace que los desarrolladores comiencen a desarrollar nuevamente, a menos que vean el problema como un defecto de diseño, que lo devuelve al diseño, etc. Finalmente, las pruebas del sistema pasan y se cierran.

Finalmente, el cliente regresa y realiza pruebas de aceptación del usuario en el nuevo sistema. Aquí es donde deciden si la solución que probaron los probadores, los desarrolladores desarrollaron y los diseñadores diseñaron es realmente lo que quieren. Si no es así, posiblemente tenga que volver a la fase de diseño o incluso volver a visitar los requisitos.

La idea detrás de la cascada es que es difícil (y muy indeseable) regresar una vez que se completa una fase. Generalmente, diferentes personas están involucradas en diferentes fases, por lo que hay múltiples transferencias, cada una de las cuales presenta un gran riesgo de mala interpretación y pérdida de información. También hay una brecha significativa entre cuándo los clientes dicen lo que quieren y cuándo ven lo que se ha construido, en cuyo momento los requisitos reales pueden haber cambiado.

Las metodologías ágiles se centran en una fuerte comunicación y cooperación entre todas las partes interesadas. El principio "Colaboración del cliente sobre la negociación del contrato" significa que no debería tener que pasar por una serie de firmas y transferencias, sino que simplemente debe trabajar junto con el cliente, cada iteración determina los requisitos para una pieza del rompecabezas e inmediatamente formando pruebas, un diseño y un código de trabajo, con todos los jugadores comunicándose lo más directamente posible (eliminando costos y riesgos de traspaso). El cliente puede comprobar rápidamente el código de trabajo, eliminando los riesgos de retraso. Todas las actividades suceden en un remolino colaborativo, no en un flujo descendente.

Para obtener una excelente visión general de lo que intentan hacer las metodologías ágiles, recomiendo el Desarrollo de software ágil de Allistair Cockburn : El juego cooperativo .

Sí, eso es más o menos correcto. Se ha escrito y discutido mucho sobre cómo hacerlo, pero un montón de pequeñas cascadas es el quid de la cuestión.

Sin embargo, la implementación específica de cómo usar un montón de pequeñas cascadas no es trivial. Por ejemplo, no vas a pasar de hacer grandes proyectos en un par de años a hacer varios proyectos pequeños. Todavía queda el gran proyecto con 1-2 años de trabajo para poner en él. Por lo tanto, debe dividir el gran proyecto en varios proyectos pequeños. Eso puede parecer bastante obvio, pero llena páginas y páginas de libros.

¿Es correcto o hay más que eso?

Ambos. Sí, es una suma precisa del concepto, pero se resumen muchos detalles. Quiero decir, casi todos los aspectos de la planificación cambian cuando estás planeando solo la próxima semana en lugar del próximo año.

Si nos fijamos en la estructura estática (definición de proceso) de un proyecto ágil, sí parece muchas cascadas pequeñas. Pero el objetivo de un proyecto ágil es obtener comentarios más rápidos y mejores .

• Realiza un desarrollo basado en pruebas para saber de inmediato si su software aún funciona
• Un cliente está en el sitio y realiza pruebas de aceptación para saber cuándo ha terminado
• Tiene retrospectivas para ajustar su proceso en función de lo que salió bien y lo que no.

El manifiesto ágil destaca algunas diferencias entre ágil y cascada (como lo perciben los que firmaron).

Realmente "ágil" a menudo significa cascadas de 1-2 días, no semanas. Eso no significa que no sigas un plan general y que los ciclos de lanzamiento reales sean de 1 a 2 días. Pero debe tratar de tener un producto probado y que funcione todos los días, y podría lanzarlo, en teoría, todos los días.

Scrum, por ejemplo, usa sprints de 4 semanas, pero un sprint no es solo una cascada (al menos, no debería serlo). Puedes cambiar las prioridades todos los días cuando veas que algo no sale como se planeó al comienzo del sprint.