Un contrato ágil para Scrum

El ejemplo de cláusulas que se muestra a continuación permite formalizar, en una petición de ofertas a proveedores (RFP, Request For Proposals) o en un contrato, cómo deberá de ser la relación entre cliente y proveedor en la ejecución de un proyecto ágil utilizando Scrum.

Aunque el lugar natural de Scrum es el contrato de un equipo por meses (pago por iteración), en muchos casos el cliente prefiere o necesita que tanto el alcance como el coste como la fecha de entrega del proyecto se fijen de antemano (ver Triángulo de Hierro). En estas situaciones, para no perder los beneficios que aporta Scrum respecto a flexibilidad y adaptación y gestión del Retorno de Inversión (ROI), se pueden definir cláusulas específicas de Cambios de requisitos y de Finalización anticipada del contrato. Con esta última en especial tanto el cliente como el proveedor ganan en términos económicos: el cliente puede ahorrar dinero y el proveedor ve premiada su productividad.

 

En el siguiente ejemplo, como parte del proyecto también se deberá elaborar la lista de requisitos priorizada (Product Backlog).


Proceso de control y seguimiento del proyecto
Control y seguimiento del proyecto basado en objetivos
El proyecto se ejecutará en iteraciones incrementales con una demostración del producto al finalizar cada iteración. De esta manera se podrá conocer de forma objetiva el estado del proyecto (si el desarrollo de los requisitos cumple con las expectativas de <<el cliente>>, si la calidad es la esperada o si hay retrasos), con lo que <<el cliente>> podrá tomar decisiones informadas.
Los requisitos se desarrollarán priorizados por el valor aportado a <<el cliente>>, de modo que en las primeras iteraciones se obtendrán los objetivos más importantes del proyecto y se podrán realizar ajustes al respecto con la suficiente antelación.
El control y seguimiento del proyecto se basará en los requisitos completados en cada iteración. Se entenderá un requisito como completado si incluye todos los entregables asociados realizados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo. Por esta razón, cada requisito deberá ser:
  • Independiente del resto de requisitos, en la medida de lo posible.
  • Demostrable, de manera que sea claro cómo comprobar con <<el cliente>> que el requisito está completado y que se cumplen sus expectativas.
  • De un grado de esfuerzo para ser completado semejante al del resto de requisitos, de manera que <<el cliente>> pueda realizar una extrapolación del progreso del proyecto.
 

Iteración 0 – Elaboración de la lista de objetivos/requisitos y planificación

 

Duración: <<1 mes>>.
Objetivos:
  • Planificar y distribuir los objetivos y alcance del proyecto en iteraciones, de manera que los requisitos estén priorizados balanceando el beneficio que aportan a <<el cliente>>, su coste de desarrollo y los riesgos del proyecto. De esta manera, las primeras iteraciones del proyecto podrán acomodar los requisitos más importantes y mitigar los riesgos más altos.
