La literatura acerca de métodos ágiles ilustra la tarea de diseño como un proceso incremental (el diseño del sistema crece y evoluciona periódicamente) y adaptativo (transformar el producto para cumplir las necesidades del usuario aplicando retrabajo y refactoring), el cual está enfocado a obtener un producto funcional al final de cada sprint. Esta aproximación se ha denominado Diseño Emergente.

Por otra parte, la aproximación de Diseño Inicial está orientada a la identificación de las estructuras internas y las relaciones de los componentes del software en suficiente detalle para facilitar la planeación y la construcción.

Tabla 2. Estrategias para “Bienvenido el cambio”

 

BIENVENIDO EL CAMBIO

Uno de los principales retos que afronta la industria del software es la volatilidad de los requerimientos derivada de los cambios en las reglas del negocio, la participación de múltiples usuarios y roles, y la dificultad de obtener especificaciones de requerimientos libres de ambigüedades y completas.

A pesar de ser aproximaciones muy diferentes, tanto el Diseño Emergente como el Diseño Inicial están dirigidos a dar respuesta a la volatilidad de los requerimientos a partir del reconocimiento de que el cambio es inevitable y que lo mejor es estar preparado para él.

Tabla 2. Estrategias para “Bienvenido el cambio”

 

Basado en nuestra experiencia en proyectos de desarrollo de software misionales y empresariales en sectores como banca y seguros, y en las conclusiones presentadas por [B. Meyer 2014], consideramos que la opción de Diseño Emergente es ineficiente y conduce a productos difíciles de mantener dado que:

• Los mismos autores y promotores del Diseño Emergente [M. Cohn 2009], advierten acerca de las dificultades que presenta dicha aproximación:
  • Estimar, planear y el establecer compromisos es una labor realmente difícil
  • Particionar el trabajo a través de los individuos del equipo es muy difícil
  • Es incomodo trabajar sin contar con un diseño
  • El retrabajo es inevitable

• Si bien es cierto que los requerimientos son dinámicos y cambiantes, no se puede generalizar la idea de que los usuarios no saben lo que quieren. Por el contrario, en soluciones misionales y empresariales los involucrados tienen un alcance y unos objetivos claros al arrancar un proyecto de software, a partir de los cuales se pueden determinar las características y atributos de calidad más relevantes del producto a implementar.
• Técnicas tales como herencia, extensibilidad, patrones de diseño, y diseño bajo contrato, entre otras, pueden reducir significativamente el esfuerzo en programación. Estas buenas prácticas solo se pueden aplicar bajo el entendimiento global del producto de software, y deben ser establecidas y definidas antes de implementar código.

Es importante reconocer que en las etapas iniciales del proyecto no es posible contar con la información necesaria para tomar todas las decisiones de diseño, y por lo cual algunas de estas decisiones se deben diferir a iteraciones posteriores. La aproximación de Diseño Inicial no pretende llegar a un diseño “perfecto”, sino llegar a un diseño sólido y lo suficientemente extensible, donde las necesidades y decisiones futuras puedan ser soportadas, sin impactar significativamente el avance construido.

 

CICLO DE VIDA ÁGIL PROPUESTO

Es de aclarar al lector, que el presente documento está centrando en “importancia del Diseño Inicial en proyectos ágiles” y no desconoce los aportes y beneficios de los métodos ágiles. De hecho, nuestra propuesta de adopción de un método ágil se basa en técnicas destacadas de SCRUM como: iteraciones cortas, time-boxing, rol de product owner, entregas de software ejecutables, administración visual, y pruebas por cada pieza de funcionalidad.

Nuestra propuesta consiste en realizar una fase de iniciación seguida de una fase de implementación. Esta última, conformada por múltiples sprints donde se desarrollan las tareas mencionadas en SCRUM tales como: planeación, daily scrums, revisión del sprint, retrospectiva, y refinamiento del product backlog.

Figura 1. Ciclo de Vida Ágil Propuesto

Con respecto a la fase de iniciación propuesta, esta tiene como objetivos:

• Obtener la visión del proyecto que servirá de inspiración y foco para todo el proyecto.
• Estudiar y comprender el problema antes de intentar resolverlo, definiendo una arquitectura de solución antes de embarcarse en los detalles.
• Obtener una declaración clara, consistente, libre de ambigüedad, viable, y trazable de cada uno de los requerimientos de alto nivel, que permita delimitar lo que debe hacer y no hacer el sistema.
• Definir los criterios de aceptación de cada uno de los requerimientos de alto nivel.
• Diseñar una arquitectura que satisfaga a los stakeholders, lo suficientemente flexible y extensiva para soportar cambios.
• Consolidación del equipo (product owner, scrum master, equipo scrum, stakeholders, cuerpo de asesoramiento).

La implementación de este ciclo de vida nos ha permitido mejorar los resultados de los proyectos gracias a la definición clara de interfaces y responsabilidades inter-proyectos, la selección óptima de frameworks y herramientas, y la definición de compromisos más acertados en cuanto fechas y alcance de cada release.

 

BIBLIOGRAFÍA

1. M. Cohn, “Succeeding With Agile”, Addison-Wesley, 2010.
2. M. Cohn, “Agile Design: Intentional yet Emergent”, Blog, 2009 (www.mountaingoatsoftware.com /blog/agile-design-intentional-yet -emergent).
3. B. Meyer, “Agile! The Good, the Hype and the Ugly”, Springer, 2014.