La mayor parte de mi vida profesional, como muchos otros, la he vivido trabajando en proyectos a precio cerrado (fixed price) en concreto trabajando para administraciones públicas en las que el alcance del proyecto venía prefijado de antemano en pliegos de condiciones administrativas y claúsulas técnicas.
En este tipo de proyectos tienes que presentar una propuesta económica, de recursos y de tiempo a la administración pública que valorará cuál es la mejor de las ofertas presentadas, normalmente la de presupuesto económico más bajo, decidiendo luego qué proveedor será el adjudicatario. Por tanto, desde antes de iniciar el proyecto, tendrás que estudiar las condiciones y el alcance fijados en los pliegos y hacer una arriesgada estimación de cada una de las tareas o módulos que se requiere desarrollar y lanzar tu oferta.
¿Se puede ser ágil en proyectos en los que el costo, el alcance y a veces la fecha de entrega están cerrados desde el inicio? Yo pienso que sí, veamos cómo.
¿Qué hacer con el coste?
Este es el lado más arriesgado de este triángulo de hierro. Hemos hecho una estimación basada en lo que ponía en los pliegos de contratación pero estos contienen en la mayor parte de las ocasiones una descripción genérica de las tareas a realizar que luego se concretará a medida que se avanza en el proyecto o se analiza con las partes interesadas. Más que una oferta hemos hecho una apuesta que no sabemos si nos saldrá bien.
Tendremos que confiar en haber hecho una buena estimación. Por naturaleza todos tendemos a ser demasiado optimistas teniendo en cuenta sólo los escenarios en los que todo marcha bien. Sólo cuando usamos estimaciones tipo PERT en la que se nos obliga a ponernos también en el peor caso nos paramos a pensar en esos grandes imprevistos que siempre pueden pasar (como se dice en inglés, shit happens). A partir de aquí nos basaremos en las mejoras de eficacia que proporciona la agilidad.
En Scrum y otros frameworks iremos entregando cada poco tiempo una parte del alcance prometido lo que permitirá ir enseñando nuestros trabajo, haciendo correcciones y aprendiendo de lo que ya hemos hecho. En los proyectos en cascada también hay fases: Análisis, Diseño, Construcción y Testeo pero al final de las primeras sólo entregamos unos documentos sobre lo que se va a construir. Sería como analizar, diseñar un nuevo prototipo de móvil y esperar a construir 10.000 unidades para luego comenzar a venderlo y ver si le gusta a los usuarios que lo han comprado o no.
Incluir los tests y planes de aseguramiento de la calidad en cada sprint nos permitirá construir bien desde el inicio y con menos costes. Es mucho más fácil corregir los problemas de cobertura de un móvil cuando se está desarrollando y diseñando la antena en los primeros modelos que cuando ésta ya ha llegado a la línea de ensamblaje para la producción en masa.
¿Qué hacer con el alcance?
A medida que avanza el proyecto es habitual que el cliente se dé cuenta de que necesita cosas que no están incluidas en el contrato inicial. Elaboró los pliegos con el conocimiento que tenía en ese momento pero según se adquiere más experiencia en el proyecto y se va usando la aplicación (recordemos que la vamos entregando poco a poco para que la comiencen a utilizar) se va dando cuenta de que hay partes sin las que el software sería mucho menos provechoso.
En los proyectos ágiles en los que he trabajado admito modificaciones negociadas al alcance. Si se quieren incluir cinco informes nuevos a la aplicación que la harían mucho más útil deberemos acordar qué otras tareas de igual o similar estimación quitamos del alcance del proyecto. Normalmente está tan interesado en incluir las nuevas funcionalidades que no le importa sacar del proyecto otras tareas que ahora no ve tan importantes o que incluso considera que no deben hacerse.
Para la negociación habré presentado al cliente desde el arranque del proyecto una estimación de cada una de las funcionalidades a entregar de forma que sabe cuánto valen para él cada uno de estos puntos si decide quitarlos del alcance. Esta estimación fue realizada al inicio del proyecto y puede que ahora sepamos que hay cosas que son mucho más costosas de realizar de lo que estimamos al inicio, sin embargo, no cambio esta estimación inicial para que el cliente no se sienta engañado. Normalmente las estimaciones que ahora son más costosas son compensadas con otras que ahora sabemos que no lo son tanto y que también quiere que quitemos del proyecto. En cualquier caso, si hemos conseguido que el cliente esté satisfecho con el trabajo que le hemos ido entregando poco a poco y además está contento por las nuevas funcionalidades que va a conseguir, la negociación no debería ser muy dura.
¿Que hacer con el tiempo?
A veces, además de tener un importe económico y un alcance fijos tenemos que cumplir también con unas fechas de entregas inalterables que nos obligarían a aumentar las horas extras, los tiempos dedicados durante el fin de semana y el número de desarrolladores implicados en el proyecto aumentando considerablemente nuestro coste del proyecto.
Si hemos sido ágiles en el proyecto y hemos ido poniendo en producción cada poco tiempo lo que hemos ido desarrollando, el cliente podrá tener ya en uso el día de la fecha de entrega un porcentaje alto de lo que se necesita entregar. Si además hemos priorizado correctamente, desarrollando en primer lugar aquellas funcionalidades que más valor aportan, sólo quedarán fuera aquellas de menor importancia por lo que normalmente pueden entregarse en una segunda fase sin que se altere demasiado el valor del sistema.
Si hubiésemos realizado un desarrollo en cascada y estuviésemos retrasados, en la fecha de entrega no tendríamos nada que subir a producción a pesar de que podríamos tener un 80% del trabajo realizado. Durante las últimas semanas del proyecto tendríamos que abusar de las horas extras y del estrés para entregar ese 20% que nos falta pero probablemente sólo consigamos que sufra la calidad del software que entregamos y que se se ignore la fase de tests del desarrollo apareciendo un montón de bugs después de la entrega.
