Desarrollo de software ágil: ¿Cómo reaccionas * financieramente * ante los requisitos cambiantes del usuario?

Hay una cosa que siempre me he preguntado al leer sobre todas estas cosas de "desarrollo ágil" aquí en SE y otros sitios:

En ingeniería de software "tradicional", usted

1. recopilar los requisitos del usuario,
2. escribir una especificación basada en estos requisitos,
3. entregárselo al cliente y facturarle el trabajo realizado hasta el momento,
4. hacer un diseño técnico (aproximado), para que pueda estimar el costo de implementación,
5. dar al usuario un presupuesto para la implementación,
6. espere a que el cliente firme la especificación y acepte la oferta,
7. diseñar, implementar, probar,
8. cuenta.

Si, durante el proceso, los requisitos cambian, envía una oferta (con un precio) por los cambios deseados (o lo hace de forma gratuita si el cambio es pequeño, le gusta el cliente y el cliente no lo hace con demasiada frecuencia) .

Entonces, ¿cómo funciona esto (financieramente) en un proyecto ágil, donde los cambios frecuentes de requisitos son parte del proceso?

• ¿Escribe una oferta para cada cambio de diseño? (¿No sería esto un desastre?)
• ¿O negocia un precio fijo y espera que el cliente no cambie los requisitos con demasiada frecuencia? (Podría ser arriesgado, conozco a clientes que aprovecharían esta oportunidad para solicitar nuevas funciones durante años antes de aceptar que el proyecto se haya completado).
• ¿O simplemente le factura al cliente el tiempo total requerido? (Podría ser riesgoso para el cliente, que no conoce el costo por adelantado).

En un mundo ágil ideal, usted acuerda un precio por adelantado y varias horas, pero no el alcance. El cliente decide cuál es el producto útil mínimo, en lugar del producto que realmente quiere, y eso debería estimarse bien debajo de la cantidad de horas acordadas.

Luego, se los entrega de forma iterativa y cambian de opinión todo lo que quieren, pero nunca se pasa la cantidad de horas acordadas. En teoría, y a menudo en la práctica, terminan con el producto que realmente necesitan en lugar del producto que realmente quieren.

Y si quieren continuar pagándole por horas adicionales después del valor acordado original, también está bien. Si hace un trabajo lo suficientemente bueno para hacer que el progreso sea visible, a través de las tarjetas de historia, Greenhopper o lo que sea, puede hacer que sea muy obvio para el cliente qué características están perdiendo (o al menos despriorizando) cada vez que agregan algo nuevo, lo que en gran medida pone una parada a los cambios frívolos.

Hay dos riesgos dignos de mención aquí. Primero es que el cliente puede tener miedo, si no ha entendido Agility por adelantado. Parece que está tomando todo el riesgo. Solo la experiencia muestra que él no es realmente.

El segundo es que deben participar, durante todo el proceso, o todos perderán. Muchos clientes no entienden qué tan comprometidos deben estar hasta que sea demasiado tarde.

Pero si usted, como empresa, lo explica bien, todos son ganadores.

Algunas personas trataron de dar soluciones a utilizar la agilidad en los proyectos de precio fijo en el pasado. Personalmente, creo que generalmente no es posible.

Scrum, en particular, es adecuado para empresas de software de productos y se utiliza menos en empresas de servicios.

Puede usar algo de agilidad en sus proyectos, como iteraciones, stand-ups diarios, burndorn, etc., pero puedo asegurarle que si ofrece una cierta cantidad de cosas por un precio determinado y entrega menos de lo que estaba en el contrato, Tendrás un problema.

Por favor, no sirva Agility à toutes les sauces . Debemos usar la solución adecuada a un problema dado.

Esto no está realmente relacionado con la programación ágil o cualquier modelo que utilice. Al trabajar como profesional independiente, utilizo una combinación de cascada y modelo V, pero sigo teniendo el mismo problema: ¿qué pasa si el cliente quiere cambiar algo durante el diseño detallado? ¿Qué pasa si él hace cambios durante la implementación?

El enfoque que debe utilizar depende del cliente y sus relaciones.

Si un contacto es imprescindible para todo lo que hace por este cliente, porque sabe que intenta no pagar cuando puede, o intentará demandarlo siempre que sea posible, entonces sí, debe escribir una oferta por cada pequeño cambio en los requisitos. No es un desastre: si está bien organizado, puede que no sea demasiado difícil acomodar un nuevo requisito durante el desarrollo. Pero seguro, es una pérdida de tiempo y dinero, y es bastante extraño tener que firmar una oferta de cambio que le llevará dos horas implementar.

