|
 Sobre requisitos estables y detallados, poner fecha y precio a un contrato puede ser más o menos complicado, pero sólo se trata de calcular esfuerzo y planificar trabajo.
Hacer lo mismo con requisitos inestables y sin certeza de la forma final del producto no es cuestión de ciencia, sino de mancia.
... ¿Por qué no tenemos requisitos detallados al empezar?
¿Porque necesitamos descubrirlos durante del desarrollo para mejorar de forma continua la visión del producto?.
¿Porque es un entorno de negocio muy inestable y en continuo cambio?...
O porque hemos decidido trabajar con un modelo ágil, y en los modelos ágiles no hay que planificar ni hacer requisitos detallados.
Si es por la última razón, quizá deberíamos analizar nuestros impulsos metodológicos.
Si el sistema se puede definir de forma completa, y previsiblemente estable, resulta más eficiente la gestión predictiva: trazar un plan y considerar a las modificaciones de requisitos como "incidencias" que se gestionarán con ingeniería clásica de requisitos.
Y como en este caso tendremos un cliente capaz de definir con detalle el resultado que desea, también querrá un contrato que le diga cuándo y por cuánto le va a salir: un contrato de obra que pueda revisarse si las partes acuerdan incluir tras la firma, modificaciones de requisitos con impacto significativo sobre los compromisos firmados.
Pero si se van a estar modificando los requisitos de forma continua, no es realista tomar como fiable un plan inicial; y si en esto no están de acuerdo cliente y proveedor, malamente podrán encajar de forma coherente sus respectivas responsabilidades de adquisición y suministro.
La idea es formalizar con contratos de obra los proyectos de requisitos cerrados, y con contratos de servicio los proyectos ágiles.
Es un planteamiento realista, pero también excesivamente simplista, porque los proyectos no son, o de la clase blanca, o de la negra. O "estos son los requisitos y ya no van a cambiar" o "ya te iré diciendo cada día lo que tienes que programar".
La forma de un contrato ágil es peliaguda, porque se trata de un equipo de trabajo, cliente incluido, que replantea en ciclos muy cortos cómo debe ser el producto. Parece por tanto razonable darle forma contractual de servicio, y cobrar al cliente por los recursos que consume durante el tiempo acordado.
Pero... ¡qué miedo para el cliente! ¿no?. En primer lugar, suponiendo que sea conocedor de la diferencia entre previsión y agilidad, y que reconozca que a su producto le conviene un modelo de desarrollo ágil; ¿se fiará y dirá:? "vale: yo contrato los servicios de un equipo de x técnicos + 1 Scrum Manager, pago tanto, y en el contrato no ponemos nada de qué tendré ni en qué fechas; que eso lo iremos descubriendo por el camino. (?¿?¿)". A mi se me ocurren dos formas de abordar este tipo de contratos:
1.- Si se trabaja con un proveedor o un equipo no contrastado, o en un proyecto que, aun teniendo un nivel alto de inestabilidad, permite fijar requisitos para iteraciones de desarrollo de un par de meses, se puede diseñar un marco contractual de servicio que fije el nivel de recursos y costes, con cláusulas que definan la creación de anexos periódicos (uno por iteración). En estos anexos las partes irán incluyendo los requisitos de cada iteración. Lo que en scrum sería la pila del sprint. 2.- Un contrato de servicio.
Si se trabaja con un equipo contrastado (incluido el propietario del producto), el contrato de servicio es la opción más ágil, que permitirá hacer iteraciones tanto de 2 como 8 semanas, replantear el producto o las fechas de cierre de versiones... 
 |
RSS de los comentarios
?) También me parece muy juicioso, y creo que está en mente de muchos, lo que apunta Miguel. Es como la pescadilla que se muerde la cola: para que un cliente confíe en ti de cara a aceptar un marco de trabajo en el que las especificaciones del software no estén más que esbozadas parece que debe ser un cliente satisfecho, con el que ya se ha trabajado durante mucho tiempo, lo que nos llevaría a la situación que plantea Miguel, ¿cómo "arrancar" un proyecto bajo una metodología ágil, desde el principio? ¿Quizá mostrando "casos de éxito" a la empresa contratante de proyectos desarrollados con una metodología similar? ¿Y cómo tener casos de éxito si no conseguimos nuestro primer proyecto desarrollado bajo metodología ágil? Un gustazo leer este blog, saludos 
Por otro lado, desde el lado más desarrollador que todos tenemos
Sobre los dos formas de contrato que mencionas,... ¿alguna vez has visto uno así para desarrollos informáticos? ¿la plasmación real de una metodología ágil en un contrato entre dos partes?