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

Por supuesto, la cascada es viable. ¡Nos llevó 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 marco simple en lugar de una metodología.

Querer implementar una metodología porque alguien en un blog que te gusta habla de ello es tan estúpido como dejar que los problemas sigan sin hacer nada.

Empiezas diciendo:

  

Los dos predominantes   filosofías de desarrollo de software 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 estuviera de moda, las personas solían hablar sobre una gran variedad de enfoques diferentes para la construcción de software. Siguen existiendo hoy en día, pero de alguna manera a menudo se agrupan en un gran lío 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 cascada. Miles de desarrolladores crean software extremadamente complejos para aeronaves, sistemas críticos para la vida, banca, etc., utilizando métodos no ágiles todos los días.

Así que sí, por supuesto, hay una alternativa viable a ágil.

Primero, voy a estar en desacuerdo con sus declaraciones:

  

La cascada dice: el cambio es costoso, por lo que debe minimizarse.
Agile dice: el cambio es inevitable, por lo tanto, haga el cambio barato.

Mi interpretación es:

Waterfall dice: El cliente sabe lo que quiere.
Agile dice: El cliente no sabe lo que quiere, así que tendremos que hacer algunas versiones diferentes.

La mejor implementación de "cascada" que he visto en mi vida fue un gran proyecto de integración con un cliente financiero muy grande y había alrededor de 40 subproyectos involucrados. El paquete de escritorio y sitio web que proporcionamos fue solo 1 de esos 40 subproyectos. Si bien pensé que explotaban el dinero de otras personas en exceso, tenían sus cosas juntas y mantenían más de 40 barcos diferentes que se movían juntos en formación. El proyecto se puso en marcha en la fecha prevista (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 hizo a tiempo y según las especificaciones. El horario de la noche de Go-live fue de aproximadamente 100 páginas y aproximadamente 40 de esas páginas fueron detalles de contacto de emergencia de pánico de todo tipo de personas involucradas. Me impresionó mucho este cliente.

O, puede hacer lo que hacemos, que se ejecuta y hacer lo que es el informe más reciente de quejas / errores, y llamar a eso ágil.

Sí, varias técnicas de desarrollo de software son todas viables dependiendo de su dominio del problema. Es "Caballos para Cursos".

Por ejemplo, estás 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 de cascada (o incluso más estricto); si es posible, debe resolver todos los problemas de manera directa (o ¡BOOM!).

¿Está creando la última interfaz de usuario de marketing web 2.0 / 3.0 / buzzy? Agile es una manera mucho mejor de ir (necesitas un feedback rápido y un cambio).

Hay lo que yo llamaría principios de fabricación de software que aún se pueden aplicar sin importar la metodología, por ejemplo:

• control de fuente
• construir y CI
• programación de pares
• 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 correcto para ti, tu equipo y tu dominio de problemas.

El problema radica en la complejidad del software. La cascada es ideal para cosas como la construcción de puentes y la 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 se puede utilizar un programa de construcción real como un proyecto de construcción real.

Cambios de software. El software cambia rápidamente. La ley de Moore establece que la cantidad 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 como 2 ^ (2t).

El software cambia rápidamente, y la complejidad aumenta exponencialmente con él.

Al controlar el costo del software, desea controlar los factores exponenciales , no solo los multiplicativos o los aditivos. Cambiar el código aumenta la complejidad (y se vuelve exponencialmente más complejo a medida que avanza el proyecto) de manera exponencial.

Cambiar 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 puede hacer eso en ningún otro tipo de disciplina de ingeniería (como construir carreteras. No inventa un pavimento nuevo solo para allanar una carretera 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 administración, los procesos, los empleados capacitados, para desarrollar software versionado. Con un método de cascada, necesitarías volver a entrenar a tu equipo para manejar incluso las correcciones de errores menores.

de todos modos, mis 2 centavos.

Para responder a la pregunta, ¿existe una alternativa viable para el software tal vez no, o aún no, al menos en el caso general? Creo que todo se reduce a la naturaleza del software. El software, al ser información, puede ser duplicado de forma gratuita. A diferencia de un puente o una casa. Esto significa que, con la práctica, podría mejorar en la construcción de una casa y operar en un dominio relativamente simple. ¿En qué punto, por qué no utilizar un enfoque de un solo disparo?

Pero como 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 riesgoso, me gustaría probar experimentos e incrementar e iterar.

Las estaciones de energía nuclear y los sistemas de conexión por cable a menudo se dan como ejemplos de software que querría hacer en cascada. ¿Pero no fue el sistema de aviónica de lanzadera desarrollado de forma iterativa? ¿Cómo fueron los sistemas de control de tráfico aéreo de Canadá y Estados Unidos?

Y si OPEN / Metis es iterativo e incremental, entonces, para mí, parece que tiene una filosofía ágil, incluso si no se asocia con otras prácticas ágiles comunes.

El método de cascada es ciertamente viable y es tan sólido filosóficamente como cualquier otro enfoque. Recuerde que Waterfall ha existido por mucho más tiempo que Agile, pero tenga en cuenta que este no es un argumento para determinar si una metodología es mejor que otra.

Utiliza el método Waterfall cuando se tiene una comprensión muy clara de todo el dominio del problema y lo que el cliente desea lograr en un paquete de software. Probablemente haya cotizado un precio fijo al asumir el contrato, y su cliente entiende 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 distintas etapas de desarrollo, y es a menudo el caso de que cada etapa sea completada por un equipo diferente, a veces incluso una empresa diferente, cada una de las cuales no necesariamente se encuentra en Contacto con los demás. Con frecuencia se ve que Waterfall se aplica con buenos resultados en proyectos militares y gubernamentales cuando se licitan a contratistas externos. Cuando Waterfall y otros enfoques similares obtienen una mala reputación es cuando los desarrolladores se encuentran con 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 culpa de la metodología, sino de su aplicación.

La comparación entre Agile y cualquier metodología es falsa. Agile 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 cree que minimizar el cambio en el software es una opción viable para aquellos que desean entregar software valioso?

Cada oportunidad de minimizar el cambio es valiosa tanto para el desarrollador como para el cliente. Los cambios pueden hacer que un programa se deslice, o que las funciones se omitan para cumplir un programa. Es la forma en que gestiona los efectos del cambio que influye en el valor de sus proyectos.

  

¿O es realmente la pregunta sobre 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 elige un método que funcione para usted. Si te gusta el enfoque particular, síguelo. Si no se ajusta a tus necesidades, cámbiala. La manera en que se desarrolla el software realmente se reduce a tratar de hacer el mejor uso de los recursos que tiene a mano, y a minimizar las prácticas que pueden llevar a su proyecto al fracaso, y a menudo se da cuenta de que necesita cambiar su método para adaptarlo al proyecto particular a la mano.

Realmente una cosa es decir "Ok, ahora somos ágiles", y otra muy distinta es vivir y trabajar según la filosofía que Agile es. Ya sea que utilice Waterfall, Incremental, Spiral, SCRUM, XP, FDD o cualquier otro método, básicamente está en Agile donde valora:

• Personas e interacciones sobre procesos y herramientas
• Software de trabajo sobre documentación completa
• Colaboración del cliente en la negociación del contrato
• Respondiendo al cambio siguiendo un plan

y donde reúnes tus herramientas, método y experiencia para aplicar estos valores con éxito.

Sí, los modelos de proceso en cascada, en espiral, iterativos y otros híbridos son todos 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 con qué precisión puede planificar y predecir.

La afirmación de que "las dos metodologías de desarrollo de software predominantes son rápidas y ágiles" es falsa, ya que existe un espectro de procesos de desarrollo de software, y muchas compañías sintetizan su propia versión del modelo de proceso, a menudo cambiando para un proyecto dado. Hay más de dos enfoques viables para el desarrollo de software. Aunque Waterfall y Agile tienden a caer en 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.

Agile dice: El cambio es inevitable, así que haz el cambio barato.

Pero esa no es toda la historia. Las empresas deben poder planificar y predecir, pero el software es un proceso creativo y las estimaciones a menudo son erróneas. ¿Recuerdas el triángulo bueno, rápido, barato? Agregue una cuarta dimensión, procese, y descubra que reducir el esfuerzo del proceso también puede comprimir el programa, cuando las estimaciones resultan ser erróneas y un proyecto está en peligro de demora. El software es un proceso fungible (mutable), y Agile, Iterative, Spiral ofrecen la capacidad de ofrecer funcionalidad incremental en intervalos más cortos.

Los modelos de procesos impulsados por cascada y otros requisitos tienen controles para manejar el cambio, por lo que es inexacto decir que la cascada 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 el horario impacto cuando tienes requisitos y diseño por adelantado). Cuando está construyendo un producto, o necesita la necesidad de definir por completo los requisitos (funcionalidad), es conducido a uno de los modelos híbridos.

Y cuando las estimaciones son erróneas, a menudo el proceso (la cuarta pata del triángulo de hierro) se sacrifica para cumplir con el cronograma.

Los enfoques maduros ágiles y en cascada no se distinguen 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 compañía 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 de control de calidad sólido y una empresa que impulsa el desarrollo son lo más importante para producir un software de primera clase.