Contratos Ágiles

 

Introducción
  • Las especificaciones nunca se entenderán completamente.
  • El usuario no sabrá lo que quiere hasta que el sistema esté en producción
  • Un sistema nunca puede ser totalmente especificado, ni totalmente testado
  • No se puede determinar el costo ni el tiempo que durará un proyecto
Contrato

Cuando un CLIENTE necesita de un SERVICIO que ofrece un PROVEEDOR para completar un PROYECTO se define un CONTRATO, que consiste en un ACUERDO entre ambas partes en el cual debe indicarse:

  • PARTES
  • CAUSA
  • SERVICIO
  • CONSENTIMIENTO (firma)
  • REGLAS: Regirán el servicio y permitirán mantener el acuerdo durante la prestación

EN TEORÍA: Las reglas se acuerdan libremente por ambas partes para crear condiciones óptimas que permitan completar con éxito el proyecto. En este acuerdo las dos partes “ganan”.

EN PRÁCTICA: Cada parte tratará de sacar ventaja.

Triángulo de Hierro

Triángulo de Hierro
* Si se modifica una variable, alguna otra también tiene que ser modificada. En caso contrario se pone en riesgo la calidad.
* En un contrato ágil el acuerdo entre las partes se tiene que poder revisar regularmente de manera ligera.
* Debe prestarse mucha atención en definir las reglas en base al alcance, costo y tiempo establecidos.

Metodología Ágil

Parte de los siguientes valores (definidos en el “Agile Manifesto”):

  • individuos y su interacción, por encima de los procesos y las herramientas.
  • software que funciona, por encima de la documentación exhaustiva.
  • Colaboración con el cliente, por encima de la negociación contractual.
  • Respuesta al cambio, por encima del seguimiento de un plan.

Se basa en el desarrollo de software iterativo. Se emplean ciclos cortos involucrando al cliente para definir y priorizar requerimientos, con el objetivo de que, a través de la colaboración con el equipo de desarrollo, se disponga de un producto potencialmente entregable al final de cada iteración.

El equipo de desarrollo es multifuncional y auto-organizado, es decir, es responsable de organizarse y gestionarse a sí mismo, siendo capaz de encontrar una solución a un problema sin que se le dictamine cómo debe resolverse.

La definición de un Contrato Agile supone un cambio de mentalidad que debe cubrir varios aspectos:

  • Colaboración estrecha y confianza mutua entre el cliente y el proveedor. La comunicación es esencial para facilitar la colaboración y creación de sinergias para obtener mejores soluciones.
  • Rápida capacidad de reacción ante imprevistos en el desarrollo
  • Flexibilidad en los requisitos del producto o servicio
  • Cobro por entrega de “valor”

Si en algún momento durante el proyecto hay que recurrir al contrato que se firmó al inicio, posiblemente esta sea una mala señal de que las cosas están empezando a ir mal y que la confianza se está deteriorando.

Desventajas de los contratos tradicionales

En el inicio del proyecto se intenta disponer de todos los requisitos detallados (abordar toda la complejidad funcional de una vez), elaborando un análisis funcional que formará parte del contrato.

Desventajas

  • Se deben plantear hipótesis antes de disponer de toda la información necesaria y de poder entender mejor el producto y contexto en que se va a desarrollar.
  • El cliente deberá pedir en el contrato todo lo que se imagine que en algún momento pueda ser necesario
  • Durante el desarrollo del proyecto aparecerán requisitos no relevantes
  • La verificación del cumplimiento de las expectativas del cliente, se deja para la última etapa, favoreciendo la imposibilidad de detectar requisitos no relevantes en etapas tempranas.
  • Las hipótesis que no hayan sido correctas y los requisitos no detectados a tiempo, llevarán a la necesidad de alterar drásticamente el triángulo de hierro, reduciendo notablemente la calidad del producto (o en el peor caso descartando al producto)
Contrato Marco

Permite incorporar anexos sin necesidad de una nueva negociación completa por las partes.

CONTENIDO:
Cláusulas comunes a cualquier contrato: Partes, fecha, dominio, etc.
Objeto del contrato: Debe especificar que las obligaciones se irán concretando a posteriori mediante la firma de anexos en los que se definirán las iteraciones.
Obligaciones de las partes: Además de las obligaciones comunes (formas y plazos de entrega, y de pago), hay que hacer hincapié en las obligaciones que derivan de trabajar con metodologías ágiles:

  • Duración del Sprint
  • Imposibilidad de modificar un sprint una vez definido
  • Periodicidad de reuniones
  • Pago por release
  • Procedimiento de cambio del product backlog, no solo para inlcuir nuevas funcionalidades sino también para priorizarlas y cuantificar en items el desarrollo de cada una de ellas

Glosario de términos Se recomienda incluir un glosario de términos
Product Backlog: El cliente es responsable de este documento y por tanto quien a definir y priorizar las funcionalidades de su producto/servicio. El proveedor establecerá el peso de cada funcionalidad. Si bien es mutable, el Product Backlog sirve como base inicial, se recomienda incluirlo como Anexo I.
Incumplimientos y sus consecuencias: Definir qué se considera incumplimiento de las obligaciones de cada una de las partes y que consecuencias tendrán. Por ejemplo se puede indicar las consecuencias que tendrá los retrasos en un sprint, o la cancelación anticipada del proyecto.
Pago inicial: Suele establecerse un pago por el asesoramiento técnico en la definición del Product Backlog y en la elaboración de presupuesto y contrato marco.
Cláusulas especificas de la prestación de servicios: Propiedad del código, mantenimiento de los desarrollos, backups, contratación de servidores, etc.

Tipos de Contrato

Contrato cerrado (AF CF)
* No ceptar cambios.
* Reducir feedback
* Descomponer el proyecto en varias fases de AC y CF.

Contrato Alcance No Vinculante (AV CF)
* Cambios sobre requisitos no desarrolldos que no modifiquen A
* Finalización anticipada (con retribución)
* Pago de tareas adicionales. Se recomienda primero completar los requisitos “baseline”
* Si se establece PF: Hacer tanto como se pueda en ese plazo

Contrato Objetivo (AF CV)
* Compartir ganancias y pérdidas: Fomenta que las partes colaboren y vayan mejorando.

Contrato Progresivo (AV y CV)
Dos alternativas:
* Pago fijo por iteración
* Pago por costo de iteración.

Aceptación del producto

Consta de dos pasos principales:
1) Revisión presencial.
2) Período de aceptación.

Uno de los riesgos concernientes al proceso de aceptación es que el cliente pierda la perspectiva de la globalidad del proyecto o del objetivo de la iteración, dando lugar reclamos. Se recomienda mostrar al finalizar cada iteración.
* Una visión del baseline, el trabajo ya realizado, pendiente, cambios o agregados respecto al alcance global, en forma de mapa del producto.
* La velocidad de desarrollo y la proyección de fecha estimada de finalización.

Referencias

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *