¿La metodología de desarrollo de software de Waterfall sigue siendo viable?

El modelo de cascada al que se refiere nunca fue pensado para ser un modelo de proceso usado en un proyecto real. En cambio, es un hombre de paja. Identifica las fases y actividades clave que existen en los proyectos de software y el flujo más básico entre ellos. Esta simplificación excesiva de cómo desarrollar software es defectuosa, e incluso se presentó de esa manera.

Del artículo de Wikipedia:

  

La primera descripción formal del modelo de cascada se cita a menudo como un artículo de 1970 de Winston W. Royce, aunque Royce no usó el término "cascada" en este artículo. Royce presentó este modelo como un ejemplo de un modelo defectuoso que no funciona.

El documento analizado se titula Administración del desarrollo de grandes sistemas de software . En ella, Royce presenta ese modelo en la segunda página. Sin embargo, el texto inmediatamente debajo de la representación pictórica continúa leyendo:

  

Creo en este concepto, pero la implementación descrita anteriormente es arriesgada e invita al fracaso.

Sigue esto con una discusión de los problemas con las pruebas luego de la "finalización" de la fase de desarrollo, y cómo las fallas aquí pueden llevar a rediseños importantes y cambios en el código, y cómo estos pueden llevar a grandes excedentes en costos y cronogramas. A lo largo del documento, refina el modelo original a uno que es realmente viable en un proyecto. Al final, termina con un modelo que introduce la creación de prototipos, la interacción con el cliente y el refinamiento de los artefactos, ideas que eventualmente terminarán siendo críticas para el movimiento ágil que comenzó a fines de los 90 y principios de los 2000.

Para responder a su pregunta: La cascada que está preguntando no es, y nunca fue, un método viable para entregar proyectos de software con una cantidad razonable de calidad a tiempo y presupuesto. Sin embargo, hay otras metodologías orientadas a los planes que son opuestas a ágiles que pueden trabajar en proyectos.     

El proceso de la cascada mítica que se compara más a menudo con el ágil nunca existió y, por lo tanto, no puede considerarse muerto. Los procesos reales en cascada todavía están vivos y bien, y sobresalen en la entrega puntual del software de presupuesto que cumple con las expectativas del usuario.

La gente no usa el libro de texto modelo de cascada y probablemente nunca lo haya hecho.

Es una construcción teórica idealizada cuyo propósito es hacer que pienses en los pasos en el desarrollo de sistemas. El punto principal es que desea que los cambios más grandes se produzcan lo antes posible, porque nunca tendrá el tiempo ni el dinero para realizar un gran cambio una vez que se haya creado una gran cantidad de código.

A pesar del hecho de que es más una forma de pensar que un proceso, sigue siendo en gran medida la forma en que muchas, probablemente la mayoría de las organizaciones, se dedican a crear software (o casas, submarinos o cualquier otra cosa ...) .

En el mundo real, no tiene límites totalmente estrictos entre las fases y, a veces, vuelve a las fases anteriores para subproyectos pequeños. Lo que la metodología te dice no es que "estas cosas no están permitidas". Lo que le dice es "estas cosas le cuestan dinero y / o tiempo", así que intente evitar eso en el futuro.

Es bueno que Agile Snobs (TM) mire por la nariz a los desarrolladores "anticuados" y su metodología pintoresca e impracticable, pero el hecho es que Agile tampoco es una panacea. Algunos proyectos no pueden construirse utilizando Agile y muchos equipos que creen que Agile son en realidad descuidados y desorganizados.

La metodología no es el punto. El punto es pensar en lo que estás haciendo y por qué lo haces de esta manera , y obtener el mayor valor para el cliente en el menor tiempo razonable.

Quizás una mejor manera de preguntar a qué te refieres es "¿cuándo es menos iterativo y más formal mejor?"

Hay situaciones en las que este es el caso:

• Cuando los requisitos no cambien.

• Cuando cumplir con los nuevos requisitos es menos importante que alcanzar el 100% de los originales.

• Cuando todos los componentes de tecnología están maduros y bien entendidos.

En cierto sentido, puedes tomar lo contrario de lo que podría llevarte a ser ágil.

Muy pocas técnicas son aplicables en todas partes. Muy pocos no tienen ningún uso.

Sí, está muy vivo, aunque hoy en día es el más común " V model " que se utiliza

En cualquier caso, el problema que tiene Agile es que la solución casi nunca termina, el cliente puede continuar solicitando cambios y el desarrollo continuará resolviéndolos de manera iterativa. Para un proyecto que se basa en costos de tiempo y materiales, esto funciona muy bien. Para un proyecto que tiene un costo fijo, no lo tiene.

Para estos proyectos de costo fijo, el cliente casi siempre espera que los hitos predefinidos demuestren progreso, sin embargo, estos son más de la variedad escrita formal en lugar del código de trabajo. Para clientes como este, las especificaciones escritas se convierten en el proyecto, uno donde el desarrollo del software es una consideración secundaria (como se supone, si tiene un proyecto bien definido, el software debería ser fácil de desarrollar). Estas empresas también son las que hacen un uso intensivo de recursos de desarrollo baratos y subcontratados.

Entonces, si tiene una cantidad fija de dinero o tiempo, no espere que los requisitos cambien o no se les permita cambiar ningún requisito, y se espera que proporcionen un conjunto sólido de documentación escrita, entonces los modelos de cascada son la Sólo los que tienen sentido.

Agile puede introducirse en medio de estos proyectos para realizar el desarrollo, pero aún tiene una fase de aceleración en la que se crean las especificaciones a partir de los requisitos, y una fase de rampa en la que el software se instala y prueba in situ. Agile no responde bien a estos casos.

¿A quién? La mayoría de los gerentes con los que me he ocupado todavía usan el proceso de desarrollo de software de Waterfall para la programación, y parece que a los niveles superiores les gusta que sean fáciles de programar.

En la práctica, muy pocos desarrolladores que conozco creen que funciona o incluso son válidos.