Agile ha reemplazado completamente la metodología Waterfall

Agile ha reemplazado completamente la metodología Waterfall
Índice
  1. ¿El auge del SDLC ágil reemplazó por completo el desarrollo en cascada?
  2. El término cascada a menudo se relaciona más con un argumento de hombre de paja
  3. Generalmente atribuido a un artículo de Winston W Royce en el que mostró a propósito una metodología defectuosa
  4. Cascada a menudo es un término utilizado para cualquier metodología de desarrollo de software lineal
  5. La principal diferencia entre Waterfall y Agile es que Agile es iterativo
  6. En la actualidad, el desarrollo iterativo parece adaptarse mejor a las necesidades de muchos clientes
  7. El ritmo de cambio del mundo no se está desacelerando, entonces, ¿por qué nuestros ciclos de vida de desarrollo?
  8. Una muestra de lo que vendrá

¿El auge del SDLC ágil reemplazó por completo el desarrollo en cascada?

¿El desarrollo de código de TI tradicional ha visto su último día con el establecimiento de Agile como una mejor manera de hacer negocios? Es muy posible que sea el caso, ya que las métricas de los proyectos están demostrando ser del lado del rendimiento. Y los gerentes de proyecto están prestando atención.

El término cascada a menudo se relaciona más con un argumento de hombre de paja

Durante años, el desarrollo temprano de software ha consistido en seguir una secuencia. Se completa un paso y luego el equipo pasa al siguiente, y al siguiente, y al siguiente. Cada fase fue un hito, así como una métrica medible que podría usarse para mostrar el éxito. No es de extrañar que el logro de la secuencia a menudo pareciera ser más importante que la creación del software en sí, una crítica común. Esto creó un mito del hombre de paja sobre el método Waterfall, un miedo que no era real pero que tomó una mente propia. No es de extrañar que los defensores de Agile salten de todo corazón sobre los errores de Waterfall, diciendo que es el peor método de desarrollo que existe, al menos desde que se crearon las hamburguesas de la gasolinera AMPM (en realidad, no son comida real en absoluto).

Generalmente atribuido a un artículo de Winston W Royce en el que mostró a propósito una metodología defectuosa

La metodología secuencial anterior para el desarrollo fue establecida por Winston W. Royce cuando expuso los principios del método de la cascada. Sin embargo, también señaló que los riesgos deben gestionarse y mitigarse con cinco pasos que brindan una ayuda crítica en el asunto. Éstas eran:

  • El diseño del programa es lo primero.
  • Documentar el diseño.
  • Haz todo dos veces para asegurarte de que esté bien.
  • Planificar, controlar y monitorear las pruebas.
  • Involucrar al cliente.

En algún punto del camino, uno u otro de estos controles de riesgo se sigue perdiendo, lo que a menudo conduce al fracaso.

Cascada a menudo es un término utilizado para cualquier metodología de desarrollo de software lineal

El método de la cascada es una práctica de alcanzar un escalón y caer en el siguiente. Los codificadores de software encontraron una gran estructura en él al crear primero una idea y luego pasar a un marco conceptual para una aplicación. Luego se escribiría el código y se probaría. Un enfoque profesional aplicaría algunas pruebas de calidad para asegurarse de que la aplicación funcione bajo presión, y luego se liberaría para su uso completo. El enfoque proporcionó un camino predecible y formulado al que se volvió bastante fácil adjuntar palabras de moda. Con el tiempo, este camino pasó a ser más conocido como Concepción, Iniciación, Análisis, Diseño, Construcción, Pruebas, Producción y Mantenimiento.

Sin embargo, una limitación clave de los enfoques en cascada era su naturaleza secuencial. Un equipo no participaba en una fase posterior hasta que se completaba la fase actual. Y en un entorno profesional, esa finalización necesitaba ser confirmada o verificada. Como era de esperar, el método de cascada tenía un gran potencial para convertirse en una base muy rígida para la burocracia, algo que los desarrolladores de software creativo realmente no pueden soportar. Además, las partes interesadas rara vez vieron el software hasta que se completó, lo que resultó en una solución que puede no haber alcanzado el resultado esperado. Los cambios en el camino fueron engorrosos de manejar y crearon conflictos entre los equipos de desarrollo y aquellos que esperaban la solución perfecta. Por lo tanto, el terreno ya estaba preparado para que entrara en juego un enfoque diferente mucho antes de que Agile comenzara a convertirse en una metodología de reemplazo bien adoptada.

