Contratos Ágiles – Segunda parte

En esta segunda parte de la serie veremos contratos y cláusulas específicas pensados para marcos de trabajo ágil. 

Contrato por Sprint

Es un contrato para un mini proyecto que se completa en un único. El alcance se define al comienzo y no hay posibilidad de introducir cambios (ya que serían dentro de un Sprint en curso). Aunque no es habitual verlos en práctica, es adecuado para trabajar en Scrum en micro desarrollos o pequeños evolutivos.

Contrato por Sprints

Cuando existe un grado de madurez suficiente en Agile, tanto en el cliente como en el proveedor, es muy conveniente esta modalidad. Se asigna un equipo a un proyecto. Si no tiene velocidad conocida, se evalúan los primeros 3 Sprint para obtenerla. Luego se establece un precio por equipo por Sprint, asumiendo la cantidad de puntos que pueden completar. También es posible convenir un precio por punto de historia implantado. El alcance es abierto, y el Product Owner puede introducir todos los cambios necesarios. El contrato finaliza cuando se alcanza el valor de negocio deseado. Aunque es mejor ser muy cauteloso en hacer estimaciones tempranas, el coste total del proyecto estará determinado por la velocidad del equipo multiplicado por el número de Sprints previstos hasta la fecha de release (si aplica) multiplicado por el valor del punto de historia.

Coste total = team velocity * cantidad sprints * precio story point

Es fundamental contar con Historias de usuario de referencia, para que proveedor y cliente hablen el mismo lenguaje, así como una Definición de Hecho y de Listo acordada. El Product Owner debe ser efectivo en la redacción de Criterios de aceptación, y la priorización de las historias que realmente aporten valor de negocio. El uso de Spikes para reducir la incertidumbre cuando existen aspectos tecnológicos oscuros o caóticos es una buena práctica. 

Respecto a los incentivos, el proveedor desea entregar los puntos previstos para poder continuar más iteraciones, y el cliente tiene previsibilidad de costes y de la cantidad funcionalidades que obtendrá a lo largo del tiempo. Resulta interesante la continuidad del equipo en otro proyecto similar, ya que se han capitalizado mejoras de velocidad, autonomía, coordinación y proceso. 

Dinero por nada y cambios gratis (Money for nothing, changes for free)

Estas dos cláusulas incentivan tanto al cliente como al proveedor a enfocar la relación desde el punto de vista del valor de uso o de negocio.

Una ventaja evidente de una correcta implantación de Scrum es que regularmente tenemos un producto potencialmente entregable al mercado y la cantidad de trabajo en progreso es exactamente cero. Esto permite al final de cada Sprint cambiar la dirección y reevaluar si el proyecto vale o no el esfuerzo. En el desarrollo tradicional, contrariamente, a medida que transcurre el tiempo, el riesgo es cada vez mayor para el cliente, ya que los costes se han acumulado y no tiene un producto que pueda llevar a sus clientes. Esto se conoce como penalidad por salida anticipada.

El producto se desarrolla a través de varios Sprints, y al alcanzar el valor de negocio deseado cesa su ejecución. Si esto ocurre antes del plazo estimado al comienzo del proyecto, el cliente debe pagar al proveedor un porcentaje del compromiso remanente, que suele coincidir con el beneficio neto del proveedor por el tiempo de servicio no prestado.Por esto se le llama Dinero por nada. 

Ejemplo:

Coste mensual para el cliente 10.000

Coste mensual para el proveedor 8.000

Beneficio mensual del proveedor 2.000

Duración del contrato: 12 meses

Si al llegar el mes 10 el cliente considera que ya tiene suficiente valor de negocio, finaliza el contrato y debe pagar al proveedor 4.000 (2 meses por 2.000 de beneficio mensual). Vemos que el proveedor ha recibido esta suma sin esfuerzo ni riesgo, mientras que el cliente en lugar de pagar 20.000 por los dos meses faltantes desarrollando funcionalidades de poco valor, ha abonado sólo un 20% (4.000 en lugar de 20.000).

A su vez, el Producto Owner puede introducir cuantos cambios considere, siempre dentro de lo que prescribe Scrum (no dentro de un Sprint en curso). Esta es la cláusula Cambios gratis. Un posible escenario de esto, similar al ejemplo anterior, es que llegado un cierto punto, descubrimos que las historias restantes no aportan valor, y, en lugar de cancelar el proyecto, el Product Owner decide un cambio de dirección (recordemos que al finalizar el Sprint las historias se encuentran “hechas” o “no comenzadas”, y no hay trabajo en progreso). Puede entonces cambiar el alcance o Scope quitando esas historias de la pila de producto y añadiendo unas nuevas.

Se puede considerar como un Time and materials, con un objetivo de costes (with cost target), con la salvedad que hay un incentivo del lado del proveedor para finalizar antes (el ahorro de costes y el dinero gratis) que también opera del lado del cliente (aunque pague un porcentaje, siempre es mejor que pagar el total previsto). 

Este modelo es sumamente apropiado para el marco Scrum, aunque requiere su correcta aplicación. Por ejemplo, si el Product Owner introduce cambios durante un Sprint, o influye en las estimaciones, no es posible continuar y se reconvierte en un Time and materials al uso.

En nuestra próxima entrega discutiremos contratos derivados del Time and Materials y cláusulas especiales para una ejecución ágil de proyectos, y las conclusiones finales.

Pincha este enlace para ver la primera parte

Pincha este enlace para ver la tercera parte

Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional.