Es después del fracaso de metodologías como RUP o Métrica v3 en España cuando surge Agile. Diecisiete profesionales de referencia en la industria del software, representantes de eXtreme Programming, Scrum, Crystal, FDD o Pragmatic Programming, deciden reunirse en un complejo turístico de esquí en las montañas de Utah. Están desencantados con los modelos actuales de desarrollo de software y quieren proponer una alternativa a estos procesos. Procesos que ellos denominaban “pesados” y que consideran demasiado orientados hacia la documentación.

De esta reunión, en 2001, en la que participaban ingenieros software, anarco-organizacionales, sólo pudo obtenerse un resultado meramente simbólico, un manifiesto con cuatro valores máximos y 12 principios “ágiles”. Estos valores y principios lograban resumir lo que estos diecisiete representantes habían llegado a acordar. El único “pero” lo puso Martin Fowler, británico, que indicó que la mayoría de americanos no sabrían pronunciar la palabra Agile.

Estos cuatro valores ágiles indican que se valorará más:

  • A los individuos y sus interacciones que a los procesos y las herramientas
  • Al software que funciona frente a la documentación excesiva
  • A la colaboración con el cliente frente a la negociación del contrato
  • A responder ante el cambio antes que seguir un plan

Algunos de sus principios más importantes son:

  • <<Nuestra más alta prioridad es satisfacer al cliente a través de entregas tempranas y continuas de software de valor>>
  • <<Damos la bienvenida a los cambios a los requerimientos, incluso tarde en el desarrollo. Son una ventaja competitiva del cliente>>
  • <<Entregar al cliente software que funciona con frecuencia, desde un par de semanas a un par de meses, con preferencia a la menor escala posible>>
  • <<Los proyectos se construyen alrededor de individuos motivados. Dales el entorno y el apoyo que necesitan y confía en que tendrán el trabajo hecho>>
  • <<La forma más eficiente y efectiva de transmitir información hacia y dentro de un equipo de desarrollo es la conversación cara a cara>>
  • <<La gente de negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto>>
  • <<El software funcionando es la principal medida de progreso>>
  • <<La continua atención a la excelencia técnica y el buen diseño mejora la agilidad>>

Tras estudiar estos valores y principios se puede ver que la agilidad es una forma de pensar y no un proceso o una metodología. Una forma de pensar que no descarta totalmente las metodologías, pero quiere poner de nuevo un equilibrio en ellas indicando, por ejemplo, que:

  • <<Acepta la documentación, pero no cientos de páginas en tomos que rara vez se usan o se actualizan>>
  • <<Planificamos, pero reconocemos los límites de la planificación en entornos cambiantes>>

Cómo se resuelven los problemas del modelo en cascada

Algunos de los principales inconvenientes del modelo en cascada eran la tardía detección de problemas de “traducción” entre la gente de negocio y los desarrolladores. Además, se validaba tarde con el usuario si se habían satisfecho las necesidades que este tenía.

Si se hace caso a los principios ágiles como la entrega frecuente de software que funciona se estará poniendo en producción cada cierto tiempo una versión del producto. Aunque esta versión no esté totalmente terminada, permitirá al usuario usarla y validar pronto si esto que han desarrollado es o no lo que él tenía en mente.

Además, con los departamentos de negocio y de desarrollo trabajando codo con codo se reducirá la posibilidad de mala “traducción” entre lo que el usuario quiso decir y lo que finalmente se entendió. Ideas que más tarde se transmitirán a diseñador y desarrolladores en conversaciones cara a cara y no sólo en documentos de cientos de páginas.

Podían existir también problemas de integración cuando se unían en producción los diferentes componentes y funcionalidades del software. Éstos se detectaban muy tarde en los modelos en cascada. Con esta mejor comunicación, la priorización de la excelencia técnica y la entrega frecuente de software funcionando, no se permitirá que todas las líneas de código lleguen a verse juntas demasiado tarde. Se integrarán en una fase temprana del proyecto, limitando así el problema antes de que sea tan grande que obligue a repetir buena parte de lo que ya se ha hecho.

 

Referencias:

  • BECK K. et al. (2001). Agile Manifesto. Disponible en: http://agilemanifesto.org.html/
  • BECK K. et al. (2001). History: The Agile Manifesto. Disponible en: http://agilemanifesto.org/history.html