Puedes leer:  Ejemplos y Tipos de Clases y Objetos en Java: Guía Completa

La principal diferencia entre Waterfall y Agile es que Agile es iterativo

Agile ofrece un enfoque de desarrollo extremadamente flexible y menos rígido, que a menudo es la razón por la que se prefiere mucho más que el método de cascada. La colaboración es el nombre del juego, y las sinergias multifuncionales, así como el desarrollo del pensamiento grupal, son algo común. La cultura del silo que era tan común en el enfoque en cascada se rompe y se reemplaza por una creatividad rápida y flexible, a menudo liberando pasos temprano y luego refinándolos una y otra vez para perfeccionarlos. Una de las mejores analogías del método Agile es cómo se maneja la forja de espadas; una espada se calienta, se martilla, se enfría y se vuelve a calentar. El proceso repetido endurece el acero, haciéndolo extremadamente fuerte con cada ciclo o iteración. Bien hecho, el producto final es una espada que corta otro metal como un cuchillo a través de la mantequilla. Obviamente, el desarrollo de software no es forjar espadas,

El diseño iterativo acepta que un proyecto y sus especificaciones pueden cambiar durante la producción desde el esquema inicial

Agile tiene sus inconvenientes; el enfoque generalmente no incluye la cantidad de pruebas finales y controles de calidad necesarios para garantizar que una aplicación no sea vulnerable con cada versión pequeña. Las pruebas son continuas e iterativas a medida que se desarrollan nuevas funciones y las aplicaciones mejoran con el tiempo. Como era de esperar, muchas aplicaciones y herramientas están descubriendo que son abiertas y fáciles de piratear porque los errores en el código simplemente no se han descubierto ni solucionado en el lanzamiento más rápido al mercado. Este tipo de pensamiento está impulsado por una perspectiva de "resultados importan", ya que los problemas solo ocurren una pequeña parte del tiempo, y la mayor parte de la producción será exitosa, un poco al revés de la Regla de Paretto 80/20. En algunos casos, el desarrollo es Ni siquiera me preocupé por el asunto, dejando la protección de datos en una iteración posterior en lugar de la inicial.

El desarrollo iterativo tiene múltiples puntos de retroalimentación de las partes interesadas a lo largo de la vida del proyecto

Claramente, Agile ofrece a quienes trabajan en un proyecto un punto de éxito mucho más rápido que Waterfall, por lo que probablemente sea un enfoque de desarrollo mucho más atractivo. En lugar de esperar largos meses y años para llegar a una versión y, después de pruebas intensivas y controles de calidad, descubrir que no funciona bien (¿suena familiar como versiones antiguas de Microsoft?), Agile va al grano rápidamente. Y si el proyecto no funciona bien, pasa rápidamente al siguiente ciclo para realizar más reparaciones y otro viaje rápido a una segunda versión, y así sucesivamente. Este enfoque también tiene otros beneficios secundarios.

Por otro lado, Agile tiene una tendencia en grandes proyectos a seguir agregando sprints. Es un desafío cumplir con un cronograma acordado. Dado que el desarrollo ocurre en iteraciones, resolviendo problemas inmediatos con un ciclo para luego encontrar más en el ciclo siguiente, el proyecto puede quedar atrapado fácilmente en un síndrome de "disco rayado" donde el trabajo parece continuar y nunca llega a un punto de finalización. Esto se puede abordar involucrando QA/Pruebas en cada iteración y decidiendo firmemente qué criterios se utilizan para la aceptación. Debe mencionarse que ha habido más de una pelea verbal en la sala de conferencias sobre cuándo se completó exactamente un proyecto versus un contratista que intenta extender un ciclo más. Agile ha demostrado ser la mejor herramienta de un consultor y el mayor desafío de un ejecutivo de TI que trata de descubrir qué significa realmente "hecho".

Cada iteración es una oportunidad para probar y modificar el producto existente, ¡simultáneamente!

