El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos

Imagen obtenida de: Picasa Web Albums

Una de las premisas del desarrollo ágil es que los requerimientos son cambiantes o poco definidos, por lo cual hace énfasis en la flexibilidad y productividad, favoreciendo un esquema en el cual el alcance de un proyecto no estará definido desde el principio. Este principio está en conflicto con los esquemas de fecha, presupuesto y alcance fijos definidos a nivel corporativo a la hora de contratar proyectos de desarrollo de Software, tanto con la unidad de Tecnología de Información (TI) interna como con proveedores externos.


Es poco probable que otras áreas de la compañía, como por ejemplo finanzas o el negocio estén dispuestas a abandonar el esquema de alcance, cronograma y presupuesto fijo de la noche a la mañana, especialmente en etapas de adopción temprana del desarrollo ágil cuando este concepto les es extraño y aún no han visto los resultados.

Este artículo está dedicado a mostrar que aplicando algunos cambios, ambos esquemas pueda coexistir durante esta etapa de adopción inicial.

Un argumento que se escucha con frecuencia es que en un proyecto ágil no puede definirse una fecha tope, debido a que no sabemos que se entregará al final, por lo que no podemos estimarlo. Pues bien, en un proyecto tradicional tampoco nadie sabe que se terminará entregando al final (y por eso los estimadores agregan holguras), aún así se define una fecha final y cuando esta se alcanza muchos asuntos quedan por resolver.

¿Por qué definir también una fase de análisis y diseño inicial para un proyecto ágil?

Para que ambos esquemas puedan coexistir, es necesario mantener una fase de definición de alcance, cronograma y presupuesto al inicio del proyecto, siendo esto previo a la primera iteración. Algunos llaman a esto la “iteración 0”, sin embargo, no necesariamente tendrá la misma estructura y duración de una iteración ágil.

Deben aplicarse procedimientos adaptados al desarrollo ágil a esta fase, ya que aplicar el mismo enfoque de cascada podría ser un error. La intención de esta fase es desarrollar las historias de usuario y elaborar una primera lista de objetivos / características priorizados (el “product backlog”) general. Con base en esa lista de características se puede definir un conjunto mínimo de funcionalidades, fijando con esta base la fecha tope y presupuesto para el requerimiento ó proyecto.

El procedimiento a seguir en esta fase es muy similar al de un proyecto tradicional, pero requiere las adaptaciones necesarias para hacer uso de los artefactos de desarrollo ágil.

Dinero por nada y cambios gratis (Money for nothing and Changes for free):

Una vez que comienzan las iteraciones (sprints), el esquema de desarrollo ágil y de fecha tope fija pueden coexistir si se utilizan los principios de “dinero por nada” y “cambios gratis” (Money for nothing and changes for free, igual que la famosa canción de Dire Straits de 1985).

“Cambios gratis” significa que el cliente (el área de negocio representada en el dueño del producto o “product owner”), puede reemplazar cualquier historia de la lista de características (“product backlog”) por historias de igual valor (medio en puntos de historia, jornadas o cualquier otra medición acordada), siempre y cuando esto se haga antes que la historia involucrada haya sido tomada para una iteración (si esto ocurriera el cambio no sería gratis, dado que tendría un costo de retrabajo para el proveedor). 

Este principio garantiza que el cliente al final obtendrá el producto que quiere sin invertir más tiempo o dinero del estimado originalmente.

"Dinero por nada significa" que el cliente en cualquier momento puede declarar que ha recibido suficiente funcionalidad, aún en los casos en que no se hayan entregado las funcionalidades definidas originalmente. En estos casos, el cliente deberá pagar por las jornadas de consultoría invertidas en el análisis, pero no por las funcionalidades que no se han desarrollado. De hecho, podría considerar la posibilidad de invertir esos puntos de historias en otra aplicación o funcionalidad si es conveniente para el proveedor y el cliente.

En Conclusión

La situación ideal sería que la organización adoptará el enfoque ágil en todos sus niveles, cambiando las formas de contratación internas con el departamento de TI o con proveedores a otras que correspondan con el desarrollo ágil, como por ejemplo costo objetivo más incentivo o tiempo y materiales.

Sin embargo, la realidad indica que antes que las áreas de negocio y finanzas estén dispuestas a realizar estos cambios, deben ganar confianza en que el desarrollo ágil funciona y que es factible para ellos abordar estas fuentes de contratación que son más riesgosas para quien adquiere el Software.

La única forma de ganar esa confianza es adoptar algunas prácticas ágiles sin cambiar todo el esquema de contratación y los métodos presentados en este artículo pueden servir para lograr ese objetivo.

¿Y tú?, ¿Qué opinas?

¿Te has encontrado con las situación de tener que combinar un enfoque de desarrollo ágil con un esquema de contratación predictivo?, ¿como lo manejaste?, propondrías algún enfoque ágil para manejar las contrataciones?. Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (puedes firmar tu comentario con la dirección de tu web si así lo deseas).

¿Te ha gustado este artículo?, entonces siguenos en nuestras redes?

Te invitamos a suscribirse por los distintos canales, incluyendo lista de correo electrónico, al Twitter @PMOInformatica, a nuestra página de Facebook o al feed RSS.

Referencias:

>> Proyectos Ágiles.org
>> Scrum and Fixed Price Impossible?
>> How to apply Scrum in fixed date, fixed budget projects?