desarrollo de software a través de la colaboración de cascada y métodos ágiles

Es imposible.

Todas las metodologías ágiles deben ser iterativas. De lo contrario, no corresponderán a los principios primero y tercero del manifiesto :

Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.

...

Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.

Waterfall es un enfoque no iterativo por su definición :

El modelo de cascada es un enfoque de diseño secuencial lineal (no iterativo) para el desarrollo de software, en el que el progreso fluye en una dirección hacia abajo (como una cascada) a través de las fases de concepción, iniciación, análisis, diseño, construcción, prueba, implementación y mantenimiento. .

Por lo tanto, no puede usar enfoques iterativos y no iterativos al mismo tiempo.

Actualización: Hay varias metodologías que no son ni una cascada clásica ni ágil (modelo RUP o Espiral, por ejemplo). Pueden tomar algo de ambos enfoques, pero no son ni lo uno ni lo otro.

Hay un término para tal cosa, Wagile :

El desarrollo de software Wagile es un grupo de metodologías de desarrollo de software que resultan de pasar de ágil a cascada, hacer muchas cascadas cortas y pensar que es ágil, modelo de cascada disfrazado de desarrollo de software ágil, etc.

Y es tan malo como suena...

Encontré un buen artículo para este tipo de proceso...

Sergey Kudryavtsev tiene razón, no es posible.

El principio fundamental detrás waterfalles que el trabajo de gestión de productos se realiza por adelantado: se investiga el mercado, se genera el concepto, se entrevista a los clientes, se diseña todo el producto y luego se pasa un PRD completo y exhaustivo a Ingeniería, que luego desarrolla el producto. , lo prueba y luego lo implementa. Todo el progreso fluye en una sola dirección y el PRD representa una directriz de Producto a Ingeniería.

Con agile, Product aún investigará el mercado, generará un concepto y entrevistará a los clientes, pero no se especificará el producto completo antes de que comience el desarrollo. Un PRD, o varios PRD, se compartirán con Ingeniería, pero estos serán documentos vivos más pequeños. Ingeniería responderá con sus comentarios e inquietudes, y el PRD se actualizará en consecuencia. Lo mismo ocurre cuando se reciben comentarios e inquietudes de los clientes. El proceso es iterativo y estos documentos representan una comprensión del cliente que se comparte entre Producto e Ingeniería.

Visto de otra manera, los agile antipatrones son casi la definición de waterfallrequisitos:

Anti-patrones a tener en cuenta

• Todo el proyecto ya está especificado con gran detalle antes de que comience cualquier trabajo de ingeniería.
• Se requiere una revisión exhaustiva y la aprobación definitiva de todos los equipos antes de que comience el trabajo.
• Los diseñadores y desarrolladores no saben cuándo se han actualizado los requisitos.
• Los requisitos nunca se actualizan en primer lugar (porque todos los aprobaron, ¿recuerdas?)
• El propietario del producto escribe los requisitos sin la participación del equipo.

El problema se sentirá particularmente agudo cuando una parte de la organización está implementando agilemientras que la otra waterfall. Si Producto está usando agilee Ingeniería waterfall, entonces Producto se preguntará por qué las cosas tardan tanto e Ingeniería se quejará de que los PRD están "a medias". Si es al revés, Ingeniería se preguntará en qué se supone que deben trabajar y Producto se quejará de que Ingeniería debe esperar. Se producirá un sentimiento de dolor.

Actualización : Steve Blank acaba de publicar algunos pensamientos sobre el tema en AgileFall - When Waterfall Sneaks Back Into Agile :

AgileFall es un término irónico para la gestión de programas en el que intenta ser ágil y eficiente, pero sigue utilizando técnicas de desarrollo en cascada. A menudo produce un resultado que es como combinar una cera para pisos y un postre.

Continúa describiendo cómo se puede ajustar el proceso para volver a encarrilarse.

Waterfall se basa en la premisa de que la detección temprana de errores, antes de que se invierta mucho, es más económica que la detección tardía de errores. Por lo tanto, planifica más por adelantado para evitar sorpresas más adelante.

Agile se basa en la premisa de que lo anterior es un buen paso para prevenir errores, pero no lo protegerá de cambios y complicaciones. Por lo tanto, operar de forma iterativa y en un alcance más pequeño logra lo mismo que la cascada y más.

Podría tratar de argumentar algo como "Scrum realmente es iterativo, una cascada superpuesta" o "Agile simplemente aboga por hacer subproyectos de cascada mucho más cortos, uno tras otro" y, dependiendo de quién pregunte y lo que quiera, podría tener éxito.

Puede incorporar varios principios ágiles como la estrecha colaboración, la priorización, la participación del cliente, las pruebas continuas, valores como la apertura, el coraje y el respeto en el proyecto de cascada y considerar esta misión cumplida.

El problema es que tanto la cascada como la metodología ágil tienden a tener ciertas expectativas. En general, son más las expectativas las que chocan entre sí que las prácticas defendidas por los "modelos". Y generalmente son las expectativas que tienden a ir con la cascada las que hacen que la cascada sea problemática. Como la expectativa de que el diagrama de Gantt en cascada tenga cualidades proféticas. O la expectativa de que debido a que ha agregado algo de tiempo de búfer al final, puede exprimir fácilmente algunas características más o "aclaraciones" de características. Donde tan ágil se opone rigurosamente a estos...

Puede hacer proyectos exitosos con cascada al igual que con ágil. Intentar meter ambos en el mismo proyecto generalmente es una señal de que no todos en su grupo entienden el punto de ágil. Y usted está tratando de resolver disfuncionalidades que la gente aún no está dispuesta a dejar pasar.