Para otros clientes, el enfoque que funciona bien es el siguiente:

• Al firmar la primera oferta, especifique el costo estimado y el costo máximo. El costo estimado no significa nada legalmente: es solo una estimación. El costo máximo tiene valor legal: si usted dice que el producto le costará $ 3,000 a su cliente, y finalmente le costará $ 3,157.24, el cliente aún tendrá que pagar $ 3,000. En la práctica, en la mayoría de los casos, el costo real será menor que el máximo dado y más cercano a su estimación.

• Cuando el cliente solicite cambiar un requisito, calcule el costo que tiene y compárelo con el costo real y el estado. Si casi termina el producto y el costo real es de $ 2,108.36 y el costo del cambio se estima en $ 150, simplemente hágalo. Si, por otro lado, existe el riesgo de alcanzar el máximo, entonces dígale a su cliente que debe reevaluar el costo total juntos.

Ágil y 'Escribir una oferta' parece una antítesis :) - este último no es ingeniería de software productiva: D

Bien, ahora que tenemos el chiste fuera del camino, volviendo a la realidad.

"¿Cómo funciona en Agile ?" - El contrato complica las cosas, pero espero que quede claro. Agile se basa en el principio de 'confianza' y 'trabajo conjunto', lo que significa que el cliente puede cambiar lo que sea, en cualquier momento y comprende que puede costar un poco más o, si no es intrusivo, tal vez sin costo adicional.

¿Qué significa esto? Significa que el contrato explica que nosotros (el cliente) fijamos una estimación inicial del costo y el% de varianza +/- que podemos manejar, por ejemplo, una oferta de $ 100K pero estoy dispuesto a subir a $ 120K (esto PUEDE no ser parte del contrato, pero en la mente del cliente).

Ahora, cuando llega un cambio de diseño, usted es ágil con la estimación y la planificación: reúne a su equipo y les pregunta el 'punto de la historia' estimando la complejidad de la factorización de los cambios. Debido a una estimación de velocidad, podría multiplicarlos y dar una estimación de horario. Debería ser relativamente fácil reducir el costo por punto de historia si conoce el equipo y sus salarios relativos (no promedie el salario de TODOS, sucumbirá a la falla de los promedios).

¿Necesita volver al cliente con las finanzas? NO. No necesariamente. Hará que el cliente los priorice e inserte en el lugar correcto de la cartera de pedidos. Ahora que conoce el tamaño del trabajo atrasado (debería hacerlo si aún no lo sabe) y en función de los aspectos financieros (costo por punto de historia), sabe qué requisitos de baja prioridad pueden no ser factibles con el presupuesto dado. MOSTRARLOS el trabajo atrasado priorizado con la estimación de las características factibles según el contrato $$. Luego deje que ELLOS decida si está dispuesto a pagar más para obtener más si / cuando usted / ellos lleguen allí. Si lo quieren gratis ... toma una posición y diles que costará más.

Esto debería ayudar sin que usted vuelva constantemente con las finanzas si puede tener este gráfico en algún lugar para que el cliente lo vea.

¡Espero que esto ayude!

La experiencia de otras personas probablemente variará, pero una forma en que lo he visto hacer es en gran medida lo mismo que su "tradicional" con un par de cosas a tener en cuenta:

1. Incorporar algunos gastos generales para los cambios (por ejemplo, 10%)
2. Evaluar y facturar por separado los grandes cambios o los cambios agregados y facturar más allá del costo incorporado (un buen ejemplo, aunque no sea la programación, es el trabajo de diseño, donde a menudo el costo inicial incluye, por ejemplo, 3 revisiones, y las revisiones posteriores o quizás rehacer total extra)

A menudo, también, los proyectos ágiles comienzan como un elemento "central" y salen de allí de forma modular según sea necesario (he visto que esto sucede bastante en los proyectos en los que participé). Entonces, comienza con un producto central, digamos que es una aplicación de mapeo. La primera implementación es solo un mapa que se centra en su ubicación actual (lo que el cliente ordenó inicialmente).

Luego, el cliente decide que quiere tener pasadores de ciertas atracciones a su alrededor. De acuerdo, esa es una pieza bastante grande (relativamente hablando), por lo que lo factura como un nuevo "módulo" o pedido de compra. Los cambios en cosas como el color o el diseño de esos pines están incluidos en el costo de ese pedido. Las instrucciones y las superposiciones son otra orden de compra, ya que no se solicitaron hasta después de que la otra orden de compra estaba en marcha, y así sucesivamente.