Contenido
- ¿Por qué Agile IT?
- ¿Cómo aborda la metodología ágil los problemas del modelo de cascada?
- ¿Cómo ha impactado Agile la industria de TI?
- Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
- Razones por las que BT cambió a prácticas ágiles
- Mala gestión de los requisitos
- Diseño deficiente de software
- Restricciones de desarrollo
- ¿Qué hizo BT para abordar los problemas anteriores?
- Conclusión
Fuente: Darkovujic / Dreamstime.com
Para llevar:
Para muchos, el modelo en cascada del desarrollo de software ha sido el estándar durante décadas, pero ahora está siendo reemplazado por la metodología Agile, mucho más flexible.
La metodología ágil para el desarrollo de software puede impactar positivamente en la industria de TI. Los resultados de la adopción de la metodología ágil se pueden medir de varias maneras. La respuesta más rápida de las solicitudes de cambio de software, menos errores, la medición cuantitativa del rendimiento del equipo y los cuellos de botella son reflejos de una implementación exitosa de Agile. Para medir con éxito el impacto de Agile, una organización necesita comparar varias métricas relacionadas con el desarrollo pre-Agile y post-Agile. El impacto real de Agile no se puede medir solo por el aumento de los ingresos o por el aumento del número de errores corregidos. Se deben considerar varios parámetros internos para comprender el impacto real. (Para obtener más información sobre el desarrollo ágil, consulte Desarrollo ágil de software 101).
¿Por qué Agile IT?
La industria de TI se ha inclinado hacia prácticas ágiles, principalmente debido a las limitaciones del modelo en cascada del desarrollo de software. En general, se ha observado que las empresas de TI no pueden responder a las cambiantes demandas de los clientes o las situaciones del mercado o reducir los costos con el modelo en cascada del desarrollo de software. Incluso si contrarrestamos esta inclinación abrumadora hacia la metodología ágil y consideramos que parte de la emoción es simplemente exagerada, hay una gran cantidad de comentarios empíricos contra el modelo de cascada.
En pocas palabras, el modelo en cascada es un modelo de desarrollo de software en el que el trabajo se realiza de forma secuencial, una fase tras otra. Hay cinco fases de este modelo: requisitos, diseño, implementación, verificación y mantenimiento. Por lo general, después de completar una fase, es difícil, si no imposible, realizar cambios en una fase anterior. Entonces, la suposición es que los requisitos son bastante fijos. La principal diferencia con el modelo Agile está en el supuesto de que no habrá cambios en los requisitos. Agile asume que las situaciones comerciales cambiarán y también lo harán los requisitos. Por lo tanto, el software se entrega en fragmentos más pequeños sobre ss, mientras que en el modelo en cascada, la primera entrega o lanzamiento se realiza después de mucho tiempo. (Para obtener más información sobre el desarrollo, consulte Cómo Apache Spark ayuda al desarrollo rápido de aplicaciones).
La crítica más notable contra el modelo de cascada ha sido su suposición de que no habrá cambios en los requisitos. La suposición misma es defectuosa y poco realista. Por ejemplo, en 2001, un estudio sobre 1.027 proyectos de TI en el Reino Unido mostró que esta suposición era la razón más importante del fracaso de los proyectos de TI.
En otro ejemplo, Craig Larman, autor del libro "Desarrollo ágil e iterativo: una guía del administrador", ha señalado cómo varios proyectos ejecutados por el Departamento de Defensa (DoD) utilizando el modelo de cascada en los Estados Unidos no han logrado Alcanzar sus objetivos. A lo largo de las décadas de 1980 y 1990, se exigió al Departamento de Defensa que utilizara el modelo en cascada para sus proyectos de desarrollo de software según los estándares publicados en DoD STD 2167. Estadísticas impactantes revelaron que el 75% de estos proyectos de software nunca se utilizaron. Después de este informe, se lanzó un grupo de trabajo bajo el Dr. Frederick Brooks, un conocido experto en ingeniería de software. El grupo de trabajo salió con un informe que comentaba "DoD STD 2167 también necesita una revisión radical para reflejar las mejores prácticas modernas. El desarrollo evolutivo es mejor técnicamente, ahorra tiempo y dinero ".
Los siguientes cuatro supuestos del modelo de cascada habían fallado en escenarios del mundo real:
- Los requisitos dados están razonablemente bien definidos y, por lo tanto, no cambiarán significativamente.
- Incluso si los requisitos cambian durante la fase de desarrollo, serán lo suficientemente pequeños como para adaptarse al ciclo de desarrollo.
- La integración del sistema, que ocurre después de la entrega del software, se realizará según el plan.
- La innovación de software y el esfuerzo requerido para innovar irán de acuerdo con un cronograma planificado y predecible.
¿Cómo aborda la metodología ágil los problemas del modelo de cascada?
La metodología Agile es fundamentalmente diferente del modelo en cascada y eso queda claro a partir de sus supuestos:
- Nadie, ni siquiera el cliente, puede conocer o comprender completamente los requisitos. No hay garantía de que los requisitos no cambien.
- Los cambios de requisitos pueden no ser pequeños y manejables. De hecho, vendrán en varios tamaños y seguirán llegando. Por lo tanto, el software se entregará en pequeños incrementos para realizar un seguimiento de los cambios.
¿Cómo ha impactado Agile la industria de TI?
Agile se está adoptando en muchos lugares, mientras que muchas compañías están haciendo planes para adoptar Agile. Aunque Agile definitivamente ha realizado cambios fundamentales en la industria de TI, los hechos y las cifras aún son un poco difíciles de obtener. Pero el impacto de Agile se puede entender con el estudio de caso de British Telecom (BT) que se presenta a continuación.
Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
No puede mejorar sus habilidades de programación cuando a nadie le importa la calidad del software.
Razones por las que BT cambió a prácticas ágiles
BT comenzó a experimentar una serie de problemas con sus prácticas de desarrollo de software en 2004. BT desarrolló una serie de proyectos de software, tanto simples como complejos. Muchos proyectos de software no pudieron desarrollar resultados de calidad dentro del plazo acordado. BT descubrió que los problemas debían sus raíces al modelo de cascada. Por lo tanto, reforzar el modelo de cascada no iba a ayudar. Las principales causas de los problemas se detallan a continuación:
Mala gestión de los requisitos
- Se dieron demasiados requisitos para cumplirse en un tiempo demasiado limitado.
- Muchos requisitos eran irrelevantes para las necesidades del negocio.
- Casi todos, si no todos los requisitos se les asignó el estado de alta prioridad.
- Los requisitos representaban las necesidades comerciales actuales sin tener en cuenta los escenarios futuros. Eso dejó abierta la posibilidad de futuros cambios de software.
Diseño deficiente de software
- Dada la gran cantidad de requisitos, los diseñadores gastaron demasiado tiempo tratando de averiguar qué significaban los requisitos. Quedaba poco tiempo para el diseño real.
- Los analistas de requisitos se trasladaron a otras tareas, llevándose consigo conocimientos tácitos no escritos.
- Los dos factores anteriores resultaron en un diseño deficiente. Los diseñadores aún tenían que entregar de acuerdo con la línea de tiempo original.
Restricciones de desarrollo
La codificación fue apresurada y de baja calidad debido al diseño defectuoso del software. Los desarrolladores se darían cuenta de que un diseño de software deficiente daría como resultado un código deficiente, pero sin embargo tuvieron que cumplir con el cronograma acordado. Se informarían muchos errores durante la integración porque no se ejecutaron pruebas unitarias y pruebas de regresión.
Para el momento en que se implementa el software, el cliente observa que los requisitos ya han cambiado y también el escenario comercial. El software también tiene muchos problemas. Efectivamente, todo el esfuerzo de desarrollo de software ahora se considera un desperdicio.
¿Qué hizo BT para abordar los problemas anteriores?
BT se dio cuenta de que reforzar el modelo de cascada no era la respuesta a los problemas. Necesitaba un nuevo enfoque. Entonces, decidió implementar el enfoque ágil. Bajo el nuevo enfoque, se decidieron las siguientes cosas:
- En lugar del ciclo de desarrollo de 12 meses, BT ahora entregaría piezas de software viables en un ciclo de 90 días. La idea era enfocarse en uno o dos problemas de negocios y apuntar a entregar una solución de software en 90 días. El comienzo de este ciclo estuvo marcado por una intensa discusión entre los diferentes interesados, de modo que los requisitos se identificaron, analizaron y priorizaron claramente.
- El objetivo era entregar valores comerciales claros y tangibles. El cliente interno estaba bajo presión para proporcionar requisitos claros. Entonces, en lugar de objetivos vagos, las historias de los usuarios se dieron con criterios claros de aceptación.
- El software que se entregaría sería completamente probado y documentado. El software pasaría por frecuentes pruebas de integración para identificar problemas de antemano.
Con el enfoque ágil, BT podría adaptarse a los requisitos cambiantes o situaciones comerciales más fácilmente. Se mejoró la calidad del código y se abordaron los errores básicos de última hora.
Conclusión
Agile, a pesar de todas sus ventajas y el entusiasmo que lo rodea, todavía se encuentra en una etapa en la que su potencial no se aprovecha plenamente. Esto se debe a que muchas organizaciones están personalizando el enfoque hasta el punto de modificar sus principios originales. Como resultado, el modelo de cascada está regresando en algunos casos. Si bien la personalización continuará, es importante mantener los principios básicos de Agiles. Muchas organizaciones afirman ser completamente ágiles, pero todavía tienen un camino por recorrer para convertirse en una empresa verdaderamente ágil.