Hace ya tiempo que la ingeniería de software ha reconocido y demostrado, en virtud de los resultados obtenidos, el valor del paradigma ágil para la industria. El modelo ágil ha hecho hincapié en aspectos cruciales de los modelos de proceso de antaño, los que determinaron, quizás, su ineficacia e ineficiencia para una dinámica de negocios altamente cambiante como la que hoy nos toca.
La dificultad de reconocer con profundidad, y anticipadamente, las necesidades (requerimientos) a través de modelos proyectivos, la escasa participación/compromiso y dificultad de los interesados en lograr definirlas tempranamente, la dificultosa capacidad de atender el cambio en los requerimientos y el costo inherente causado por su llegada tardía a un proyecto que ya ha avanzado en la construcción del software, la pobre calidad comunicacional de los modelos documentales y el hallazgo tardío de defectos (y su eventual alto costo de recupero) son sólo algunos de los aspectos que el modelo ágil ha buscado resolver.
Es, como todo proceso asociado con la tecnología informática, un modelo en evolución. Pero son innegables el éxito y el nivel de adopción que ha logrado en la industria del software.
Pero fue, y es, un cambio cultural muy grande para las organizaciones salir de la planificación estrictamente predictiva, de la cultura del diseño “congelado” y de la tan pretendida completitud de las especificaciones. A esto se suma salir del enojo por el cambio tardío en los requerimientos, acabar con la práctica del analista que elaboró y entregó su especificación funcional y se desentendió del proyecto, y movilizar a un desarrollador inmerso y parapetado en los laberintos del código. Por último, se debe salir de la –muchas veces- pronunciada cultura delegatoria de interesados y usuarios sobre las áreas de TI para definir los alcances de las soluciones a sus problemas.
Constituir una sociedad desarrolladora basada en la colaboración y la responsabilidad compartida para el logro de una solución, no es tarea fácil.
El paradigma ágil fue pensado para equipos de tamaño reducido (de 5 a 10 integrantes), que evolucionan una o pocas aplicaciones, con alto expertise en ella/s y (normalmente) con un seniority alto, con habilidades comunicacionales muy desarrolladas y con fuerte autonomía de gestión. Fueron concebidos para auto-contener todos los recursos requeridos para desarrollar y evolucionar una aplicación de software.
La difusión y adopción cada vez más extendida del modelo ágil comenzó, con el tiempo, a toparse con una realidad: los proyectos de software pueden ser de gran magnitud, pueden requerir de la participación de múltiples equipos o de un elevado número de recursos por equipo, los equipos pueden residir en locaciones geográficamente distantes (e incluso diferir significativamente husos horarios), la composición de la solución requiere coordinar la integración del producido de todos los equipos y ningún equipo es dueño completo de la solución global ni de su visión arquitectónica.
Es entonces que el modelo auto-gestionado para los equipos ágiles, como fue brevemente descripto más arriba, comenzó a resultar insuficiente para determinados proyectos de envergadura y alta complejidad estructural. Esta cuestión se ha hecho, además, frecuente.
¿Cómo resolver, entonces, esto sin traicionar los principios del paradigma ágil? ¿Es posible extender las prácticas ágiles –sobre todo las de gestión- hacia un modelo que implica múltiple participación de equipos en un proyecto? ¿Hay que aceptar prácticas de control y gobierno de los proyectos que, probablemente, el paradigma ágil original hubiera desestimado por no valiosas?
Para responder esto la industria del software ha visto surgir distintas iniciativas. Las más salientes son:
- SAFe (Scaled Agile Framework Enterprise – scaledagileframework.com – Dean Leffingwell). Es un marco de trabajo que extiende el concepto de agilidad a toda una organización, comprendiendo la gestión del portfolio estratégico hasta los equipos de desarrollo. Está pensada para grandes empresas asimiladas a principios ágiles y LEAN (Mary y Tom Poppendieck – Lean Software Development)
- LeSS (Large Scale Scrum – https://less.works/ – Craig Larman y Bas Vodde). Es un marco metodológico para escalar Scrum a un contexto de desarrollo con múltiples equipos Scrum.
- DAD (Disciplined Agile Delivery – https://www.disciplinedagiledelivery.com/ – Scott Ambler). Es un marco metodológico orientado al aprendizaje, híbrido y ágil, que cubre el ciclo completo de desarrollo y entrega de una solución de software y contempla prácticas para ser aplicado a escala.
- SPS – Nexus (Scaled Professional Scrum- scrum.org). Es un marco metodológico definido por los creadores de Scrum para escalar las prácticas del modelo a múltiples equipos.
Entre los aspectos clave a resolver podemos citar, entre otros:
- Se necesita disponer y comunicar fuertemente una visión de la solución para todos los equipos involucrados. Una visión de arquitectura global compartida es vital para alinear los distintos equipos hacia una solución consistente.
- Se necesita gestionar prioridades entre equipos, interdependencias y secuencias de integración. Surgen nuevos roles para resolver esta temática. Posibles roles estarán dados por las necesidades de guiar acerca de la arquitectura referencial de la solución, de efectuar el manejo de las prioridades del backlog integrado del producto, de gestionar el impacto entre equipos por el surgimiento de cambios de impacto múltiple, de gestionar el roadmap de integración de la solución y el manejo de interdependencias. Es posible la necesidad de constituir equipos con roles especializados a modo de staff global del proyecto, que diriman y asesoren sobre cuestiones de su ámbito de gestión con una visión integral del proyecto.
- Se hace más requerido producir documentación de interfaz entre equipos, documentación de tipo contractual técnica. La comunicación surgida de las prácticas de análisis y diseño JIT (Just In Time), que puede ser habitual en un equipo ágil auto-gestionado, puede resultar insuficiente
- Toma mayor peso la gestión de la configuración de toda la solución para lograr integraciones efectivas y consistentes
Los modelos citados, de una u otra forma, abordan los aspectos citados (y otros varios), e incluso (como SAFe) procuran introducir agilidad estructurada desde el nivel estratégico más alto de la organización para el tratamiento de las iniciativas de negocios afectadas por soluciones informáticas.
En nuestra experiencia, podemos resaltar además la importancia del abordaje de los siguientes temas
- Debe estar asimilado totalmente el paradigma ágil en el conjunto de equipos que deben integrarse a escala. Equipos no ágiles tendrán dificultades en replicar prácticas que desconocen, y además, aplicarlas en un contexto escalado.
- Sin embargo, se debe ser flexible para aceptar prácticas híbridas (no estrictamente ágiles) si agregaran valor a la construcción de la solución.
- Los equipos que no han actuado a escala, aun ágiles, pueden tener dificultades para asumir su salida del “ensilamiento” y actuar en integración colaborativa. Es un tema cultural que debe allanarse.
Por otra parte, todo proyecto debería revisar sus prácticas de escalamiento para ajustarlas a su realidad y contexto. No existe un modelo de escalamiento que se ajuste con eficacia y eficiencia plenas a todos los proyectos. Se debe ser consciente del aporte de valor al proyecto que cada práctica comprende y seleccionarla adecuadamente. Además, las prácticas deben ser revisadas en retrospectiva y, eventualmente, ajustarse.
El paradigma ágil propone la sistemática revisión colaborativa del diseño y la construcción a través de los resultados obtenidos en las sucesivas iteraciones del desarrollo. Sobre el valor aportado por dichos resultados se acciona para profundizar un camino, revisar y mejorar la calidad de producto, y ajustar el proceso si fuera requerido hacerlo. El modelo que se adopte para escalar el proceso de desarrollo no escapa de ser revisado, durante la ejecución del proyecto, con la misma dinámica y rigurosidad.
Desde Liveware se impulsa la gestión ágil de proyectos tanto dentro de la organización como en la de sus clientes.