# Contrato cerrado VS Alcance abierto

En este post voy a realizar una comparativa entre dos maneras de realizar un PROYECTO. Por un lado, la forma clásica hasta ahora, es la realización de un proyecto mediante un contrato cerrado, basado en una metodología Waterfall. Por otro lado, podemos realizar un proyecto manteniendo el alcance abierto y revisando el avance de forma iterativa, basado en metodologías ágiles.

# Contrato cerrado

Características de un proyecto acordado mediante un contrato cerrado

# Fecha de entrega prefijada.

Antes de iniciar el desarrollo del proyecto ya está establecida la fecha de finalización del mismo, lo cual es difícil de asegurar. Cuanto máayor sea el proyecto, mayor probabilidad de que aumente la desviación en tiempo del mismo y, por lo tanto, en coste y calidad.

# Alcance fijo acordado previamente.

Al tratarse de una metodología de gestión dividida en fases muy marcadas (toma de requisitos, diseño, implementación, verificación y mantenimiento), requiere que el alcance total del proyecto esté definido previamente de forma contractual, lo que en el caso del desarrollo de software es realmente complicado de que se cumpla. Además, esto requiere que el cliente conozca a la perfección la necesidad que desea cubrir, lo que en mi experiencia en la realizacion de proyectos de desarrollo software es irreal y muy difícil de tener claro.

# Poco flexible ante los cambios.

Es una consecuencia de los dos puntos anteriores, puesto que tenemos prefijados tanto la fecha de finalización del proyecto como el alcance del mismo, la reacción al cambio es compleja puesto que no se dispone de margen para ello.

# Alcance abierto

Características de un proyecto ejecutado mediante alcance abierto

# Servicio por horas/sprints sin fecha de fin concreta.

La finalización del servicio la marca el valor entregado y las necesidades de los usuarios. Con cada iteración se realiza una entrega de valor de modo que es analizada por todos los interesados. Con ello se valida la entrega y se marcan los siguientes pasos a realziar en base al valor.

# Priorización de tareas según VALOR.

Utilización de un backlog que incluye las historias de usuario a realizar ordenadas en función del valor que aportan. De esta manera nos aseguramos (al menos de una forma más cercana a negocio) que el equipo de desarrollo trabaja para entregar las funcionalidades que más valor aportan a los interesados.

# Reacción al cambio.

Puesto que se realizan iteraciones cortas, se analiza cada poco tiempo las necesidades de los usuarios y la satisfacción obtenida tras cada sprint, puediendo cambiar el sentido del desarrollo o repriorizar las historias de usuario según el feedback del mercado. No es necesario esperar hasta fechas muy avanzadas para poder reaccionar a las necesidades que pueden surgir, esto se consigue mediante un ejercicio de inspección y adaptación iterativo.