El paradigma ágil y su aplicación a gran escala

Escribe Osvaldo Galerato* (foto).- Ya no debemos dudar del aporte del paradigma ágil para mejorar la eficacia en general y del proceso de desarrollo en particular; asimismo, ha aportado mucho a la mejora de la satisfacción del cliente/usuario, foco primario de su concepción.

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.

El modelo ágil presenta una dinámica de alto nivel de interacción cotidiana entre los integrantes de un equipo, lo requiere. Exige roles multidisciplinarios/polifuncionales contenidos en el equipo. Los equipos deben ser autogestionados y autosuficientes, se tiene clara consciencia de la responsabilidad compartida por los objetivos del desarrollo. Estos son visibles para todos.

Los equipos ágiles son pequeñas comunidades fuertemente integradas, con alta proximidad en la ejecución de las tareas (lograda por compartir cercanamente el espacio físico para el trabajo o, a veces, con herramientas que salven la barrera de la distancia geográfica). Deben ser sociedades proclives a revisarse a sí mismas y, en general, de alto seniority profesional. Un particular mix entre conocimientos amplios sobre las disciplinas del desarrollo y puntuales capacidades profundas en lo tecnológico y en el conocimiento del dominio del problema. Tienen la particularidad, y la exigencia también, de incluir y comprometer muy fuertemente a usuarios e interesados en su proceso.

Con este perfil han entregado resultados satisfactorios y demostrado su valor.

Claro está que, lograr la conformación de estos equipos productivos ha llevado, y lleva para las organizaciones, un esfuerzo de cambio cultural significativo. Muchos principios del desarrollo tradicional, otrora inamovibles, han debido franquearse: abandono de la obsesión sobre un completo conocimiento inicial y detallado de los requerimientos para construir software, aceptar el cambio de dichos requerimientos una vez avanzado un desarrollo, construir para analizar y evaluar (desechar/refactorizar lo ya construido), cambiar las prácticas basados en su valor para lograr el mejor desarrollo, revisar análisis y diseño de modo compartido y sistemático, diluir las viejas formas adoptadas por los perfiles de analistas y desarrolladores clásicos, construir incremental/iterativamente y otros.

La difusión y adopción cada vez más extendida del modelo ágil ha comenzado, 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 grupo, 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 grupos y ningún equipo es dueño completo de la solución global ni de su visión arquitectónica.

Los equipos ágiles se conformaron para ser eficaces evolucionadores de una o pocas aplicaciones cargo. Su dinámica interna y la asociación con la comunidad de interesados están resueltas y aceitadas.

Pero, ¿Qué pasa en el contexto de no ser el único responsable de lograr e integrar una solución? ¿Cómo seguir teniendo consolidado el trabajo propio y la interdependencia con terceras partes? ¿Cómo seguir aportando a la mejora de la calidad de modo sistemático a partir de la revisión de la dinámica del trabajo y lo construido, cuando ésta excede el ámbito del pequeño equipo propio?

Entre los aspectos clave a resolver podemos citar, entre otros:

· 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.

· 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, gestionar el roadmap de integración de la solución y el manejo de interdependencias.

· 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.

· 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.

· Gestionar la configuración de toda la solución para lograr integraciones efectivas y consistentes.

· 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 (manteniéndose fiel, con esto, a la cultura ágil).

· Trabajar sobre la dinámica actitudinal de los integrantes de los equipos que interactúan con terceros para sostener el nivel de co-responsabilidad por los resultados del proyecto global. Organizaciones con estructuras muy “ensiladas” requieren trabajo adicional de adecuación.

· Actuar en contextos escalados, si es compleja la adopción y maduración de equipos ágiles simples, lo es más si éstos no lo son. Es otro tema de cuidado y preparación.

· Extender a modelos consolidados (Ej: Riesgos, Arquitectura, Datos, Compliance, Integración, etc.) para visibilizar interacciones y guiar la construcción, ya que es posible que muchas de las disciplinas que normalmente, de modo compartido, se gestionan dentro de la dinámica del equipo reducido (iteración a iteración).

Finalmente, esta dinámica de escala debe tratar de respetar el paradigma ágil. No debería sumar burocracia al proceso sino valor (alineamiento con las necesidades de los interesados), mitigación de riesgos y preservar la calidad del desarrollo.

Desde Liveware se impulsa la gestión ágil de proyectos tanto dentro de la organización como en la de sus clientes.

* Osvaldo Galerato, consultor asociado para Liveware