fbpx
Top

Agile, una breve historia de esta metodología 

Agile

Agile, una breve historia de esta metodología 

La mayoría de las organizaciones hoy en día practican alguna forma de desarrollo agile. No siempre fue así. Veamos el por qué de su éxito.

Por Isaac Sacolick | Original de IDGN

 

Todas las organizaciones de tecnología en estos días parecen practicar alguna versión de metodología Agile (Ágil). O al menos creen que sí.  

Ya sea que sea nuevo en el desarrollo de software o que haya comenzado hace décadas, su trabajo actual está al menos influenciado por métodos ágiles.

Pero, ¿qué es Agile y cómo los desarrolladores y las organizaciones incorporan metodologías ágiles?  

Esta es una breve historia del desarrollo ágil y cómo se diferencia de la metodología clásica en cascada.  

Discutiré las diferencias entre los métodos ágiles y en cascada en la práctica, y explicaré por qué ágil se adapta mucho mejor a la forma en que trabajan realmente los desarrolladores y los equipos, especialmente en los entornos de desarrollo actuales.

Antes de Agile: La metodología en cascada

Los veteranos como yo recuerdan cuando la metodología en cascada era el estándar de oro para el desarrollo de software.  

El uso del método de cascada requería una tonelada de documentación por adelantado, antes de que comenzara la codificación.

Por lo general, el proceso comenzaba con un analista comercial que redactaba un documento de requisitos comerciales que capturaba lo que la empresa necesitaba de la aplicación.  

Estos documentos eran extensos y detallados y contenían todo: 

  • Desde la estrategia general… 
  • … hasta las especificaciones funcionales integrales
  • Y los diseños de la interfaz de usuario visual.

Los tecnólogos utilizaron el documento de requisitos comerciales para desarrollar un documento de requisitos técnicos.  

Este documento definió: 

  • La arquitectura de la aplicación
  • Las estructuras de datos
  • Los diseños funcionales orientados a objetos
  • Las interfaces de usuario 
  • Y otros requisitos no funcionales.

Una vez que los documentos de requisitos comerciales y técnicos estuvieran completos, los desarrolladores iniciarían la codificación, luego la integración y, finalmente, las pruebas.  

Todo esto tenía que hacerse antes de que una aplicación se considerara lista para producción.  

Todo el proceso podría llevar fácilmente un par de años.

La metodología de la cascada en la práctica

La documentación utilizada para la metodología en cascada se denominó “la especificación” y se esperaba que los desarrolladores la conocieran tan bien como sus autores.  

Podría ser castigado por no implementar correctamente un detalle clave, por ejemplo, descrito en la página 77 de un documento de 200 páginas.

Las herramientas de desarrollo de software también requerían capacitación especializada, y no había tantas herramientas para elegir.  

Desarrollamos todas las cosas de bajo nivel nosotros mismos, como abrir conexiones de base de datos y subprocesos múltiples para nuestro procesamiento de datos.

Incluso para aplicaciones básicas, los equipos eran grandes y las herramientas de comunicación eran limitadas.  

Nuestras especificaciones técnicas nos alinearon y las aprovechamos como la Biblia. 

Si cambiaba un requisito, sometíamos a los líderes empresariales a un largo proceso de revisión y aprobación.  

Comunicar los cambios en todo el equipo y corregir el código eran procedimientos costosos.

Debido a que el software se desarrolló sobre la base de la arquitectura técnica, los artefactos de nivel inferior se desarrollaron primero y luego los artefactos dependientes. 

Las tareas se asignaban por habilidad, y era común que los ingenieros de bases de datos construyeran tablas y otros artefactos de bases de datos primero.  

Los desarrolladores de aplicaciones codificaron la funcionalidad y la lógica comercial a continuación, y la interfaz de usuario se superpuso en último lugar. 

Pasaron meses antes de que alguien viera la aplicación funcionando.  Para entonces, las partes interesadas generalmente estaban inquietas y, a menudo, más inteligentes sobre lo que realmente querían.  