Actividades
  • Identificación de los objetivos del proyecto y de los requisitos iniciales de alto nivel que permiten la consecución de estos objetivos. [2]
  • Priorización de los requisitos en iteraciones y entregas considerando los siguientes criterios:
    • El valor aportado por cada requisito para <<el cliente>>. Deberá ser explícito quien es el actor o usuario beneficiario de cada requisito y qué valor le aporta.
    • El esfuerzo necesario para desarrollar cada uno de los requisitos, de manera que en las primeras iteraciones se desarrollen los requisitos que proporcionen el máximo valor con el mínimo esfuerzo y que puedan encajar en la periodicidad de las iteraciones.
    • Las dependencias inevitables entre requisitos.
    • Minimizar los riesgos del proyecto respecto a desarrollo de los requisitos, disponibilidad y grado de implicación de los actores y beneficiarios implicados, interacción con otros equipos (proyectos en paralelo, compras de material e infraestructura, encargados de entregar el proyecto a los usuarios finales), etc.
    • Maximizar la cohesión del contenido de cada iteración, identificando los puntos de acoplamiento y las dependencias entre los diferentes incrementos de manera que sean mínimos, para poder dar por realmente completados los requisitos desarrollados en cada una de las iteraciones.
  • Calcular la duració de cada uno de los incrementos desarrollados de manera que puedan encajar en la periodicidad de las iteraciones (que deberán ser de la misma duración de <<1 mes>>.

Entregables

 
Iteraciones de desarrollo
Duración: Todas las iteraciones de desarrollo serán <<mensuales>>.
Objetivos:
  • Completar un incremento de producto que sea demostrable a <<el cliente>> al finalizar la iteración, de manera que pueda tomar decisiones informadas y objetivas sobre el estado del proyecto (si el desarrollo de los requisitos cumple con las expectativas de <<el cliente>>, si la calidad es la esperada o si hay retrasos).
Actividades

En el inicio de cada iteración:

  • <<El cliente>> y <<el proveedor>> mantendrán una reunión para consensuar los objetivos y contenido de la iteración, en función de los criterios de priorización indicados anteriormente, así como para dar detalle a los requisitos seleccionados en la medida en que cada una de las dos partes necesiten. De manera general, cada requisito deberá tener asociado un conjunto de condiciones de aceptación para poder considerar que el requisito ha sido completado. [3]

Al finalizar cada iteración:

  • <<El proveedor>> deberá hacer a <<el cliente>> una demostración de los requisitos completados. En esta demostración participaran los interesados que <<el cliente>> designe; entre ellos se podrá encontrar, por ejemplo, a los promotores del proyecto, al responsable funcional, al responsable técnico, a usuarios finales seleccionados, etc. <<El cliente>> hará una aceptación de estos requisitos realizando las comprobaciones de calidad oportunas.
  • <<El cliente>> podrá repriorizar el conjunto de requisitos del proyecto y consensuará con <<el proveedor>> el contenido de las siguientes iteraciones según lo estipulado en la clausula de “Cambio de requisitos” << dado que además de ser fijos el alcance y el tiempo del proyecto también es fijo el su coste para el cliente (y por tanto lo que va a cobrar el proveedor)>>. En particular, los elementos que se repriorizarán serán: requisitos inicialmente identificados del proyecto, modificaciones a estos requisitos, nuevos requisitos que aparezcan durante el proyecto, problemas de calidad detectados, etc.
Entregables
  • El producto desarrollado hasta ese momento, incluyendo todos los entregables asociados completados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo. [4]

 

Cambios de objetivos/requisitos

Para que esta cláusula sea efectiva, <<el cliente>> se compromete a colaborar con <<el proveedor>> en todas las iteraciones y, especialmente, en las reuniones de recogida de requisitos (como, por ejemplo, las reuniones de planificación de iteración) y en las reuniones de demostración.

  • Los cambios en prioridades de la lista de requisitos no implicarán ningún coste adicional a <<el cliente>> siempre que se mantenga el cómputo total de horas del contrato.
  • La adición de nuevos requisitos (tras las demostraciones) no implicará ningún coste adicional a <<el cliente>>, siempre que se retiren del contrato requisitos no iniciados que computen las mismas horas. 
  • No se consideran cambios las subsanaciones por parte de <<el proveedor>> de los defectos de calidad del producto.

 

Finalización anticipada del contrato

  • Con el objetivo de mantener un Retorno de Inversión (ROI) aceptable en cada iteración, <<el cliente>> podrá finalizar el contrato en cualquier momento siempre que abone a <<el proveedor>> un 20% de las horas de proyecto pendientes de realizar. [5]
  • Los requisitos que previamente fueron acordados por las dos partes para ser entregados con anterioridad al momento de la finalización del contrato y que estén sufriendo un retraso de entrega atribuible a <<el proveedor>> quedan excluídos del cómputo de horas pendiente a realizar y deberán ser entregados por <<el proveedor>> sin incurrir en ningún pago adicional por parte de <<el cliente>>.
  • Sea como fuere, <<el proveedor>> se compromete a entregar un 80% de los requisitos del proyecto en la fecha inicial de entrega, cumpliendo los criterios definidos en las condiciones de aceptación para poder considerar que los requisitos han sido completados, siempre que no se produzca alguna desviación por causas que estén fuera de la responsabilidad de <<el proveedor>>. 

contrato-agil-money-for-nothing


 

[1] En el caso de proyectos de desarrollo de software: análisis funcional, diseño técnico, código, pruebas (unitarias, de integración, de rendimiento, funcionales, de regresión, etc.).

[2] En el caso de proyectos de desarrollo de software, para ayudar y guiara conseguir este objetivo, en la iteración 0 ser interesante realizar una primera versión de muy alto nivel de los siguientes modelos:
  • Modelo de actores, procesos y flujo de información.
  • Modelo de Casos de Uso (funcionalidades).
  • Modelo de Dominio (entidades de información y sus relaciones).
  • Modelo de interfase de usuario (GUI), línea de diseño gráfico, hojas de estilo, guía de usabilidad y diseño de interacción, etc.
  • Modelo de arquitectura y de componentes (solución tecnológica), identificando componentes de uso común y reutilizables.
  • Modelo de seguridad (autenticación y autorización para acceder a las funcionalidades).
  • Modelo de gestión de cambios de la configuración.
  • Modelo de control de la calidad.
  • Modelo de gestión del cambio (comunicaciones a beneficiarios, formaciones y soporte).
Esto NO implica realizar un análisis funcional y/o un diseño técnico del proyecto en la iteración 0. Si en el proyecto es necesario realizar un análisis funcional o un diseño técnico, también se elaborará de manera incremental, iteración a iteración: “se entenderá un requisito como completado si incluye todos los entregables asociados realizados (documentación, etc. [1]) e integrados con los entregables de las iteraciones anteriores, de manera que el producto sea susceptible de ser entregado a <<el cliente>> con el mínimo esfuerzo.
También puede ser conveniente realizar las siguientes actividades:
  • Identificar el grado de configuración y parametrización del producto para cubrir las necesidades de <<el cliente>>, así como los mecanismos para conseguirlo.
  • Definir los patrones de diseño, estándares de codificación, guías de uso de los componentes de infraestructura tecnológica a utilizar o cualquier herramienta a utilizar en el desarrollo.
  • Para reducir el riesgo tecnológico lo antes posible, realizar una prueba de concepto de arquitectura, componentes tecnológicos más arriesgados, infraestructura, GUI, etc. en la iteración 0 o en la primera iteración de desarrollo.
[3] En el caso de proyectos de desarrollo de software, para ayudar a reducir la incertidumbre de la iteración, minimizar la dependiencia de <<el cliente>> durante ella y garantizar la usabilidad de la solución, puede ser necesario aprobar previamente a cada iteración el prototipo navegable de la interfase de usuario (GUI) que se desarrollará en esa iteración y acompañarlo de una descripción de comportamiento, redactada como pruebas de aceptación asociadas a cada requisito. Es de especial importancia que este prototipo lo validen tanto el responsable funcional del proyecto en representación de los promotores del proyecto como una muestra representativa de los usuarios finales (con los objetivos de obtener su feedback y de garantizar su productividad de trabajo con la herramienta).
[4] En el caso de proyectos de desarrollo de software, <<el proveedor>> deberá entregar el código fuente, scripts de instalación y la batería automatizada de pruebas (unitarias, de integración, de rendimiento, funcionales, de regresión, etc.), de manera que sea sencillo auditarlas y repetirlas, tanto por <<el cliente>> como por el proveedor que se encargará del mantenimiento evolutivo y correctivo del sistema.
[5] En lugar de perder el 100% del coste de las horas pendientes en requisitos que no le aportan suficiente valor, a <<el cliente>> le resulta más conveniente abonar un 20% de las horas a <<el proveedor>> para así ahorrarse un 80%. Cuanto mejor se haga Scrum, más salen ganando ambas partes: el cliente, por no dedicar más dinero del necesario al proyecto, y el proveedor, por recibir un pago final (y aumentar su margen) sin dedicar ningún recurso.

Para más información:

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s