Recientemente me interesé por las prácticas ágiles en el desarrollo de software y desde entonces he visto muchos artículos que señalan que estas prácticas permiten reducir los costos generales.
La lógica detrás de esto generalmente es la siguiente: si sus requisitos cambian, puede reflejar este cambio en el próximo retraso del sprint y esto conducirá a un costo reducido, porque el diseño de la nueva característica y su implementación está muy cerca en términos de tiempo, por lo que el el costo disminuye, de acuerdo con la famosa regla de que cuanto más tarde necesite realizar un cambio en sus requisitos, más costoso será satisfacer ese requisito.
Pero los proyectos de software medianos a grandes son complejos. Un cambio repentino en los requisitos no significa que no tendrá que tocar otras partes de su sistema para cumplir con ese requisito. En muchos casos, la arquitectura deberá modificarse de manera muy significativa, lo que también significa que deberá volver a implementar todas las características que se basaban en la arquitectura anterior. Entonces, todo el punto de los costos reducidos desaparece aquí. Por supuesto, si un nuevo requisito requiere una nueva parte independiente del sistema, eso no es un problema, la arquitectura antigua simplemente crece, no es necesario repensarla y volver a implementarla.
Y lo contrario. Si está utilizando una cascada y de repente se da cuenta de que debe introducirse un nuevo requisito, puede ir y cambiar su diseño. Si requiere que se modifique la arquitectura existente, debe rediseñarla. Si realmente no se mete con él pero solo introduce una nueva parte del sistema, entonces vas y haces todo el trabajo, no hay problema aquí.
Dicho esto, me parece que la única ventaja que tiene el desarrollo ágil es la creación de funciones completas entre sprints, y para muchas personas y proyectos esto no es crítico. Además, parece que ágil da como resultado una mala arquitectura de software en general, porque las características se unen entre sí, a los equipos ágiles solo les importa que una característica funcione, no cómo funciona. Esto parece ser así cuando los sistemas crecen en complejidad con el tiempo, las prácticas de desarrollo ágiles en realidad aumentan el caos en la arquitectura general del producto, lo que eventualmente resulta en costos más altos, ya que será cada vez más difícil introducir cambios, mientras que cascada le permite perfeccionar su arquitectura antes de liberar nada.
¿Alguien puede indicarme dónde me estoy equivocando aquí, porque obviamente mucha gente usa ágil en entornos de producción, por lo que debo estar equivocado en alguna parte.
Respuestas:
En primer lugar, el modelo de "cascada" siempre fue un hombre de paja que describía cómo NO ejecutar un proyecto de desarrollo de software. Búscalo.
De todos modos, la mayoría de los proyectos SDLC "en cascada" implican un proceso de "Gestión del cambio", porque cuando las personas descubren que los supuestos que se escribieron en las especificaciones ya no son válidos (y esto siempre sucede en grandes proyectos complejos). Desafortunadamente, el proceso de gestión de cambios se construye como una medida de manejo de excepciones y es estúpidamente costoso, lo que significa que el proyecto terminará tarde o de mala calidad.
La idea detrás de las metodologías ágiles es que el cambio es un hecho, sucederá. Por lo tanto, debe realizar la operación estándar de "gestión de cambios" en lugar del manejo de excepciones. Esto no es fácil, pero la gente ha descubierto que si usa muchas buenas prácticas de diseño, puede hacerlo.
Otro problema importante con el diseño de carga frontal es que (la mayoría de las veces) se dedica mucho tiempo a la recopilación de requisitos y al diseño, al desarrollo y al tiempo de prueba. Además, si la prueba es la última fase y se descubre un problema grave, es muy poco probable que se solucione dentro de su marco de tiempo.
Quizás una de las mejores características de un enfoque ágil es que exige una interacción continua (es decir, comunicación real) entre el equipo que desarrolla la solución y el cliente que la necesita. Se hacen las prioridades, de modo que los elementos de mayor prioridad se hagan primero (y si se agota el tiempo, se cortan los elementos de baja prioridad). La retroalimentación llega rápidamente.
Volviendo a la cuestión de los cambios dramáticos, realmente necesita usar métodos que mitiguen los cambios. Los buenos principios de SOLID OO pueden desempeñar una buena parte de esto, al igual que la construcción de conjuntos de pruebas automatizadas sólidas para que pueda probar su software de regresión. Debes hacer estas cosas independientemente de tu metodología, pero se vuelven realmente esenciales si estás tratando de ser ágil.
fuente
Bueno, hay algunas ventajas. La primera es que los clientes no leen documentos de especificaciones. Siempre. Waterfall supone que todo el mundo estará de acuerdo con una especificación desde el principio y luego, cuando el software se entregue al cliente un año después de la especificación correspondiente, estarán contentos. En la práctica, los clientes solo descubren todas las cosas que realmente necesitan, realmente no necesitan y realmente necesitan ser algo diferente cuando juegan activamente con el software en sí. Agile obtiene un prototipo funcional en manos de los clientes, por lo que estas desconexiones se detectan de inmediato. Agile no se trata solo de reaccionar a los requisitos cambiantes. También se trata de que esos requisitos cambiantes ocurran temprano, cuando el costo del cambio es bajo, no al final, cuando el costo del cambio es alto.
Una segunda ventaja es que, debido a que Agile tiene entregas altamente visibles a menudo, es menos probable que los proyectos se descarrilen. Con un gran proyecto de Cascada, es muy fácil retrasarse sin siquiera darse cuenta. Waterfall produce marchas de la muerte de varios meses al final del proyecto. Con Agile, debido a que está entregando a los clientes cada dos semanas, todos saben exactamente dónde está el proyecto y los resbalones son atrapados (y ajustados) rápidamente. En mi experiencia, Waterfall produce semanas o meses de 100 horas semanales al final. Ágil significa que es posible que tengas que dedicar un par de días de 12 horas al final del sprint.
Una tercera ventaja es que los proyectos ágiles tienden a ser más motivadores. Es muy difícil para las personas tener algún tipo de sentido de conducción en un proyecto de un año. La fecha límite parece muy lejana y esa falta de inmediatez significa que las personas tienden a postergar, pulir demasiado los diseños y, de lo contrario, simplemente no funcionan de manera muy productiva. Esto es especialmente cierto porque los primeros meses se gastan en cosas que a la gente no le gusta hacer, como documentos de especificaciones. Debido a que Agile siempre tiene plazos muy inmediatos y concretos en un futuro muy cercano, las personas tienden a estar más motivadas. Es mucho más difícil postergar con una fecha límite concreta para un conjunto fijo de tareas que vencen la próxima semana.
fuente
En respuesta a la cita de la pregunta, que es un malentendido fundamental de los oponentes anti-ágiles
"... mientras que la cascada te permite perfeccionar tu arquitectura antes de lanzar algo". es una falacia, déjame arreglarlo por ti; "... mientras que la cascada te permite perfeccionar tu arquitectura para que nunca liberes nada " .
La implicación de que Waterfall de alguna manera proporciona una arquitectura de mayor calidad es fundamentalmente falsa y completamente refutada por evidencia histórica empírica.
Si Facebook se diseñó en forma de cascada con 500 millones de usuarios como un requisito difícil y rápido y no se lanzó hasta que se perfeccionó una arquitectura de soporte que nadie hubiera oído hablar de ella hoy.
Lo mismo con YouTube, Twitter y muchas otras compañías.
Obtuvieron algo que el cliente podía tocar y responder al trabajo y lo lanzaron lo más rápido posible. Recibieron comentarios, lo refinaron y lo lanzaron nuevamente; iterar. Así es como en estos tres ejemplos, responden con solo características que los clientes aceptan y desean y pierden el menor tiempo posible en cosas que los clientes encuentran de poco o ningún valor.
Cualquier persona con años significativos de experiencia en desarrollo de software estará de acuerdo en que no existe una arquitectura perfecta . Solo uno que comienza más lejos de la entropía y la gran bola de barro que otras alternativas. Agile lo reconoce y lo tiene en cuenta. Incorporando al proceso, esto como deuda técnica, rápida re-priorización y refactorización.
fuente
Scrum por sí mismo no prescribe ninguna práctica técnica porque es un marco general.
El desarrollo ágil de software requiere excelencia técnica del equipo. Esto viene de seguir las prácticas técnicas de XP (programación extrema). Por ejemplo, debe aprender sobre refactorización, tdd, todo el equipo, programación de pares, diseño incremental, ci, colaboración, etc.
Hacerlo así hace posible manejar los cambios de forma rápida y segura, lo que también es la razón principal para utilizar el desarrollo ágil en primer lugar.
La única medida de agile que importa es si regularmente (semanalmente, quincenalmente) logra liberar software valioso y funcional para su cliente. ¿Puedes hacer eso? Entonces eres ágil en mi libro.
fuente
Para mí, el principal beneficio de Agile es reducir el riesgo en el proyecto.
Al entregar de forma iterativa y obtener muchos comentarios de su base de usuarios, aumenta la posibilidad de que entregue algo que realmente quiere, y lo hará entregando pragmáticamente las características más importantes para ellos lo antes posible. En teoría, esto se hará con mejores estimaciones y planificación. Obviamente, esto es muy atractivo desde la perspectiva del negocio, mucho más que solo la construcción liberable.
Se podría argumentar que este cambio constante compromete su sistema y reduce la calidad, pero yo diría dos cosas. 1) Este cambio ocurre de todos modos en proyectos de entrega de software más tradicionales: simplemente no se tiene en cuenta y ocurre más adelante en el proyecto, que es cuando, como usted señaló, las cosas son más difíciles y más caras de cambiar. 2) Agile tiene mucho que decir sobre cómo lidiar con este cambio en términos del uso de personas motivadas con experiencia y prácticas como TDD, emparejamiento y revisiones de código. Sin ese cambio de mentalidad hacia la calidad y la mejora continua, acepto que el cambio frecuente que implica ágil podría comenzar a causar problemas.
fuente
Si su arquitectura necesita ser modificada significativamente como resultado de un cambio en los requisitos, tiene una mala arquitectura o unos malos requisitos. Una buena arquitectura le permite diferir tantas decisiones como sea posible y desacoplar componentes de su sistema. Los buenos requisitos (del usuario) no son cosas como "usar una base de datos diferente".
Entonces, operemos bajo el supuesto de que tenemos una buena arquitectura de trabajo. Si ese es el caso, las metodologías de desarrollo ágil pierden este "lavado" con metodologías de diseño de gran tamaño. Después de todo, una característica central de las metodologías de desarrollo ágil son las prácticas como TDD que promueven el acoplamiento suelto en el código, lo que permite que el proyecto continúe a alta velocidad, ya sea cerca del comienzo o muy maduro.
fuente
Después de un proceso ágil, hay una mejor oportunidad de atrapar este requisito antes de que se haya desarrollado demasiado software (y necesita ser cambiado). Cuando pasas varios meses sin trabajar con el cliente y darles algo para mirar, te das cuenta de estos grandes problemas arquitectónicos solo después de "pensar" que estás listo para entregar.
Prefiero tratar de implementar estos cambios en una aplicación que funcione que tenga cobertura de prueba que un montón masivo de código que ni siquiera se compila. Mientras era jefe de soporte técnico, me entregaron un CD de una aplicación que había estado en meses de desarrollo y que ni siquiera se instalaba. Podríamos haber encontrado ese problema la primera semana, pero en su lugar era hora de pedir la cena porque era una noche larga.
fuente