Desarrollo de software ágil: ¿Cómo reacciona * financieramente * a los requisitos cambiantes de los usuarios?

13

Hay una cosa que siempre me he preguntado al leer todo este material de "desarrollo ágil" aquí en SE y otros sitios:

En la ingeniería de software "tradicional", usted

  1. recopilar los requisitos del usuario,
  2. escriba una especificación basada en estos requisitos,
  3. entregárselo al cliente y facturarle por el trabajo realizado hasta ahora,
  4. haga un diseño técnico (aproximado), para que pueda calcular el costo de la implementación,
  5. dé 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. proyecto de ley.

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) muy a menudo).

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

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

5 respuestas

13

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

Luego, les entregas de forma iterativa y cambian de opinión todo lo que quieren, pero nunca pasas por el número 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ándote horas adicionales después del valor original acordado, también está bien. Si hace un trabajo lo suficientemente bueno como 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 despriorándose) cada vez que agregan algo nuevo, lo que en gran parte pone Una parada a los cambios frívolos.

Hay dos riesgos dignos de mención aquí. Lo primero es que el cliente puede asustarse, si no ha entendido la agilidad por adelantado. Parece que está tomando todo el riesgo. Sólo la experiencia demuestra que él no es realmente.

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

Pero si usted, como compañía, lo explica bien, todos son ganadores.

    
respondido por el pdr 06.03.2012 - 21:14
4

Algunos people intentaron < a href="http://agilediary.wordpress.com/2009/01/16/scrum-and-agile-in-a-fixed-price-project-environment/"> to give soluciones para usar Agility en proyectos de precio fijo en el pasado. Personalmente creo que generalmente no es posible.

Scrum, en particular, es adecuado para compañías de software de producto , y se usa menos en compañías de servicios.

Puede usar cierta agilidad en sus proyectos, como iteraciones, paradas diarias, Burndorn, etc., pero le puedo asegurar que si ofrece cierta cantidad de cosas por un precio determinado y entrega menos de lo que había en El contrato, tendrás un problema.

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

    
respondido por el user2567 06.03.2012 - 21:23
3

Esto no está realmente relacionado con la programación Agile o el modelo que uses. Trabajando como freelance, utilizo una combinación de Waterfall y V-model, pero sigo teniendo el mismo problema: ¿qué sucede si el cliente desea cambiar algo durante el diseño detallado? ¿Qué pasa si 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 un Oferta por cada pequeño cambio en los requisitos. No es un desastre: si está bien organizado, puede que no sea demasiado difícil satisfacer 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 por un 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 dice que el producto costará $ 3,000 a su cliente y finalmente le cuesta $ 3,157.24, el cliente todavía 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, estime el costo que tiene y compárelo con el costo real y el estado. Si casi ha terminado el producto y el costo real es $ 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 general de forma conjunta.

respondido por el Arseni Mourzenko 06.03.2012 - 21:16
3

Agile y 'Escribir una oferta' parecen una antítesis :) - esta última no es ingeniería de software productiva: D

Bien, ahora que tenemos la broma fuera del camino, volvamos a lo real.

"¿Cómo funciona en Agile ?" - El contrato complica las cosas pero espero aclararlo. Agile se basa en el principio de "confianza" y "trabajo conjunto", lo que significa que el cliente puede cambiar lo que sea, cuando quiera y entiende que puede costar un poco más o, si no es intrusivo, tal vez sin costo adicional. / p>

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

Ahora, cuando se produce un cambio de diseño, se agiliza con la estimación y la planificación para: reúne a tu equipo y les pides la estimación de 'punto de historia' w.r.t. La complejidad de factorizar los cambios. Debido a una estimación de velocidad, puede multiplicarlos y dar una estimación de programación. Debería ser relativamente fácil descartar el costo por punto de historia si conoce al equipo y sus salarios relativos (por favor, no haga un promedio del salario de TODOS, sucumbirá a la falla de los promedios).

¿Necesita volver al cliente con las finanzas? NO. No necesariamente. Tendrás al cliente priorizando estos e insertándolos en el lugar correcto en el registro. Ahora que sabe el tamaño de la acumulación (debería, si no lo sabe ya) y sobre la base de las finanzas (costo por punto de historia), usted sabe qué requisitos de baja prioridad no pueden ser posibles con el presupuesto. MOSTRARles el atraso repriorizado con la estimación de características factibles según $$ contrato. Luego, deje que ELLOS decidan si están dispuestos a pagar más para obtener más dinero si / cuando lleguen allí. Si lo quieren gratis ... tomas una posición y les dices que costará más.

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

Espero que esto ayude!

    
respondido por el PhD 06.03.2012 - 21:18
1

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

  1. Incorpore algunos gastos generales para los cambios (por ejemplo, 10%)
  2. Evalúe y facture por separado los grandes cambios o agregue y facture los cambios más allá del costo incorporado (un buen ejemplo, aunque no programado, es el trabajo de diseño, donde a menudo el costo inicial incluye, por ejemplo, 3 revisiones y posteriores revisiones o tal vez los redos totales son 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 he participado con). Entonces, empiezas 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 solicitó inicialmente).

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

    
respondido por el Shauna 06.03.2012 - 21:17

Lea otras preguntas en las etiquetas