Inicio Make Text BiggerMake Text SmallerReset Text Size
¿Métodos de desarrollo ágil con contratos de fecha y precio cerrados?. E-mail
Valoración del artículo: / 7
MaloBueno 
26.07.2005
firmaDe momento es una combinación peligrosa.
Jamer World, Randy Miller, Andrew Cheeseman y Roy Osherove la trataron en la mesa redonda "Agile Development" que se celebró el 7 de julio en la Tech-Ed de este año, sin dar con más solución que el transmitir al cliente las ventajas y razones del desarrollo ágil, para que comprenda que al ser un modelo sin una planificación inicial cerrada, y estar abierto al cambio continuo, no permite cerrar fechas y precios.

El mismo Ken Schwaber, en su libro "Agile Project Management with Scrum", dedica el apéndice D a esta cuestión, en el que afirma "I didn’t know how to use Scrum to address his business. Scrum’s principle is “the art of the possible,” not “you give me what I paid for, when you said that you’d deliver it."

Pero por desgracia los clientes tienen la mala costumbre de querer saber cuándo tendrán programada la solución para su problema, y cúanto les va a costar; y algunos son tan suspicaces que no se fían si no lo firman en un contrato. ¿Puede una empresa de software comprometerse contractualmente en fechas y costes con sus clientes, y al mismo tiempo emplear un modelo de gestión de proyectos que no se los puede garantizar?.

A grandes rasgos, las dos líneas generales de gestión de proyectos son: el marco ortodoxo, con CMMI y PMI como máximos exponentes, y el marco ágil, del que scrum posiblemente sea el representante más significativo.

En la primera son aspectos clave:
  • Obtención y análisis de los requisitos previos a la planificación y estimación del proyecto.
  • Planificación y estimación objetiva basada en los requisitos.
  • Gestión de requisitos durante todo el ciclo de desarrollo con procesos rigurosos para aceptar los cambios y modificaciones, evaluando su impacto (que puede conllevar revisiones del contrato) y recabando la conformidad del cliente.
  • Procesos objetivos de validación y verificación contra requisitos.

Y en el segundo:
  • Desarrollo iterativo en ciclos breves (sprints).
  • Apertura al replanteamiento de los requisitos en el inicio de cada ciclo (backlog).
  • Incorporación del cliente (product owner) al equipo del proyecto.

La gestión de proyectos ortodoxa sí que está preparada para afrontar los compromisos de fecha y coste, pero pagando el precio de mayor rigidez en los procesos para aceptar cambios.
La gestión de proyectos ágil no puede afrontar los mismos compromisos, y por contra resulta muy flexible para incorporar modificaciones de requisitos.

Volviendo a la preguna de si se pueden emplear modelos ágiles y firmar contratos con fechas y costes cerrados, lo cierto es que sí. De hecho algunas empresas firman fechas sin contar con modelos de gestión de proyectos. Ni ortodoxos, ni ágiles; pero estas aventuras no dejan de ser bastante temerarias.

Las empresas son entornos sistémicos con múltiples relaciones internas, y esta es una de ellas: los modelos de contrato, con los modelos de procesos para el desarrollo.

Los marcos legales que delimitan las modalidades contractuales posibles son diferentes en cada país, pero en cualquier caso, no está de mas conocer cuáles son las opciones jurídicas, para no mezclar modelos de producción y de contratación incompatibles.
La legislación española establece en el artículo 1544 del Código Civil, que en los contratos de "obra o servicios" una de las partes se obliga a ejecutar una obra o a prestar a la otra un servicio por un precio cierto.
Lo cierto es que nuestra legislación enturbia un poco el asunto al definir conjuntamente el arrendamiento de obras y el de servicios sin aportar los criterios para distinguir cuando estamos ante uno u otro, porque sería de gran ayuda poder contar con dos modelos diferentes para diferenciar sin ambages si el objeto es una obra cierta en una fecha cierta, o el realizar trabajo de programación según las indicaciones continuas del cliente.

Los criterios que deben emplearse para poder diferenciar en el contrato cuál es la figura que recoge (si obra o servicio), por ser los que ha manejado nuestra doctrina y jurisprudencia son:
  • En el contrato de prestación de servicios se debe una actividad, sin tener directamente en cuenta el resultado del servicio, mientras que en el de ejecución de obra el objeto de la prestación debida es el resultado final, con idependencia del trabajo necesario para lograrlo.
  • En el contrato de servicios la remuneración acostrumbrada debe ser proporcional al tiepo de duración de los servicios contratados, por contra en el contrato de obra es normal fijar la retribución en proporción al número o medida de la obra.
  • En el contrato de servicios la prestación de éstos se realiza en situación de dependencia de quien los recibe, en tanto que en el de obra la actividad dirigida a lograr el resultado es realizada por un contratista o empresa independiente.

Algunos fragmentos de sentencias del tribunal supremo que recogen la diferencia entre ambas figuras:

"Como de obra o empresa en cuanto el profesional se obliga a prestar al comitente, más que una actividad, el resultado de la misma,"
"la jurisprudencia viene manteniendo que nos hallamos en presencia de un arrendamiento- de obra cuando su objeto viene constituido por el resultado concreto prometido por el profesional; y no la prestación de unos servicios, además el precio era cierto y determinado"

En consecuencia, un desarrollo guiado con un marco de gestión ágil, puede garantizar al cliente que cada mes se le hará entrega de nuevas funcionalidades operativas, que habrán sido las acordadas en las reuniones de trabajo en las que él participará.
El contrato debería ser por tanto un contrato de servicio en el que nos comprometiéramos a realizar los trabajos que se indiquen en las actas de cada reunión mensual (backlog), y que el cliente adquiere también una obligación de colaboración en el proyecto.

Un desarrollo conducido por un modelo de gestión ortodoxo puede cerrar fechas, precios y funcionalidades, pero no debería hacerse antes de disponer de las funcionalidades del sistema.
Para sistemas complejos, una forma de trabajo adecuada consiste en la firma de un contrato previo de consultoría para realizar la obtención y análisis de requisitos, y otro posterior de fecha y precio cerrado, siendo el documento de requisitos parte contractual de la definición de la obra y criterio para validar el resultado final.
Este tipo de contratos deben fijar también con claridad los procedimientos para introducir modificaciones de requisitos durante el desarrollo, que pueden suponer revisiones del contrato inicial.
Comentarios (1)Add Comment
Interesante punto de vista
escrito por Invitado, July 26, 2005
Muy interesante.
Lo que está bastante claro es que aunque hasta ahora con los métodos más ortodoxos se firmasen contratos cerrados, no servían para cumplir los plazos, más que nada para que la empresa cliente pudiese pedir responsailidades (que no es poco)
Pero me gusta la idea de hacer un servicio donde se compromete a entregar cada mes los requisitos acordados. Aunque implica un cambio en la mentalidad de las empresas tan grande, que no sé si será posible verlo mucho.
Por otra parte, a lo mejor las últimas tendencias de externalizar las funciones tencnológicas pueden favorecer este cambio.

Joserra
Najaraba
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0

Escribir comentario
quote
bold
italicize
underline
strike
url
image
quote
quote
smile
wink
laugh
grin
angry
sad
shocked
cool
tongue
kiss
cry
reducir | aumentar

busy
 
< Anterior   Siguiente >

En Navegapolis
En Internet

Advertisement

Amigos de Navegápolis

Área de descargas

(c) Navegapolis