Contratos ágiles

Al inicio de las negociaciones, el cliente y el proveedor de servicios deciden el conjunto exhaustivo de requisitos que deben cumplirse para que el proyecto se considere completo. El contrato también se redacta bajo el supuesto de que el software se desarrollará secuencialmente. En este modelo de desarrollo, la visión, las especificaciones, la arquitectura, el desarrollo y las pruebas se completan en un proceso definido. Como resultado, cualquier solicitud de cambio provoca un efecto dominó hasta llegar a la arquitectura, lo que requiere mucho trabajo de reelaboración y genera residuos.

A medida que se desarrolla el producto y el cliente tiene una idea más clara de cómo se utilizará, solicita un cambio. El equipo de desarrollo se ve interrumpido por estas nuevas ideas, lo que le ralentiza y alarga la vida del proyecto. Los costes aumentan y la fecha de entrega se retrasa. Estos cambios de alcance provocan 75% de sobrecostes. Por desgracia, uno de los efectos colaterales de las juntas es que no se incluyen en el producto final funciones necesarias y atractivas.

Scrum se basa en un desarrollo iterativo en el que cada funcionalidad se diseña, construye, prueba y entrega en un Sprint, creando valor de un Sprint al siguiente. Esto es fundamentalmente diferente de un proceso definido y es el concepto básico que permite a los equipos Scrum hacer frente al cambio a medida que se produce.

En lugar de redactar un plan que incluya todo el alcance del proyecto de principio a fin, el proceso Scrum comienza con un Lista de productos pendientesbásicamente una lista de todas las características que podrían incluirse en el producto final. Dado que 80% del valor de un proyecto se encuentra en sólo 20% de las características, el Equipo Scrum empieza a trabajar primero en las características de mayor valor. Al final de cada Sprint: diseñadas, escritas y probadas. En el siguiente Sprint, se trabaja en las siguientes características más valiosas y se completan. Estas funciones se desarrollan unas sobre otras hasta que se ha acumulado suficiente valor para lanzar la primera versión del producto. El Backlog se elabora en estrecha colaboración con el cliente, de modo que tanto el proveedor como el cliente tengan las mismas expectativas.

Cambia gratis: Como no todas las funciones son iguales, si un cliente decide que quiere cambiar las prioridades o añadir nuevas funciones, puede hacerlo. El sitio Product Owner se limitaría a insertar la función solicitada en el Product Backlog, en su caso. Esto no ralentiza el proceso de desarrollo ni interrumpe al equipo, ya que éste se centra en completar el proyecto actual. Sprint Backlogque se fija durante el Sprint. Al cliente no se le cobra por el cambio, siempre y cuando indique qué función de prioridad inferior de valor en puntos equivalente debe eliminarse. Como muestra claramente la diapositiva anterior, 65% de las funciones no se utilizan nunca, por lo que suele ser una elección fácil. El cambio es gratuito porque el alcance del trabajo sigue siendo el mismo.

Dinero a cambio de nada: Como Scrum entrega los proyectos por partes de funcionalidad, una vez que el proveedor ha entregado suficientes funciones de alta prioridad para que el cliente esté satisfecho con el producto, el proceso de desarrollo puede detenerse. Las funciones que estaban en el alcance original del contrato pero que no se han desarrollado (porque el cliente se ha dado cuenta de que no eran necesarias) se dejan sin completar. El dinero sobrante se reparte entre el cliente y el proveedor, es decir, dinero a cambio de nada. El contrato debe especificar qué porcentaje del dinero restante debe ir a cada parte. Puede ser un 50-50, pero dependiendo de la relación y el nivel de confianza entre el proveedor y el cliente, el reparto puede ser de hasta 75-25 en ambos casos.

La participación de los clientes debe incluir:

• Priorización de características por valor de negocio junto con el Product Owner y el Equipo
• Aceptar los presupuestos de todos los trabajos. Scrum mide la producción en Puntos, no horas. El representante del cliente debe comprender este proceso y estar presente durante la estimación.
• Participar en las reuniones de planificación del Sprint debatiendo las características seleccionadas con el equipo. El representante del cliente debe estar presente para aclarar las características al equipo si es necesario.
• Ayudar a redactar las condiciones de satisfacción para cada característica, de modo que el equipo y el cliente tengan una definición compartida de cuándo una característica es Hecho.
• Forme parte de cada Revisión de Sprint y proporcionar información oportuna tanto sobre los trabajos en curso como sobre los ya terminados.

No todos los clientes se sienten cómodos participando tanto en el proceso de desarrollo. Cuanto más dispuesto esté un cliente a participar, mejor será el producto. Sin embargo, si el Product Owner es capaz de recabar regularmente la opinión del cliente y desempeñar un papel activo con el equipo, un cliente menos implicado puede no ralentizar las cosas. De lo que se trata es de garantizar que la visión del producto esté bien representada en el proceso de desarrollo. Por este motivo, un Product Owner de alto rendimiento es extremadamente valioso y nunca se deben asignar recursos insuficientes a esta función. Pagar por un Product Owner de calidad le compensará.

El proveedor se compromete a:

• Comprometerse a entregar la parte del alcance del proyecto que el cliente desea en última instancia. (Esto se basa en la idea de que 80% del valor se entrega por 20% de las características).
• La cláusula Dinero a cambio de nada sólo puede aplicarse si el cliente mantiene la participación con el Equipo Scrum durante el proyecto y el proveedor entrega al final de cada Sprint funcionalidades completadas que satisfagan al cliente.
• En caso de que ambas partes no puedan llegar a un acuerdo mutuo sobre las estimaciones de trabajo o el cliente no mantenga su participación en el Equipo Scrum, el contrato volverá a ser un contrato tradicional de facturación por tiempo y materiales.

Descargar Scrum Inc. Ejemplo de RFP ágil