Acordando la realización de proyectos cerrados con metodologías Ágiles
Sergio Fernández Muiños (@artabricus)
“La parte contratante de la primera parte, será considerada como la parte contratante de la primera parte”
Un día en la ópera (1935)
Como responsable de proyectos software siempre me ha parecido que la parte más complicada del ciclo de vida de un proyecto de este tipo es establecer un contrato entre un cliente que quiere un producto o una solución «digital» y la empresa de desarrollo. En innumerables ocasiones he tenido que alcanzar compromisos sobre entregas, funcionalidades, niveles de rendimiento o de ausencia de errores que “tendrán” que suceder muchos, muchos, MUCHOS meses después de la escritura del contrato. Esto, que ya en si mismo me pone los pelos de punta, se ve empeorado por la reiterada experiencia que esas expectativas (o requerimientos) del proyecto cambiarán múltiples veces a lo largo de la vida del proyecto, dado que “solo” te piden cambiar un par de líneas en un papel… trivial, ¿no?.
Mi conclusión: el producto desarrollado rara vez coincide con lo acordado en el contrato. Esto obliga al equipo a sobreesfuerzos no entendidos y obteniendo a cambio gran insatisfacción por parte de los clientes porque sus expectativas funcionales y temporales no se ven satisfechas.
Sobre procesos complejos
El desarrollo de software es un proceso de carácter puramente humano. Quiero decir, definido e implementado por personas, y con una alta carga de trabajo «intelectual», lo cual le convierte en un proceso donde la incertidumbre es inevitable. Históricamente, esta incertidumbre se ha «cubierto» a través de una protección de los recursos principales. Normalmente esta protección se implementa a través de un «buffer» asociado a estos recursos (equipo, tiempo, budget, scope). Dicho de otra forma, a una sobredimensión de los mismos. Una sobredimensión típicamente mal «digerida» en una relación entre proveedor y cliente.
La adopción de una filosofía ágil para afrontar de forma global este tipo de proyecto cambia drásticamente esta perspectiva. Esto no quiere decir que los contratos desaparezcan, pero si se «transforman» en contratos ágiles que reducen la «importancia» de estos a cambio de un mayor compromiso, transparencia y colaboración con nuestros clientes. El contrato se creará, obviamente, con unos requisitos, un presupuesto y una duración determinada. Además, y en la medida de lo posible, será el equipo de desarrollo el que «pesara» las funcionalidades y requisitos que aparecerán en dicho contrato. De la misma manera que lo harán con las entradas del Backlog durante la ejecución del proyecto. En el caso de que el equipo de desarrollo no esté disponible, o aun no haya sido decidido en este momento del proyecto, la revisión conjunta de esta lista ponderada de requisitos será una de las primeras actividades a realizar.
Money for Nothing and Your Change for Free
Eso si, al comenzar el desarrollo ágil, la implicación del cliente permitirá que estos requisitos iniciales no tendrán que ser inmutables y, de hecho, se espera que no lo sean (y así lo que antes era un problema casi insalvable, ahora se convierte en un beneficio) pudiendo cambiarse por otros de un “peso” equivalente. Siempre de forma transparente y colaborativa. Con todo esto se rompe el paradigma del Triángulo de Hierro abriendo el vértice del Scope. Esta aproximación para la realización de contratos ágiles ya fue descrita por Jeff Sutherland en su famoso «Money for Nothing and Your Change for Free«.
Personalmente, y una vez aclarado el planteamiento de los requisitos definidos dentro del contrato, soy muy partidario de incorporar un «buffer» de seguridad al scope inicialmente especificado en el contrato. Si bien, esto que, históricamente ha constituido un problema, con la aproximación ágil no lo es. El cliente se garantiza con esta aproximación que el producto obtenido al final del proceso será aquel con el mayor valor de negocio posible (según sus propios criterios). Debido a esto, el «buffer» negociado siempre será aprovechado en aras de proporcionar el máximo valor posible del producto. En el «peor» de los casos, este «buffer» no se utilizará por lo que no supondrá un coste para el cliente.
Contrato Ágil vs Time and Materials
Por otro lado, algunos clientes (¡y muchos jefes/responsables de proyecto!) tienden a comúnmente a confundir este cambio de paradigma con trabajar en unas bases de “time and materials”. Nada más alejado de la realidad. Los compromisos con nuestros clientes son constantes, antes y después de cada iteración, y mucho más férreos al ser más realistas y tener la implicación de todas las partes. Se podría ver como la sustitución de un contrato a largo plazo, por múltiples contratos reflejados, por un lado, en el BackLog y por otro lado en las reuniones de Sprint, tanto para su planificación como para su revisión.
Conclusión
A modo de resumen, se podría decir que el paradigma de los contratos ágiles se sustenta en cambios como los siguientes:
Requisitos fijos -> Requisitos iniciales intercambiables.
Hitos -> Incremento constante de valor.
Análisis de riesgos -> Evaluación continua del producto. ¡¡Kaizen!!
Contrato -> Colaboración y transparencia.
Estos cambios en el paradigma nos están llevando poco a poco a proveedores y clientes a alcanzar una manera diferente de definir y afrontar los proyectos. Usando contratos ágiles y anteponiendo la colaboración a los contratos y poniendo el foco en el valor de los resultados.
Referencias
[Sutherland, Jeff (2008)] Money for Nothing and Your Change for Free. Blog.