Contrato de Software Agil - Principios Scrum

Cuando una organización necesita contratar una empresa para abordar el desarrollo de sistemas de información generalmente suscribe un contrato donde se describe en esencia los derechos y deberes de ambas partes.

En este post comparto algunas políticas que he utilizado en contratos para garantizar una adecuada gestión en proyectos de software mediante la incorporación de algunas practicas ágiles. Los beneficios son incalculables!

A continuación describo las secciones o áreas de dominio que podrían ser utilizadas para modificar los contratos.

Sobre el enfoque de ejecución

1. El proyecto sera ejecutado sobre un enfoque iterativo e incremental.

Sobre el Acta de Inicio y Contrato

1. LA ORGANIZACIÓN realizara con LA CONTRATISTA reuniones de inicio para establecer las premisas requeridas para la firma del contrato y el acta de inicio del proyecto.

Acta de Inicio

1. LA ORGANIZACIÓN realizara con LA CONTRATISTA reuniones de inicio para establecer las premisas generales del proyecto, las cuales serán descritas en un acta de Inicio.
2. El tamaño de cada iteración, será acordado entre ambas partes, y dependerá del tiempo del contrato y el alcance previsto.
3. Los roles y responsabilidades requeridos para la ejecución del proyecto, será acordado entre ambas partes, registrándose en el acta de inicio del proyecto.
4. Las políticas de comunicación requeridas para la ejecución del proyecto, será acordado entre ambas partes, registrándose en el acta de inicio del proyecto.

Entregables o Requisitos

1. LA ORGANIZACIÓN realizara con LA CONTRATISTA reuniones de inicio para establecer los entregables o requisitos que serán desarrollados en el plan iterativo e incremental del proyecto.
2. Los entregables o requisitos por cada iteración, serán acordado entre ambas partes, y dependerá de su priorizacion y valor por parte de LA ORGANIZACIÓN.
3. Los entregables o requisitos serán priorizados a partir de un acuerdo entre las partes, de modo que en las primeras iteraciones se obtendrán los objetivos más importantes del proyecto.
4. El plan de trabajo estará conformado por los entregables por cada iteración, registrándose en el acta de inicio del proyecto.

Contrato

1. LA ORGANIZACIÓN establecerá las condiciones de contratación, utilizando los acuerdos y compromisos registrados en el acta de inicio.

Control y Seguimiento de Proyecto

1. Las actividades de control y seguimiento del proyecto se basará en los entregables completados en cada iteración y en la demostración que debe realizar LA CONTRATISTA. Se entenderá como requisito completado, si incluye todos los entregables asociados de las iteraciones anteriores.
2. El proyecto se ejecutará en iteraciones, con una demostración del producto al finalizar cada iteración.
3. En cada iteración, se generara un acta de aceptación de los entregables y demostración.
4. En cada iteración, se generara un informe de avance para el Gerente del area, donde se deberá registrar el porcentaje de finalización para cada requisito y la tasa de requisitos completados.
5. LA ORGANIZACIÓN ejercerá funciones de inspección del servicio, quien podrá hacerse asistir por personal interno o externo, según lo estime prudente, a su solo juicio. LA CONTRATISTA se compromete a facilitar a la organización o a la persona que hubiere designado, toda la información que fuere necesaria o conveniente para verificar, fiscalizar y supervisar la ejecución del presente contrato; en general, LA CONTRATISTA prestará al personal encargado de la inspección del servicio la más amplia cooperación a los fines de facilitar la adecuada ejecución dentro de los tiempos, calidad y demás condiciones convenidas.

Control de Calidad

1. Todos los entregables acordados entre ambas partes, serán sometidos a un ciclo de calidad definidos en el “Plan de Aseguramiento de Calidad” y no serán admitidos como productos del proyecto, hasta alcanzar un nivel aceptable.
2. Cada iteración deberá producir software con calidad de producción, probado, integrado, y documentado.
3. El proyecto deberá incorporar prácticas “Desarrollo Gestionado por Pruebas”. Cada uno de los entregables, deberá contener scripts de pruebas unitarias, integrales, funcionales, entre otros.
4. En caso que LA ORGANIZACIÓN encontrare alguna incidencia en la demostraciones del producto realizadas en cada iteración por la LA CONTRATISTA, la organización informará a LA CONTRATISTA sus observaciones para que proceda a realizar su corrección.

Controles de Cambio

