¿Existe una alternativa viable a la metodología de desarrollo ágil?

47

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?

Eric Wilson
fuente
1
interesante pregunta. esperando las respuestas.
DevSolo
1
Pregunta relacionada: ¿Hay alguna alternativa importante a Waterfall and Agile?
Peter Boughton el
3
@FarmBoy - Buena pregunta. Veo la filosofía ágil un poco diferente. Lo escribiría como "Agile dice: El cambio es inevitable, así que haga que sea barato determinar el costo del cambio". El cambio aún puede ser muy costoso, pero en ágil puede resolverlo de manera rápida y económica para que siempre sepamos el costo del cambio. Dicho de otra manera, hace que la gente piense que, dado que están haciendo un cambio ágil, será barato. Algunos cambios cuestan mucho sin importar el proceso.
Mike Two
1
@ Yannis Rizos: ¿por qué cierra esta interesante pregunta solo, sin un solo voto de la comunidad?
1
@ Pierre303 debido a esta pregunta que la discusión aquí trajo esta pregunta.
Ryathal

Respuestas:

59

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
10
+1 en SU ​​metodología, el próximo entrenador ágil que me dice que SCRUM es la única forma de obtener una bota en la parte trasera;)
Martijn Verburg
1
@karianna: Hago SCRUM específicamente, pero a veces, simplemente no es apropiado. Por otro lado, también vi al equipo tratando de vender SCRUM a sus jefes pensando que resolvería su problema. Fracasaron porque el problema no eran sus jefes ni su primer ministro. No hay una sola regla. Cada caso su solución. Y sí, la mayoría de los problemas de organización se pueden resolver con técnicas ágiles, pero ágil no es una bala de plata.
55
No solo la luna. El transbordador espacial tenía ~ 1M líneas de código C en sus sistemas integrados. Durante ~ 30 años, solo tenían 2 errores que se convirtieron en compilaciones de producción.
Dan Neely
2
La cascada también mató a los primeros tres astronautas. Esta insistencia en el uso de este programa Apollo como un elemento secundario para Waterfall es ignorante en el mejor de los casos. Waterfall también es citado como responsable de que ambos programas sean una carga financiera completa, y que el Shuttle sea un "ferrari espacial" frágil y costoso demasiado ingeniero cuando la especificación original era para un "camión espacial". Estoy bastante seguro de que SpaceX no estaría de acuerdo con Waterfall.
44
@DanNeely el alto nivel de calidad del software del transbordador espacial no era barato. Aparentemente, el precio era del tamaño de $ 1000 por línea de código.
21

Primero, voy a estar en desacuerdo con sus declaraciones:

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 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.

Tangurena
fuente
8
Según Agile Dilbert: is.gd/lDoQgb
Peter K.
11
Es más como "Waterfall dice: el cliente no sabe lo que quiere, así que sentémonos, hablemos y acordemos lo que quieren antes de comenzar a
hackearlo
+1: Muy buena respuesta. Creo que la comunidad ágil tiene un problema básico: lo ágil es bueno en ciertos contextos para ciertas clases de proyectos y clientes, pero no ven que hay proyectos en los que los requisitos no cambian tan rápido y los enfoques más estructurados son una mejor opción . Creo que la comunidad ágil debería tratar de identificar de manera realista las áreas en las que su enfoque es una mejor opción (creo que tales áreas existen) y no tratar de impulsarlo como una solución general, porque no lo es.
Giorgio
66
@scrwtp - y Agile es más como "Mi cliente no sabe lo que quiere, y no puede / no quiere hablar y pensarlo, y cambian de opinión cada 5 minutos. Tengo que empujarles algo en la cara para obtener respuestas significativas ". Guau. Eso suena realmente desafortunado cuando lo escribo.
Michael Kohne
1
@scrwtp: Creo que la pregunta del millón es: ¿esa "creencia" de que puedes "sentarte y hablar y acordar" es viable? La respuesta es: depende, ¿verdad? Depende de una serie de variables: ¿qué tan grande es el proyecto? ¿SABEMOS qué tan grande es? ¿Cuánto tiempo tienen los clientes para "sentarse" con nosotros? Hemos intentado durante décadas relacionar el desarrollo de software con la construcción, que es casi 100% prescriptivo. El desarrollo de software está en algún punto intermedio entre "totalmente reaccionario" y "100% prescriptivo". En la mayoría de las tiendas, está más cerca de ser "completamente reaccionario", de ahí la adopción ágil.
Calphool
21

Empiezas diciendo:

Las dos filosofías de desarrollo de software predominantes son cascada y ágil.

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.

CesarGon
fuente
66
No puedo entender rápidamente qué es OPEN / Metis de ese enlace. (Por lo general, no es necesario descargar una metodología). Mi pregunta es: ¿cuál es su filosofía, particularmente al tratar con el cambio? ¿Intenta minimizar el cambio o reducir el costo del cambio? Tenga en cuenta que mi pregunta era sobre filosofía ágil, no sobre prácticas ágiles.
Eric Wilson
OPEN / Metis tiene un ciclo de vida iterativo que crea sistemas de forma incremental. El cambio se reconoce como algo que no solo sucede, sino que es genial cuando sucede, ya que el propósito mismo del desarrollo de un sistema de información es efectuar algún cambio. Sin embargo, el costo del cambio se controla y administra a través de un ciclo de vida apropiado y prácticas asociadas.
CesarGon
1
Con respecto a su comentario sobre las "metodologías de descarga", bueno ... usted no descarga metodologías, estoy de acuerdo. Descarga documentos que describen metodologías. De lo contrario, ¿cómo se entera de ellos? Mira la miríada de libros que describen XP, Scrum, etc.
CesarGon
1
@CesarGon Demasiado parafraseando a Cheece y Chong: "parece ágil, huele a ágil, se siente ágil, sabe a ágil; debe ser ágil ..."
10

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:

  • Fuente de control
  • construir y CI
  • programación en pareja
  • TDD
  • Doy un ^% $$ &

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.

Martijn Verburg
fuente
La cascada funciona si te lo puedes permitir. Alguien más arriba afirmó que el costo del software del proyecto lunar de la NASA era de aproximadamente $ 1000 por línea de código. La mayoría de las tiendas necesitan algo como $ 1–10 por línea de código y ágil es mejor para ese tipo de situaciones. Sin embargo, no pretendo que ágil proporcione una mejor calidad en general. Básicamente se reduce a si puede permitirse el lujo de buscar mucho dinero para estar bastante seguro de que el software es correcto o es más barato encontrar la solución una vez que descubre que el software no es correcto.
Mikko Rantalainen
2

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.

Stephen Furlani
fuente
2
Hay muchos aspectos del diseño de software que son tan absolutos como las leyes de la física. Agile es una herramienta como cascada u otras metodologías, y como otras personas publicaron, hay muchos casos de negocios en los que no tiene sentido. Me sorprendería si te viera en la fila para subirte a un avión donde Boeing dijo que estaban en medio de un proceso ágil en el software de control de vuelo y que necesitaban que los clientes repitieran si el avión no voltea en el aire sin razón.
Hounshell el
Y solo para disparar más agujeros en su argumento, se están diseñando diseños de carreteras en este momento que serían apropiados para una carretera entre Kansas y California, pero no entre Nueva York y Boston. Y nuevas técnicas para manejar el asfalto están saliendo todo el tiempo.
Hounshell
2
Y, por último, usted dice: "Con un método de cascada, necesitaría volver a capacitar a su equipo para manejar incluso pequeñas correcciones de errores". Eso es tan ignorante de cómo funciona el proceso en cascada. Debería probar una buena tienda de cataratas antes de exponerse sobre cómo es inapropiado para cada escenario de desarrollo de software.
Hounshell el
1
Hola Stephan, no todos los requisitos de software cambian constantemente.
Paul Nathan
1
El negocio siempre cambia ; un negocio que no está cambiando y adaptándose es un negocio que está muriendo. El tiempo es una constante , que no interactúa bien con el cambio. Un sistema que tiene la filosofía de reconocer que se espera un cambio puede acomodar el cambio, de lo contrario, el tiempo tiene que acomodar el cambio, ¡y es una constante constante!
2

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.

AlanMJackson
fuente
2
Entonces, ¿ahora ágil está tratando de tomar el crédito por iterativo e incremental? No importa que iterativo e incremental hayan sido partes PRINCIPALES del desarrollo en cascada desde que comencé el desarrollo en el '92.
Dunk
1

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 .

¿Alguien realmente piensa que minimizar el cambio en el software es una opción viable para aquellos que desean entregar un software valioso?

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.

¿O se trata realmente de qué tipo de prácticas funcionan mejor en nuestras situaciones para gestionar el cambio inevitable?

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:

  • Individuos e interacciones sobre procesos y herramientas
  • Software de trabajo sobre documentación completa
  • Colaboración del cliente sobre negociación de contrato
  • Responde al cambio sobre el siguiente plan

y dónde reúne sus herramientas, método y su experiencia todos juntos para aplicar estos valores con éxito.

S.Robins
fuente
2
Guau. Hay tantas cosas extrañas aquí. Cascada es viable sobre la base de estar alrededor por más tiempo? Cascada se justifica sobre la base del uso en contratos de defensa? ¿Cada oportunidad para minimizar el cambio es realmente en el mejor interés del cliente, o lleva a entregar lo que él pensó que quería en lugar de lo que realmente quería? Como parece que te importa esto, he tratado de entender de dónde vienes, pero me falta algo.
Eric Wilson
1
@EricWilson Waterfall ha existido por más tiempo y se ha utilizado con éxito mucho antes de que se discutiera la filosofía Agile. Es viable porque existe y, cuando se aplica correctamente, funciona para aquellos que desean usarlo. No justifiqué su uso, sino que simplemente señalé un ejemplo en el que he tenido experiencia personal donde lo he visto funcionar, y sí, también he visto algunas fallas espectaculares. No busca oportunidades para minimizar el cambio, desea oportunidades para introducir el cambio, pero necesita hacerlo con sensatez, de lo contrario, su cliente obtiene menos de lo que quería o un plazo límite.
S.Robins
0

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.

ChuckCottrill
fuente
No fui sincero. Después de cinco años de desarrollo en una variedad de compañías, solo me he encontrado con dos, y una solo es nombrada como peryorativa. ¿Espiral? Nunca lo oí.
Eric Wilson
Quise decir que no los había encontrado en el mundo real. Hay todo tipo de cosas en las redes sociales, pero no voy a comenzar a buscarlas ahora solo porque hice una pregunta en 2010.
Eric Wilson
-1

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.

Charles Lambert
fuente
1
Pondría una advertencia a tu comentario. La cascada requiere gente talentosa o caerá de bruces. Aprender a diseñar bien es difícil. Aprender a codificar es comparativamente muy fácil. En mi opinión, esa es la razón principal por la que la mayoría de los desarrolladores parecen preferir ser ágiles.
Dunk
44
Puedo decir lo mismo de ágil. Los desarrolladores de Jr. sin orientación pueden hacer un lío ágil con rapidez.
Charles Lambert