Cuando contratan a una empresa para hacer el desarrollo del software, la mayoría de los clientes prefieren un contrato a precio fijo. Dígale a los desarrolladores lo que quieren, negocie, acepte una oferta, y entonces la carga queda en la empresa de desarrollo para construir el software.
Un contrato a precio fijo requiere requisitos estables y por tanto procesos predictivos. Los procesos adaptables y los requisitos inestables implican que no se puede trabajar con la noción usual de precio fijo.
Tratar de encajar un modelo de precio fijo a un proceso adaptable acaba en una explosión muy dolorosa. La parte sucia de esta explosión es que el cliente queda herido tanto como la compañía de desarrollo de software. Después de todo el cliente no querría un software a menos que su negocio lo necesitara. Si no lo consigue su negocio sufre.
Así aún cuando no pague nada a la compañía de desarrollo, todavía pierde. De hecho pierde más de lo que pagaría por el software (¿por qué habría de pagar el software si el valor comercial de ese software fuera menor?).
De modo que hay peligro para ambos lados al firmar un contrato a precio fijo en condiciones dónde un proceso predictivo no puede usarse. Esto significa que el cliente tiene que trabajar de otro modo.
Esto no significa que no se pueda fijar un presupuesto para software por adelantado. Lo que significa es que NO se puede fijar el tiempo, precio y alcance. La manera ágil usual es FIJAR TIEMPO Y PRECIO y permitir que EL ALCANCE VARÍE de manera controlada.
En un proceso adaptable el cliente tiene mucho control a escala fina sobre el proceso de desarrollo de software. A cada iteración puede tanto verificar el progreso como alterar la dirección del desarrollo de software. Esto lleva a una relación mucho más íntima con los desarrolladores de software, una verdadera sociedad de trabajo.
Este nivel de compromiso no es para cualquier organización cliente, ni para cualquier desarrollador de software; pero es esencial para lograr que un proceso adaptable funcione apropiadamente.
El beneficio importante para el cliente es un desarrollo de software mucho más sensible. Un sistema usable, aunque mínimo, puede entrar en producción pronto. El cliente puede cambiar sus capacidades de acuerdo a los cambios en el negocio, y también aprender cómo se usa el sistema en realidad.
Una pieza tan importante como ésta es una visibilidad mayor sobre el verdadero estado del proyecto.
El problema con los procesos predictivos es que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente señalar cuando la realidad y el plan divergen. El resultado común es un gran resbalón más tarde en el calendario del proyecto.
En un proyecto ágil hay un constante rehacer del plan con cada iteración. Si las malas noticias están al acecho, tienden a aparecer más temprano, cuando aun se puede hacer algo al respecto. De hecho este control del riesgo es una ventaja clave del desarrollo iterativo. Los métodos ágiles van más allá manteniendo corta la duración de la iteración, pero también viendo estas variaciones como oportunidades.
Hay un aspecto importante en lo que constituye un proyecto exitoso. Un proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un proyecto que está a tiempo y en costo es un éxito.
Esta medida no tiene sentido en un ambiente ágil. Para el agilista la cuestión es el valor de negocio - si el cliente consigue un software más valioso que el costo que puso en él. Un buen proyecto predictivo irá de acuerdo al plan, un buen proyecto ágil construirá algo diferente y mejor que lo que se esperaba en el plan original.
Texto extraido de "The New Metodology" y traducido por Alejandro Sierra
Un contrato a precio fijo requiere requisitos estables y por tanto procesos predictivos. Los procesos adaptables y los requisitos inestables implican que no se puede trabajar con la noción usual de precio fijo.
Tratar de encajar un modelo de precio fijo a un proceso adaptable acaba en una explosión muy dolorosa. La parte sucia de esta explosión es que el cliente queda herido tanto como la compañía de desarrollo de software. Después de todo el cliente no querría un software a menos que su negocio lo necesitara. Si no lo consigue su negocio sufre.
Así aún cuando no pague nada a la compañía de desarrollo, todavía pierde. De hecho pierde más de lo que pagaría por el software (¿por qué habría de pagar el software si el valor comercial de ese software fuera menor?).
De modo que hay peligro para ambos lados al firmar un contrato a precio fijo en condiciones dónde un proceso predictivo no puede usarse. Esto significa que el cliente tiene que trabajar de otro modo.
Esto no significa que no se pueda fijar un presupuesto para software por adelantado. Lo que significa es que NO se puede fijar el tiempo, precio y alcance. La manera ágil usual es FIJAR TIEMPO Y PRECIO y permitir que EL ALCANCE VARÍE de manera controlada.
En un proceso adaptable el cliente tiene mucho control a escala fina sobre el proceso de desarrollo de software. A cada iteración puede tanto verificar el progreso como alterar la dirección del desarrollo de software. Esto lleva a una relación mucho más íntima con los desarrolladores de software, una verdadera sociedad de trabajo.
Este nivel de compromiso no es para cualquier organización cliente, ni para cualquier desarrollador de software; pero es esencial para lograr que un proceso adaptable funcione apropiadamente.
El beneficio importante para el cliente es un desarrollo de software mucho más sensible. Un sistema usable, aunque mínimo, puede entrar en producción pronto. El cliente puede cambiar sus capacidades de acuerdo a los cambios en el negocio, y también aprender cómo se usa el sistema en realidad.
Una pieza tan importante como ésta es una visibilidad mayor sobre el verdadero estado del proyecto.
El problema con los procesos predictivos es que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente señalar cuando la realidad y el plan divergen. El resultado común es un gran resbalón más tarde en el calendario del proyecto.
En un proyecto ágil hay un constante rehacer del plan con cada iteración. Si las malas noticias están al acecho, tienden a aparecer más temprano, cuando aun se puede hacer algo al respecto. De hecho este control del riesgo es una ventaja clave del desarrollo iterativo. Los métodos ágiles van más allá manteniendo corta la duración de la iteración, pero también viendo estas variaciones como oportunidades.
Hay un aspecto importante en lo que constituye un proyecto exitoso. Un proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un proyecto que está a tiempo y en costo es un éxito.
Esta medida no tiene sentido en un ambiente ágil. Para el agilista la cuestión es el valor de negocio - si el cliente consigue un software más valioso que el costo que puso en él. Un buen proyecto predictivo irá de acuerdo al plan, un buen proyecto ágil construirá algo diferente y mejor que lo que se esperaba en el plan original.
Texto extraido de "The New Metodology" y traducido por Alejandro Sierra
Comentarios
Publicar un comentario