Las dos metodologías de desarrollo de software predominantes son cascada y ágil. Cuando se discuten estos dos, a menudo hay mucho enfoque en las prácticas particulares que los distinguen (programación de pares, TDD, etc. vs. especificaciones funcionales, diseño inicial grande, etc.)
Pero las diferencias reales son mucho más profundas, ya que estas prácticas provienen de una filosofía.
Waterfall dice: El cambio es costoso, por lo que debe minimizarse.
Ágil dice: El cambio es inevitable, así que haga que el cambio sea barato.
Mi pregunta es, independientemente de lo que piense de TDD o especificaciones funcionales, ¿es realmente viable la metodología de desarrollo en cascada?
¿Alguien realmente piensa que minimizar el cambio en el software es una opción viable para aquellos que desean entregar un software valioso? ¿O se trata realmente de qué tipo de prácticas funcionan mejor en nuestras situaciones para gestionar el cambio inevitable?
fuente
Respuestas:
Por supuesto que la cascada es viable. ¡Nos trajo a la luna!
¡Y es un entrenador ágil hablando aquí!
A menos que pueda identificar claramente los problemas relacionados con la forma en que administra sus proyectos, no hay una razón válida para cambiar.
Como alternativa a las metodologías Agile y Waterfall , sugeriré SU metodología . Adaptado a su negocio específico, su equipo específico, sus productos, su forma de trabajar, la cultura de su empresa ... Es por eso que Scrum se llama un marco simple en lugar de una metodología.
Querer implementar una metodología porque alguien en un blog que te gusta ha hablado es tan estúpido como dejar pasar los problemas sin hacer nada.
fuente
Primero, voy a estar en desacuerdo con sus declaraciones:
Mi interpretación es:
Waterfall dice: el cliente sabe lo que quiere.
Agile dice: El cliente no sabe lo que quiere, por lo que tendremos que hacer algunas versiones diferentes.
La mejor implementación de "cascada" que he visto fue un gran proyecto de integración con un gran cliente financiero y hubo más de 40 subproyectos involucrados. El paquete de escritorio y sitio web que suministramos era solo 1 de esos más de 40 subproyectos. Si bien pensé que gastaban el dinero de otras personas de manera bastante excesiva, tenían sus cosas juntas y mantenían más de 40 naves diferentes todas juntas en formación. El proyecto se puso en marcha en la fecha objetivo (el objetivo se movió una vez durante el proyecto) y aunque pensé que podrían haberlo hecho de manera más frugal y ágil, se realizó a tiempo y según las especificaciones. El horario de la noche de puesta en marcha fue de aproximadamente 100 páginas y aproximadamente 40 de esas páginas eran datos de contacto de emergencia de pánico de todo tipo de personas involucradas. Me impresionó mucho este cliente.
O bien, puede hacer lo que hacemos, que es correr y hacer lo que el más reciente informe de queja / bug, y llamar a que ágil.
fuente
Empiezas diciendo:
Esto es falso Esta dicotomía ha sido construida por la comunidad ágil para crear un oponente contra el cual posicionarse. Antes de que Agile se pusiera de moda, la gente solía hablar sobre una miríada de enfoques diferentes para construir software. Todavía existen hoy en día, pero de alguna manera son agrupados en un gran desastre llamado "cascada" por los defensores ágiles.
He estado usando OPEN / Metis y sus variantes durante más de 10 años con gran éxito. Definitivamente no es ágil, y definitivamente no es una cascada. Miles de desarrolladores crean software extremadamente complejo para aviones, sistemas críticos para la vida, bancos, etc., utilizando métodos no ágiles todos los días.
Entonces sí, por supuesto, hay una alternativa viable a ágil.
fuente
Sí, varias técnicas de desarrollo de software son viables según el dominio del problema. Es "Caballos para los cursos".
Por ejemplo, está escribiendo software para controlar una planta de energía nuclear o para conducir el transbordador espacial de la NASA. Este tipo de dominio de problemas probablemente se adapte mejor a un enfoque en cascada (o incluso más estricto), si es posible desea resolver todos los problemas por adelantado (¡o BOOM!).
¿Está construyendo el último término de marketing web 2.0 / 3.0 / buzzy UI? Ágil es una forma mucho mejor de hacerlo (necesita esa retroalimentación rápida y cambio).
Hay lo que yo llamaría principios de artesanía de software que todavía se pueden aplicar sin importar qué metodología sea, por ejemplo:
y más.
Hagas lo que hagas, no escuches a los fanáticos a ambos lados de la ecuación, haz lo que sea correcto para ti, tu equipo y tu dominio del problema.
fuente
El problema proviene de la complejidad del software. Cascada funciona muy bien para cosas como la construcción de puentes y pavimentación de carreteras porque la física nunca cambia. Claro, en algún momento desarrollaremos un nuevo asfalto, pero no revolucionará la forma en que se construyen las carreteras. El acero en la suspensión de un puente es del tamaño correcto o no lo es. No puede criticar o tropezar un proyecto de construcción real como puede hacerlo con el software.
Cambios de software. El software cambia rápidamente. La ley de Moore establece que el número de transistores en un chip se duplica cada 18-24 meses. En corolario, el número de líneas de código en un programa también se duplica. La complejidad entre esas líneas de código, por lo tanto, aumenta con un bigO de algo así como 2 ^ (2t).
El software cambia rápidamente y la complejidad aumenta exponencialmente con él.
Al controlar el costo del software, desea controlar factores exponenciales , no solo multiplicativos o aditivos. Cambiar el código aumenta la complejidad (y se vuelve exponencialmente más complejo a medida que el proyecto avanza) de manera exponencial.
El cambio es inevitable. La naturaleza misma de la programación extiende el lenguaje con clases y métodos personalizados, cambiando así el lenguaje en sí. No se puede hacer eso en ningún otro tipo de disciplina de ingeniería (como construir carreteras. No se inventa un nuevo pavimento solo para pavimentar un camino en Kansas sobre California).
El método ágil también le brinda una plataforma para manejar futuras versiones y correcciones de errores. Ya tiene las herramientas de gestión, procesos, empleados capacitados, para desarrollar software versionado. Con un método en cascada, necesitaría volver a capacitar a su equipo para manejar incluso pequeñas correcciones de errores.
de todos modos, mis 2 centavos.
fuente
Para responder a la pregunta, ¿existe una alternativa viable para el software que tal vez no, o aún no, al menos en el caso general? Creo que se trata de la naturaleza del software. El software, al ser información, puede duplicarse de forma gratuita. A diferencia de un puente o una casa. Esto significa que, con la práctica, podría ser bueno para construir una casa y operar en un dominio relativamente simple. ¿En qué punto por qué no usar un enfoque de una sola vez?
Pero debido a que el software tiene cero costos de duplicación, ¿por qué harías lo mismo dos veces? El software tiende a alejarse de la fabricación. Entonces, si todo el software es la creación de un nuevo producto, entonces siempre estamos operando en un dominio complejo donde, hasta cierto punto, no sabemos lo que estamos haciendo. O es costoso saberlo por adelantado y es más barato descubrirlo haciendo. En un dominio complejo y arriesgado, me gustaría probar experimentos e incrementar e iterar.
Las estaciones de energía nuclear y los sistemas de cables aéreos a menudo se dan como ejemplos de software que desearía hacer en cascada. ¿Pero no se desarrolló el sistema de aviónica lanzadera de forma iterativa? ¿Cómo fueron los sistemas de control de tráfico aéreo canadiense y estadounidense?
Y si OPEN / Metis es iterativo e incremental, entonces, para mí, parece que tiene la filosofía ágil, incluso si no se asocia con otras prácticas ágiles comunes.
fuente
El método de la cascada es ciertamente viable y es tan filosóficamente sólido como cualquier otro enfoque. Recuerde que Waterfall ha existido mucho más tiempo que Agile, pero tenga en cuenta que este no es un argumento para afirmar si una metodología es mejor que otra.
Utiliza el método Cascada cuando tiene una comprensión muy clara sobre todo el dominio del problema y lo que el cliente quiere lograr en un paquete de software. Probablemente haya cotizado un precio fijo al contratar el contrato, y su cliente comprende que no puede desviarse de los requisitos acordados. Su proceso es estrictamente uno que fluye a través de una serie de aprobaciones entre las diversas etapas de desarrollo, y a menudo es el caso de que cada etapa la complete un equipo diferente, a veces incluso una compañía diferente, cada una de las cuales puede no necesariamente en contacto con los demás. A menudo se ve que Waterfall se aplica con buenos resultados en proyectos militares y gubernamentales cuando se licitan a contratistas externos. Donde Waterfall y otros enfoques similares obtienen una mala reputación es cuando los desarrolladores tienen problemas, como una estimación deficiente, horarios planificados sin tiempo de contingencia o una comprensión deficiente o incompleta del dominio del problema. El problema nunca es realmente una falla de la metodología, sino de su aplicación.
La comparación entre Agile y cualquier metodología es falsa. Ágil no es una metodología, es una filosofía, o quizás sería mejor decir que es un término general que representa una forma diferente de ver cómo se desarrolla el software. Una metodología es simplemente una herramienta, y como tal su valor siempre será menor que los individuos y las interacciones que están en el corazón de lo que significa ser ágil .
Cada oportunidad para minimizar el cambio es valiosa tanto para el desarrollador como para el cliente. Los cambios pueden hacer que un cronograma se deslice o que se omitan funciones para cumplir con un cronograma. Es cómo maneja los efectos del cambio lo que impacta en el valor de sus proyectos.
Sus prácticas pueden ayudar en la gestión del cambio, o pueden ignorar el cambio por completo. Lo que importa es la combinación de sus prácticas de desarrollo y la gestión de su relación con sus clientes, y si estas cosas funcionan juntas de manera efectiva para todas las partes involucradas.
Aquellos de nosotros que somos para todos los efectos Agile entendemos que usted elige un método que funcione para usted. Si te gusta un enfoque particular, síguelo. Si no se ajusta a tus necesidades, cámbialo. La forma en que elabora el software realmente se reduce a tratar de hacer el mejor uso de los recursos que tiene a mano, y minimizar esas prácticas que pueden conducir a su proyecto hacia el fracaso, y a menudo descubre que necesita cambiar su método para adaptarse a proyecto particular a la mano.
Realmente es una cosa decir "Ok, así que ahora somos ágiles", y otra totalmente distinta es vivir y trabajar según la filosofía que es Agile. Ya sea que use Waterfall, Incremental, Spiral, SCRUM, XP, FDD o cualquier otro método, básicamente es ágil donde valora:
y dónde reúne sus herramientas, método y su experiencia todos juntos para aplicar estos valores con éxito.
fuente
Sí, los modelos de procesos en cascada, en espiral, iterativos y otros híbridos son viables, pero el cambio es inevitable. El proceso es más que solo cómo manejar el cambio, y (afirmo que) el mayor determinante es qué tan bien conoce / comprende el problema y qué tan exactamente puede planificar y predecir.
Afirmar que "las dos metodologías de desarrollo de software predominantes son en cascada y ágiles" es poco común, ya que existe un espectro de procesos de desarrollo de software, y muchas empresas sintetizan su propia versión del modelo de proceso, que a menudo cambia para un proyecto determinado. Existen más de dos enfoques viables para el desarrollo de software. Aunque Waterfall y Agile tienden a caer en los extremos opuestos del espectro de "cambio", es razonable tipificar estas metodologías en competencia como,
Waterfall dice: El cambio es costoso, por lo que debe minimizarse.
Ágil dice: El cambio es inevitable, así que haga que el cambio sea barato.
Pero esa no es toda la historia. Las empresas necesitan poder planificar y predecir, pero el software es un proceso creativo y las estimaciones a menudo son incorrectas. ¿Recuerdas el triángulo bueno - rápido - barato? Agregue una cuarta dimensión, proceso, y encontrará que reducir el esfuerzo del proceso también puede comprimir el cronograma, cuando las estimaciones resultan ser incorrectas y un proyecto está en peligro de demora. El software es un proceso fungible (mutable), y Agile, Iterative, Spiral ofrecen la capacidad de ofrecer una funcionalidad incremental en intervalos más cortos.
Los modelos de proceso impulsados por Waterfall y otros requisitos tienen controles para manejar el cambio, por lo que es incorrecto decir que Waterfall minimiza el cambio, es más preciso decir que Waterfall reconoce y gestiona el cambio y comunica el impacto de ese cambio (porque el cambio causa un impacto en el cronograma cuando usted tener requisitos y diseño por adelantado). Cuando está creando un producto o necesita definir completamente los requisitos (funcionalidad), se lo dirige a uno de los modelos híbridos.
Y cuando las estimaciones son incorrectas, a menudo se sacrifica el proceso (el cuarto tramo del triángulo de hierro) para cumplir con el cronograma.
fuente
Los enfoques ágiles y en cascada maduros son indistinguibles entre sí. Su suposición sobre el objetivo del enfoque de cascada es incorrecta. Ambos tienen el objetivo de producir software de calidad. Cuando no tiene un enfoque de desarrollo sólido para la empresa en su conjunto, debe observar qué enfoque proporcionará la menor cantidad de fricción para la adopción. Al final, los ciclos de desarrollo cortos, un equipo sólido de control de calidad y una empresa que impulsa el desarrollo son lo más importante para producir software de primer nivel.
fuente