Para el lado de la tecnología de aplicaciones móviles (y web) de rápido movimiento, Agile funciona extremadamente bien. Las aplicaciones son herramientas inconstantes, que ganan y pierden popularidad muy rápidamente. Como resultado, un enfoque en cascada es simplemente demasiado lento para una economía y un mercado digital que espera ver cambios, actualizaciones y nuevas opciones literalmente cada tres a seis meses como máximo. Debido a que el cronograma de codificación y prueba se compacta bajo un enfoque Agile, el desarrollo lanza un producto mucho más rápido y tiene mucho menos tiempo de espera para ver cómo funciona el producto en el mundo real. Eso es importante porque tan pronto como uno pierde su audiencia en el mercado móvil, cae al fondo del barril para volver a subir.

Puedes leer:  Testing de Software: Explorando los Niveles de Sistemas

En la actualidad, el desarrollo iterativo parece adaptarse mejor a las necesidades de muchos clientes

Agile también hace que los contadores y la gente de presupuesto sean mucho más felices. En lugar de lidiar con proyectos largos y drenajes de costos abiertos como en Waterfall, Agile es táctil: se puede ver de principio a fin en un período de tiempo razonable y, como resultado, se calcula el costo con mucha más precisión.

Agile también puede entretener a los tipos de jugadores que quieren rendimientos y resultados rápidos. A diferencia de Waterfall, que según la teoría de TI tradicional, uno debe tener un plan y un alcance muy claros para ir del punto A al punto B, Agile es un loco viaje en tren de experimentación y unión de ideas en un concepto tangible y luego en un producto y luego un lanzamiento para ver si se pega en el objetivo original. No sorprende que Agile permita lanzamientos de software muy rápidos, lo que hace que los clientes estén mucho más contentos con un producto real sobre la mesa, aunque sigue necesitando trabajo muchas veces, pero está ahí y es tangible.

El ritmo de cambio del mundo no se está desacelerando, entonces, ¿por qué nuestros ciclos de vida de desarrollo?

Agile simplemente se adapta mejor a la dinámica de lo que espera el mercado en la entrega de productos. Uno esperaría que los enfoques de desarrollo de TI tradicional y Waterfall aún proporcionen una mejor administración y entrega a largo plazo en proyectos de grandes empresas de alto perfil y con una tasa de falla de proyecto más baja. Pero la verdad es que Agile es aún mejor incluso en proyectos grandes, al menos en términos de aquellos que se completan. El diablo está en los números.

En los primeros informes de la industria de 2012 a 2014, Agile se promocionó como un enfoque innovador que funcionó muy bien y tuvo resultados de proyectos notablemente mejores.

Acelere otros tres años hasta 2015 y comenzó a surgir el patrón que confirma que Agile era el mejor camino a seguir en proyectos de TI pequeños, medianos y grandes en términos de resultados.

Sin embargo, en general, la industria todavía se siente avergonzada en términos de aquellos proyectos que van de principio a fin y se mantienen en el buen camino. Entonces, cuando decimos que Agile funciona mejor que Waterfall, eso se refiere a tener éxito en el 39 por ciento de los proyectos en comparación con Waterfall, con solo el 11 por ciento de los proyectos completados a tiempo. Entonces, visto de otra manera, Agile produce una victoria a tiempo en 4 de 10 proyectos, mientras que Waterfall solo funciona bien en 1 de cada 10 proyectos. En cualquier caso, la tasa de éxito es desafiante y la industria continuará intentando hacer mejoras. Con Agile produciendo cuatro veces la tasa de éxito que, tiene sentido cambiar.

Una muestra de lo que vendrá

En particular, Agile funciona mucho mejor en proyectos de menor escala que en iniciativas de grandes empresas. Eso ha creado un impulso para dividir los proyectos en partes digeribles para un mayor rendimiento y finalización de éxito frente a los grandes desafíos de megalitos. Entonces, en algunos aspectos, se está produciendo un cambio en la forma en que se planifican los proyectos debido a Agile, que a su vez está creando muchos proyectos pequeños que funcionan mejor bajo Agile, lo que a su vez promueve un mayor uso de Agile. Es una profecía autocumplida en acción. Waterfall no tiene posibilidades de permanecer en estas condiciones.


Si quieres conocer otros artículos parecidos a Agile ha reemplazado completamente la metodología Waterfall puedes visitar la categoría Desarrollo.

Entradas Relacionadas 👇👇

Go up