Contratar Proyectos Ágiles

Uno de los cuatro valores del Manifiesto Ágil dice que los equipos ágiles prefieren la colaboración con el cliente antes que la negociación contractual. Los principios y valores del desarrollo de software ágil están motivados por un supuesto básico:

“En el software, el cliente no sabe lo que quiere, pero sí sabe lo que no quiere”.

En otras palabras: en la mayoría de los proyectos software es imposible determinar al principio más de un 20% de los requisitos, por lo que hay que ir derivándolos a medida que avanza el proyecto. Cuando los interesados reciben una demostración de parte del trabajo, saben inmediatamente si es lo que querían o no, y aprovechan para reformular los requisitos o añadir otros nuevos.

Este paradigma, contrario al enfoque predictivo, está muy bien para enfocar el proyecto conforme al valor. El gran inconveniente, sin embargo, lo encontramos cuando el desarrollo no debe hacerse con recursos propios, sino que hay que externalizarlo, lo cual implica que habrá que firmar un contrato con un proveedor. La pregunta ahora es ¿qué tipo de contrato debería firmarse en un proyecto ágil?

Sabemos que la respuesta no es un contrato de precio fijo (también conocido como precio cerrado, suma total, etc.). ¿Qué proveedor va a comprometerse a un precio fijo sin conocer el alcance?

Igualmente podemos deducir que tampoco serán idóneos los contratos por tiempo y materiales, o los contratos de coste reembolsable. ¿Qué cliente va a asumir el riesgo del sobrecoste si finalmente el proyecto acaba costando un 50% más, o un 100% más (el doble) de lo presupuestado?

Tratemos de ver esto con un ejemplo. Supongamos que un cliente tiene que contratar un proyecto que debería terminar en 20 semanas. Si bien el alcance no está determinado porque debe deducirse colaborando con ciertos interesados a medida que el proyecto avance, sí se sabe que habrá cuatro puestas en producción (4 releases) al final de las semanas 5, 10, 15 y 20, cada una de ellas con valor para el negocio porque ciertos usuarios irán cambiando su forma de hacer las cosas. Se sabe que el equipo externo estaría bien dimensionado con 4 personas a tiempo completo, obteniendo un esfuerzo total estimado de 3200 horas-persona (=4x40x20). Supongamos que la tarifa media de mercado para estos profesionales es 50€/h.

Con estos datos, el cliente ya podría estimar un presupuesto de 160k€ (3200 horas-persona x 50€/h). Si se proyecta en el tiempo, al final de cada release se habrían pagado 40, 80, 120 y 160k€, respectivamente. Sin embargo, como se ha comentado anteriormente, ningún proveedor va a firmar un contrato a un precio fijo si no se puede predeterminar el alcance. Por otra parte, el cliente no firmará un contrato por tiempo y materiales a 50€ la hora porque a lo mejor acaban siendo 5.000 ó hasta 10.000 horas, quién sabe.

El enfoque aconsejable aquí sería descomponer el proyecto en módulos, o grandes funcionalidades, o épicas, que es lo único que puede saberse en este momento, y tratar de acordar desempeño y precio para cada una de ellas.

El Product Owner podría profundizar (con ayuda de los interesados del negocio) descomponiendo las épicas en historias de usuario. Estas historias podrán cambiar, por supuesto, si no no sería un proyecto ágil, el objetivo ahora es llegar hasta una pila de producto priorizada para las 4 releases. Es decir, podríamos tener 4 release backlogs con sus respectivas user stories, más detalladas en la primera release que en la última, como es lógico.

Entonces ya podría estimarse el tamaño del proyecto (con ayuda de los interesados técnicos) en puntos de historia (en términos relativos, no absolutos). Supongamos que el tamaño inicial del proyecto es de 1000 puntos de historia distribuidos a lo largo de las 4 releases en 400, 300, 200 y 100 puntos de historia, respectivamente.

Con esta información, el cliente podría proponer a los posibles proveedores varios modelos de acuerdos contractuales beneficiosos para ambas partes. Me parecen muy interesantes los modelos expuestos por Alistair Cockburn y Jeff Sutherland.

Cockburn propone, entre otros, un modelo de contrato por tiempo y materiales combinando el precio por hora y el precio por punto de historia. Veamos cómo sería aplicado al ejemplo:

• Se acuerda una tarifa horaria media bastante inferior a la tarifa de mercado, digamos por ejemplo 15€/h en lugar de 50€/h.
• Se acuerda una tarifa por punto de historia para cubrir el presupuesto total de 160k€. Es decir, 112€/punto de historia = (160000-15×3200)/1000.
• El cliente mitiga su riesgo de desviación por sobrecostes: Si se entregan finalmente 1000 puntos de historia, pero tardando por ejemplo 24 semanas en lugar de 20, el proyecto costaría 169.600€ (=15x160x24+112×1000). Comparándolo con un contrato por tiempo y materiales, que habría costado 192.000€ (=50x160x24), vemos que el sobrecoste se ha reducido desde un 20% a un 6%.
• El proveedor mitiga el riesgo por cambios de alcance y tiene una motivación por terminar antes: Si finalmente termina 1000 puntos de historia en 16 semanas, en lugar de 20, el proyecto costaría 150.400€ (=15x160x16+112×1000) con lo que su tarifa media sube de 50€/h hasta 58,75€/h (un 18% más).

El modelo de contrato que propone el coautor de Scrum Jeff Sutherland, denominado Money for Nothing and Changes for Free (como la canción de Dire Straits) se basa en estimular que el proveedor termine antes y el cliente se comporte de forma ágil:

• La cláusula Money for Nothing se aplica cuando el cliente quiere terminar anticipadamente el contrato. Esto tiene mucho sentido en los proyectos ágiles porque llega un momento en que el incremento de valor que aportarían los siguientes sprints ya no justifican su coste. El cliente puede aplicar esta cláusula si ha cumplido con su papel en el proyecto ágil (ha resuelto los impedimentos con prontitud, acudido a las reuniones de acicalado, planificación del sprint, ayudado a estimar y priorizar, ha dado feedback en las demos, etc.). El cliente termina el proyecto y el proveedor recibe un porcentaje preacordado del importe del trabajo pendiente. Aplicado a nuestro ejemplo, digamos que el cliente quiere terminar el proyecto después de la tercera release (15 semanas en lugar de 20). Si el porcentaje pactado es del 20%, pagaría 128k€ (=15x160x50+5x160x50x20%) en lugar de 160k€. El proveedor libera sus recursos 5 semanas antes y su tarifa sube de 50€ a 53,3€ (un 7% más).

• La cláusula Change For Free se aplica cuando el cliente quiere cambiar una orden de trabajo por otra equivalente: puede hacerlo sin coste si, como en el caso anterior, ha ejercido correctamente su función de interesado colaborador en el proyecto ágil. En caso contrario debe pagar por la nueva orden de trabajo como cualquier cambio de alcance. Imaginemos en nuestro ejemplo que nos encontramos a mitad de la segunda release y hay una épica de 25 puntos historia en la última release en la que el cliente ya no está interesado, pero ha descubierto otra funcionalidad que también mide 25 puntos historia. Si el cliente está comportándose como se espera, entonces puede replanificarse sin coste. En caso contrario (hay constancia de una reclamación del proveedor por incumplimiento de esta cláusula) la funcionalidad que no se quiere se sigue pagando y la nueva funcionalidad se cotiza y aumenta el precio.