¡No es de extrañar que implementar cambios fuera tan costoso!

Al final, no todo lo que pusiste frente a los usuarios funcionó como se esperaba.  

A veces, no usarían una función en absoluto. Otras veces, una capacidad tuvo un gran éxito pero requirió reingeniería para respaldar la escalabilidad y el rendimiento.  

En el mundo de las cascadas, solo aprendió estas cosas después de que se implementó el software, luego de un largo ciclo de desarrollo.

Agile

Pros y contras de la metodología en cascada

Inventada en 1970, la metodología en cascada fue revolucionaria porque aportó disciplina al desarrollo de software y aseguró que hubiera una especificación clara a seguir.  

Se basó en el método de fabricación en cascada derivado de las innovaciones de la línea de montaje de Henry Ford en 1913, lo cual proporcionaba certeza sobre cada paso del proceso de producción.  

El método de cascada estaba destinado a garantizar que el producto final coincidiera con lo que se especificó en primer lugar.

Cuando los equipos de software comenzaron a adoptar la metodología en cascada: 

  • Los sistemas informáticos y sus aplicaciones eran típicamente tan complejos como monolíticos
  • Requerían disciplina y resultados claros para entregar  
  • Los requisitos también cambiaron lentamente en comparación con la actualidad, por lo que los esfuerzos a gran escala fueron menos problemáticos.  

De hecho, los sistemas se construyeron asumiendo que no cambiarían sino que serían acorazados perpetuos. 

Los plazos de varios años eran comunes no solo en el desarrollo de software, sino también en la fabricación y otras actividades empresariales.  

Pero la rigidez de la cascada se convirtió en su ruina cuando entramos en la era de Internet, y la velocidad y la flexibilidad eran más apreciadas.

El manifiesto ágil

Agile se lanzó formalmente en 2001, cuando 17 tecnólogos redactaron el Manifiesto Agile.  

Escribieron cuatro principios fundamentales para la gestión ágil de proyectos, con la intención de guiar a los equipos en el desarrollo de un mejor software:

  1. Individuos e interacciones sobre procesos y herramientas
  2. Software de trabajo sobre documentación completa
  3. Colaboración con el cliente sobre la negociación del contrato
  4. Responde al cambio sobre el siguiente plan

El pivote hacia los métodos ágiles

El desarrollo de software comenzó a cambiar cuando los desarrolladores comenzaron a trabajar en aplicaciones de Internet. 

Gran parte del trabajo inicial se realizó en nuevas empresas donde los equipos eran más pequeños, estaban ubicados en el mismo lugar y, a menudo, no tenían antecedentes tradicionales en informática.  

Hubo presiones financieras y competitivas para llevar sitios web, aplicaciones y nuevas capacidades al mercado más rápido.  

Las herramientas y plataformas de desarrollo cambiaron rápidamente en respuesta.

Esto llevó a muchos de los que trabajamos en startups a cuestionar la metodología en cascada y buscar formas de ser más eficientes.  

No podíamos permitirnos hacer toda la documentación detallada por adelantado y necesitábamos un proceso más iterativo y colaborativo. 

Todavía debatimos los cambios en los requisitos, pero estábamos más abiertos a la experimentación y la adaptación de nuestro software en función de los comentarios de los usuarios. 

Nuestras organizaciones estaban menos estructuradas y nuestras aplicaciones eran menos complejas que los sistemas heredados de la empresa, por lo que estábamos más abiertos a crear que a comprar aplicaciones.  

Más importante aún, estábamos tratando de hacer crecer los negocios, por lo que cuando los usuarios nos decían que algo no funcionaba, generalmente los escuchábamos.

Las condiciones para la era de la metodología Agile estaban dadas. Era un cambio que iba a quedarse. Y lo hizo.   

Periodista apasionada por la innovación, la tecnología y la creatividad. Editora de The Standard CIO y Factory Pyme para The HAP GROUP