1. Sólo podrá solicitar cambios en los requisitos y sus prioridades el propietario del producto y estos serán debidamente analizados para establecer si no impactan el alcance del proyecto.
2. LA ORGANIZACIÓN podrá solicitar cambios en los entregables durante la demostración que realiza LA CONTRATISTA, al identificar alguna corrección funcional, técnica, o dependencia requerida para cumplir con los entregables que integran una iteración.
3. La adición de nuevos requisitos tras las demostraciones, no implicará ningún costo adicional si no impactan el alcance del proyecto, de lo contrario deberán ser negociados entre las partes  para determinar su viabilidad, en función de no impactar el alcance del proyecto.
4. Todo cambio solicitado por LA ORGANIZACIÓN sera debidamente documentado y registrado mediante un formato para la realización de “Controles de Cambio”.
5. No se consideran cambios las subsanaciones por parte del equipo de desarrollo de los defectos de calidad de los entregables entregados en cada iteración.
6. Se conformará un comité de proyecto que analizará los cambios solicitados y nuevas solicitudes.
7. Los cambios en prioridades de la lista de entregables o requisitos no implicarán ningún coste adicional en el proyecto siempre que se mantenga el cómputo total de horas del contrato.

Documentación

1. Toda la documentación del proyecto deberá ser entregada de forma incremental e iterativa, es decir, la documentación no se liberara al final del proyecto, sino en entregables parciales.

Políticas para el desarrollo de software ágil

Una organización que requiera agilidad en la ejecución de sus proyectos de software necesita del establecimiento de políticas que garanticen entrega temprana y continua de artefactos y servicios de software de valor y utilidad.

A continuación describo un conjunto de políticas que he utilizado en consultorias, que permitirán a la organización alejarse del modelo de desarrollo de software tradicional donde se realizaba un levantamiento de información durante 3 meses, y luego 2 meses para el desarrollo. Este tipo de desarrollo no permitía la entrega temprana de valor y no consideraba las siguientes realidades:

1. Es imposible reunir a todos los requisitos al principio de un proyecto.
2. La actividad de análisis y diseño no garantiza que no habrá cambios.
3. Siempre existirán desviaciones en tiempo y recursos.

Lineamientos Generales

1. El proyecto deberá ser ejecutado en iteraciones incrementales con una demostración del producto al finalizar cada iteración: con esta política, se conocerá el estado del proyecto, evaluando si los requisitos cumplen con las expectativas del cliente, si la calidad es la esperada, o si hay retrasos; agilizando la toma de decisiones correctivas.
2. El proyecto se ejecutará en iteraciones incrementales con una duración fija de 3 semanas.
3. Los requisitos se desarrollarán priorizados por el valor aportado al cliente: Esta política permitirá que los objetivos más importantes del proyecto sean atendidos.
4. El control y seguimiento del proyecto se basará en los requisitos completados en cada iteración. Se entiende como un requisito, los entregables asociados a: análisis, desarrollo, pruebas, documentación, etc. e integrados con los entregables de las iteraciones anteriores.
5. Cada requisito debe ser independiente del resto de los requisitos, en la medida de lo posible.
6. Cada requisito debe ser demostrable, permitiendo cómo comprobar con el cliente que el requisito está completado y que se cumplen sus expectativas.
7. El requisito debe ser de un grado de esfuerzo para ser completado semejante al del resto de requisitos: de manera que la organización y el cliente, puedan realizar una extrapolación del progreso del proyecto.

Desarrollo

1. Los componente de software, deberán ser desarrollados y liberados por partes, y no entregados al final del proyecto.
2. El desarrollo de los componente de software que conformaran la solución, deberán ser liberados en varias iteraciones.
3. Cada iteración deberá producir software con calidad de producción, probado, integrado, y documentado (funcional, técnica).
4. Cada iteración deberá cumplir con un subconjunto de requerimientos.
5. Cada iteración deberá contemplar (análisis, diseño, implementación, documentación, etc.).

Pruebas

1. Cada proyecto debe incorporar las practicas de TDD (Test Driven Development).
2. Cada uno de los entregables, deberá contener scripts de pruebas unitarias, integrales, funcionales, etc; mediante la utilización de frameworks como junit, dbunit, mockObjtects, etc.

Documentación

1. La documentación del proyectos, específicamente:  manual de usuario, manual de operaciones, arquitectura de la solución, especificaciones, etc; deberán ser entregables parciales para cada una de las iteraciones, es decir, la documentación no se liberara al final del proyecto, sino en entregables parciales.

Control de Calidad

1. Cada uno de los entregables, serán sometidos a un script de calidad, que ejecutara la organización,  y no serán admitidos como productos del proyecto hasta alcanzar un nivel aceptable.

Control de Riesgos

1. Los riesgos serán identificados en la primera iteración, llevándose a cabo también una valoración inicial de la exposición al riesgo y planes de contingencia. En cada iteración se revisará y actualizará el documento “Lista de Riesgos”, añadiendo además la lista de riesgos más importantes actualizada por cada iteración.

Control de Artefactos

1. Cada uno de los artefactos del proyecto, deberán ser mantenidos bajo un sistema de control de versiones.
2. La organizacion disponibilizara un sistema de control de versiones, que deberá ser actualizado por el cliente de forma remota.

"Es increíble el cambio que puede producir en una organización la incorporación y aplicación de políticas de desarrollo de software ágil".