Por qué RUP también puede ágil…

Agilidad es una de las tendencias en boga durante los últimos años dentro de los entornos de desarrollo de software como una  propuesta innovadora ante el eterno problema para generar valor a los usuarios, poder hacer ajustes ante ambientes cambiantes y controlar riesgos en los proyectos; muchos son los equipos que se han visto beneficiados ante el hecho de aplicar practicas agiles creando división entre las corrientes tradicionales y los agilistas, para lo cual marcos de trabajo como RUP han sido duramente atacados por promover procesos excesivamente pesados y burocráticos que se convierten más en obstáculos que medios para mejorar el trabajo.

Haciendo reflexión sobre las características de SCRUM así como las de RUP lleguo a la conclusión de que el problema no se encuentra en los métodos si no en las personas, desde el momento en que nos casamos con llevar un conjunto de buenas prácticas como técnicas que se tienen que llevar al pie de la letra y no como lo que son, “buenas prácticas”, nos convertimos en esclavos de las recomendaciones que alguien más definió o estableció y no como técnicas que pueden ser usadas en un contexto o en otro.

RUP se encuentra fundamentado en 6 principios clave los cuales son:

• Adapt the process
• Balance stakeholders priorities
• Collaborate across teams
• Demonstrate value iteratively
• Elevate the level of abstraction
• Focus continuously on quality

Si verificamos el primer principio: “Adapt the process – Adaptar el proceso”, se puede entender cómo adaptar el proceso al contexto del proyecto,  adaptarlo a las necesidades del cliente, ajustarlo a la naturaleza de los requerimientos y del negocio e identificar que sí puede ser aplicado y que no, tanto en roles, artefactos, herramientas así como en “buenas practicas, en resumen si el proyecto tiene un cierto nivel de incertidumbre y los requerimientos pueden ser cambiantes, ajustar RUP para que pueda ser ágil y efectivo ante este entorno podría ser adecuado, sin romper con la esencia del método.

Balance stakeholders priorities (Balancear las competencias entre los involucrados) y Collaborate across teams (Colaboración entre equipos), que se pueden interpretar o ligar al manifiesto ágil cuando se refiere a “Individuos e interacciones, por encima de los procesos y las herramientas” así como “Colaboración con el cliente por encima de negociación contractual”, balancear las necesidades, colaborar, comunicar, crear sinergias entre los individuos, etcétera; todo aquello que permita tener un adecuado flujo de interacción y comunicación dentro del proyecto.

Demonstrate value iteratively (Demostrar valor iterativamente), que al confrontarlo nuevamente con el manifiesto ágil encontramos  “Software que funciona, por encima de la documentación exhaustiva” entendiendo que valor al cliente en la filosofía ágil es el software funcional o productivo; así que en ambos lados de la moneda para los usuarios finales todo aquello que genere valor debe ser entregado al final de cada iteración o al final de cada sprint: software funcional, software funcional + documentación, documentación para cumplimiento contractual, etc.

En los 12 principios agiles tenemos el onceavo principio especificando lo siguiente: “La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial” y al contraponerlo con el quinto principio de RUP Elevate level of abstraction (Elevar el nivel de abstracción) se puede entender a este principio como enfocarse en lo esencial, lo más básico, lo más simple del problema, el proyecto o de los requerimientos; lo más mínimo funcional que satisfaga las necesidades de los usuarios finales; los detalles no prioritarios que refuercen al producto pueden venir después.

Focus continuously on quality (Enfoque continuo en la calidad) tomando en consideración que la agilidad y SCRUM proponen que el software entregado debe estar libre de errores para lo cual continuamente tendremos que estar haciendo entregas de calidad y el código debe estar en constante mantenimiento.

Creo fielmente que ambos marcos de trabajo tienen los mismos cimientos, pero al final el propósito de este pequeño recorrido comparativo es dar un poco de luz en donde considero convergen, se unen o fracasan las “buenas practicas” y es en el momento de querer implementarlas como un paso a paso y no como procesos adaptativos y ajustables en el momento de omitir los valores y principios que dan origen a una técnica u otra.  Considero que RUP se convirtió en excesivamente pesado desde el momento que fue llevado a la práctica como una maquinaria cerrada más que como una caja de herramientas adaptativa que se usa según la naturaleza de los problemas.