Contratación y Scrum

El tema de las contrataciones en proyectos de software, siempre ha sido polémico. De forma tradicional, en un contrato se acuerdan un grupo de requisitos del cliente, que deben ser desarrollados en un tiempo X y por un valor Y. Estas condiciones generalmente conllevan a largas negociaciones posteriores por alcance, cuando el cliente quiere añadir alguna funcionalidad, o a que no se cumplan los plazos, addendums al contrato especificando valores adicionales a los pactados por la incorporación de nuevos requisitos… en fin, podríamos decir que la contratación puede convertirse en una vulnerabilidad para empresas desarrolladoras de software.

Si hablamos de una empresa que desea o ha adoptado un marco de trabajo ágil, este siempre será uno de los primeros puntos dentro de sus preocupaciones. ¿Cuánto voy a tardar? ¿Cuántos requisitos pactamos? ¿Con cuánto presupuesto contamos? ¿Cómo voy a añadir cambios que están fuera de lo pactado? Definitivamente, una organización que adopte ágil, deberá revisar y modificar sus procesos, en especial, los de contratación.

En este punto existen varias opciones, pero todos los clientes querrán saber cuánto les va a costar su producto y cuándo lo van a tener. Es por ello que para un contrato “ágil” se va a necesitar conocer en profundidad los principios y funcionamiento de Scrum y tratar de encontrar un punto medio, que beneficie a ambas partes y permita efectivamente que el contrato responda a los principios ágiles. El Agile Manifiesto valora la colaboración con el cliente por encima del contrato, pero siempre será necesario establecer las reglas con el cliente, de forma que se aumenten las probabilidades de éxito.

Dos de las opciones que sugiero valorar (Bermejo, s.f.) son:

1. Contrato de sprint

Estructura: en realidad, no es un contrato comercial, sino simplemente un acuerdo entre el Product Owner y el equipo para un sprint.

Alcance: el equipo acuerda esforzarse al máximo para entregar el conjunto de características acordadas (alcance) con un estándar de calidad definido al finalizar el sprint. El Product Owner acuerda no cambiar las instrucciones antes de finalizar el sprint.

Riesgo: un proyecto de Scrum puede ser visto como una serie de miniproyectos con parámetros fijos, tiempo (duración del sprint), alcance (backlog del sprint),  calidad ( definition of done), y  gastos (tamaño del equipo × duración del sprint).

2. Money for nothing. Changes for free

Estructura: este contrato funciona con los proyectos de software ágiles porque casi no hay trabajo en progreso. Al final de cada sprint, la funcionalidad está acabada o no se empezó. El trabajo es del tipo time & materials con un objetivo de coste, a menudo con la intención de que el proyecto no use todo el presupuesto. Una vez se entrega cierta cantidad de funcionalidad, el cliente puede darse cuenta de que ya se ha entregado una cantidad suficiente de valor de negocio y que no se necesita más desarrollo, por lo que puede cancelar el proyecto. Hay un gasto de cancelación que es igual a la ganancia restante que faltaba.

Alcance: puede cambiar. Las características planificadas sin implementar se pueden reemplazar por otras historias del mismo tamaño. Las características adicionales cuestan más.

Riesgo: compartido. Ambas partes están interesadas en completar antes el proyecto. El cliente obtiene costes inferiores y el proveedor, un margen más amplio.

También les recomiendo leer el siguiente material, donde podrán encontrar más detalles sobre los contratos ágiles.

Saludos y hasta la próxima.

Referencias.

Bermejo, M. (s.f.) Contratos ágiles. FUOC. Fundación para la Universitat Oberta de Catalunya. Recuperado de: https://www.exabyteinformatica.com/uoc/Audiovisual/Produccion_multimedia/Produccion_multimedia_(Modulo_5).pdf