¿Existe alguna circunstancia en la que un proyecto de cascada estricto pueda tener éxito cuando los requisitos no están claramente definidos?

7

No puedo ver cómo un proyecto de software puede hacer un progreso significativo bajo una metodología de cascada si los requisitos no se pueden establecer claramente desde el principio. ¿Me estoy perdiendo algo?

    
pregunta jl6 18.10.2011 - 23:00

8 respuestas

9

Usamos cascada y hemos completado muchos proyectos con requisitos cambiantes. La cascada no es tan mala como parece y Agile no es la bala de plata que lo arregla todo (tanto los proyectos ágiles mal hechos como los proyectos en cascada, por lo que puedo ver). Ninguna de las dos metodologías tiene una tasa de éxito particularmente alta , en parte porque los usuarios no saben cómo definir lo que quieren y en parte porque hay muchos incompetentes en nuestro campo.

    
respondido por el HLGEM 18.10.2011 - 23:15
2

El comentario de "Andrew" arriba es válido. Además, qué parte de los requisitos falta. La metodología de la cascada no es tan rígida como algunos creen. Waterfall se enfoca en moverse entre las etapas principales después de haber recopilado suficiente información y datos. No hay nada que le impida refinar su análisis mientras no esté haciendo una parte importante de él.

Por ejemplo, puede comenzar el diseño sin conocer todos los informes requeridos y puede comenzar el diseño sin conocer todas las reglas de validación. Todo eso siempre se puede agregar más tarde.

Sin embargo, no desea iniciar el diseño con solo 1/3 de las columnas en la base de datos identificada. La caída de agua es una excelente metodología y es bastante adecuada para la mayoría de las aplicaciones donde el negocio no se está inventando desde cero y donde los usuarios conocen el negocio.

Puede avanzar en el diseño de su base de datos, diseño de pantalla, arquitectura del sistema, casos de uso y más sin conocer todos los detalles por adelantado.

El arte aquí es dividir el problema en partes que pueden comenzar y progresar con la menor dependencia de otras áreas grises. Este es un enfoque generalmente bueno, independientemente de la metodología empleada.

    
respondido por el NoChance 18.10.2011 - 23:26
2

Depende de qué tan buenos sean los codificadores.

Si los programadores tienen un buen conocimiento del negocio en el que están trabajando y si son lo suficientemente inteligentes como para escribir el código de forma flexible, hacia el final de la cascada, cuando los clientes vean el producto, deben:

a) no tiene mucho de qué quejarse

y

b) lo que denuncian puede modificarse y arreglarse fácilmente

¡Tienes que ser bueno para que funcione!

    
respondido por el Mongus Pong 19.10.2011 - 10:42
1

Nunca he oído hablar de un proyecto que utilice una metodología de cascada que no incorporó órdenes de cambio. Entonces, en la práctica, si los requisitos iniciales son incorrectos (hasta cierto punto, siempre son incorrectos, excepto quizás en un proyecto pequeño, nunca los he visto 100% perfectos), solo tiene órdenes de cambio y rehaga lo que sea necesario. ¿Eso significa que no es realmente cascada? Es realmente una pregunta filosófica.

¿Puede tener éxito? Puede, pero la metodología no está tan enfocada a lidiar con los requisitos cambiantes, por lo que puede que no lo haga también.

En realidad, lo que he visto mucho es que cuando los requisitos no son precisos, la cascada tiene bastante éxito para los desarrolladores de software, no tanto para los clientes. La razón es que la mayoría de las veces se adoptó una metodología de cascada en primer lugar porque el cliente, bastante razonablemente, quería saber por adelantado exactamente lo que costaría el proyecto. Desafortunadamente nadie sabe cuánto costará un proyecto de software. A veces los clientes nunca lo descubren y se niegan a contratar a alguien que no les dé un precio fijo. Dado que en ese momento los desarrolladores que intentan obtener el negocio del cliente compiten principalmente sobre la base de cotizar un precio bajo, subestiman y esperan obtener ganancias en las órdenes de cambio, que cubren cualquier cosa más allá de los requisitos iniciales y generalmente tienen una tarifa por hora alta.

Por lo tanto, cuando los requisitos son malos, significa que los desarrolladores obtienen más de la parte rentable del contrato (órdenes de cambio) y menos de la parte no rentable (la lista de requisitos que el cliente pensó que quería recuperar cuando todo comenzó).

Pero, finalmente, los verdaderos requisitos se descubren y los cambios se hacen, por lo que para el cliente "tiene éxito" en el sentido de que se hace, aunque a un costo mayor en tiempo y dinero que si los requisitos fueran correctos inicialmente.

Por lo tanto, me gusta Agile personalmente por dos razones principales: primero, alinea los intereses del cliente y el desarrollador mejor que "¿es esto una orden de cambio?" Las batallas en cascada pueden llevar a, y segundo, porque los entregables frecuentes ayudan a mitigar los riesgos. Pero "pague y trataremos de escribirle un poco de software, pero aún no sabemos cuánto obtendrá por su dinero" es difícil de vender a veces, incluso si en realidad solo es admitir la realidad subyacente de la situación. .

    
respondido por el psr 19.10.2011 - 00:18
0

Los requisitos que no se definen claramente no condenan automáticamente el proyecto, OMI. La probabilidad de que falle es alta. Lo concederé, aunque puede haber casos en los que todavía tenga éxito.

    
respondido por el JB King 18.10.2011 - 23:16
0

Se puede. Solo tiene que incluir la contingencia en sus estimaciones iniciales y explicar que si los requisitos son inciertos, también lo son sus estimaciones. Si los requisitos están llegando al mismo ritmo que el desarrollo está progresando, funcionará bien.

Recuerda que Waterfall no es lo opuesto a Agile. Todo lo que está diciendo es que no entregará componentes de forma incremental. Es simplemente "dénos sus requisitos lo antes posible y lo codificaremos para entregarle un producto al final. Pero si no nos presenta los requisitos lo suficientemente rápido, su producto se retrasará".

Sin embargo, Scrum está diseñado para manejar la incertidumbre y el cambio y todavía creo que es la mejor manera de hacerlo. Solo digo que si el cliente no está interesado, eso no significa que esté seguro de fallar.

    
respondido por el pdr 18.10.2011 - 23:17
0

Permítame recomendarle que lea "La marcha de la muerte" de Ed Yourdon. Una vez que te das cuenta de que no eres el ÚNICO que trabaja en condiciones menos que ideales, es realmente útil y motivador. Dicho esto, tampoco me ha disuadido de hacer preguntas incómodas, como ¿por qué estamos codificando sin requisitos claramente definidos?

    
respondido por el Kennah 19.10.2011 - 10:34
0

La circunstancia de éxito al responder la pregunta de cuánto tiempo tomará construir algo que ni tú ni el cliente entendemos es decir que tomará mucho más tiempo de lo que crees. Ponga en meses, o años de holgura si es necesario.

    
respondido por el Sign 19.10.2011 - 15:04

Lea otras preguntas en las etiquetas