¿Cómo se le cobra a su cliente en un proyecto usando una metodología ágil?¿Cómo cargar/presupuestar en proyectos ágiles de desarrollo de software?
por hora? Entonces se debe establecer una gran confianza antes del proyecto.
Por iteración? Habrá muchas decisiones presupuestarias, lo que puede llevar tiempo.
¿Por proyecto? ¿Cómo puede hacer eso cuando no conoce el alcance? La esencia misma de ágil es no escribir un diseño/especificación inicial grande.
Usted cobra a su cliente sobre la base de los términos definidos por su contrato que será ligeramente diferente de un contrato de oferta fija tradicional. Llamemos a eso un contrato Ágil.
Algunas opciones son discutidas por Alistair Cockburn en Agile contracts.
Otro gran recurso es 10 Contracts for your next Agile Software Project por Peter Stevens.
Mary Poppendieck también tiene excelente material sobre este tema. Consulte agilecontracts, agilecontractsworkshop, Contracts Excerpt From Lean Software Development, Lean Contracts. Más here.
Si su cliente ya ha comprado el uso de una metodología ágil, entonces tiene un marco razonable para negociar el precio por iteración. Por ejemplo, usted sabe:
Esa es mucha más evidencia sobre la cual basar las decisiones de precios que la disponible para la mayoría de los contratos de precio fijo.
Si la metodología ágil es puramente un proceso de desarrollo interno que no implique el cliente, entonces es poco probable que tenga mucho efecto en la negociación de precios entre el proveedor y el cliente. Existe un argumento que dice que un proceso que no involucra al cliente en establecer el alcance y las expectativas al menos una vez por iteración no es ágil en absoluto.
En cuanto al comentario de Mark, existe un modelo de precios muy común basado en contratos de precio fijo con un alcance definido y cronogramas optimistas. Un resultado común es que tanto el proveedor como el cliente encuentran que su optimismo inicial fue erróneo. Ambos terminan negociando desde posiciones débiles sobre las cosas que realmente les importan, y ambos terminan descontentos.
Algunas de las técnicas que funcionan bien en la gestión de este tipo de contrato son muy similares a las utilizadas en la gestión de contratos ágiles (entrega frecuente, negociación de alcance, prioridades & precio, comunicación franca, ...) la principal La diferencia es que estos no están incorporados en el acuerdo original, y el contrato puede no ser lo suficientemente flexible como para acomodarlos a todos.
Si tiene un cliente que acepte esto y comprenda el proceso de desarrollo, de hecho sería genial, y esperaría que algunas partes de una aplicación estén por debajo del presupuesto. Según nuestra experiencia y tal vez la naturaleza del mercado en el que nos encontramos, nuestros clientes solo quieren un precio y lo quieren entregado ayer. –
Mi 2c como un practicante no ágiles ... en una búsqueda para saber más ...
Si usted está haciendo un proyecto específico para un cliente, se necesita conocer el alcance del proyecto a proporcionar un costo y una escala de tiempo. El costo de producir este ámbito de trabajo es más a menudo que no parte del descubrimiento del proyecto, o le da un golpe a esto para obtener el trabajo o se le cobra por esto (explícita o implícitamente) En este caso, un costo del proyecto puede ser resuelto y acordado. En este caso, el proyecto generalmente se divide en varias etapas.
Aunque ágil puede ser iterativo y no requiere una especificación completa; un objetivo, al menos es ciertamente necesario. Debe haber alguna forma de especificación/requisito básico. Puede ser que necesite dividir el proyecto en metas más pequeñas y aplicar los costos en consecuencia.
Las iteraciones sospecho que tienen más que ver con la metodología del desarrollo, es decir, para lograr los objetivos?
Si no hay suficiente especificación para producir un costo definitivamente preciso, diría que se debe dar una "estimación" pero el trabajo debe cobrarse a una tarifa por hora, ya que supondría que habría mayores cambios en las decisiones hecho en el proyecto sobre cada iteración.
La respuesta breve es, no lo hará. Hay algunas compañías de servicios que están haciendo progresos al hacerlo, pero es un camino difícil. Su capacidad para vender la metodología y convencer al cliente de que puede entregar será alta.
Los clientes no quieren arriesgarse a pagar por una solución que nunca será entregada.
Los enfoques típicos para este problema son poner el costo "no excederá". Sin embargo, si no puede controlar el alcance, usted es el que asume todo el riesgo.
En resumen, usted está buscando clientes que se hubieran registrado para T & M (tiempo y materiales) antes de que Agile se convirtiera en la última moda (soy parte de esa moda, pero es solo una en un largo línea de procesos de desarrollo. Aspectos de la misma continuarán creciendo y una permutación de la misma tendrá un nombre diferente en unos pocos años).
que he visto que funciona bien cuando se acercó en 2 fases:
Fase 1) Inception (timeboxed)
Un período de arranque timeboxed con el cliente para el alcance del proyecto. (Un inicio intenso de un mes para un proyecto que se estima durará un año es el correcto.) Los resultados de esta fase son una acumulación completa de historias de usuarios de tamaño, una estimación del índice de flujo por par de desarrolladores y parámetros para estimar los costos del proyecto basados en el número de desarrolladores y los gastos generales de tener equipos más grandes.
El inicio proporciona una estimación de presupuesto útil que se puede rastrear a lo largo de la fase 2, una clara visión compartida tanto para el cliente como para el proveedor, más la opción de que cualquiera de las partes se vaya. Esto no es un diseño inicial, las historias tienen detalles suficientes para que un desarrollador/probador principal le asigne tamaños relativos.
Fase 2) Entrega (tiempo y materiales)
un contrato de entrega en base a tiempo y materiales, con el proyecto de presupuesto basado en los resultados de la fase inicial. La confianza acumulada en la fase 1 es vital para hacer que esto funcione.Debido a que la fase 1 proporcionó el tamaño relativo de todo el trabajo atrasado, al medir regularmente el flujo real es posible informar con facilidad y frecuencia la tasa de flujo proyectada para el resto de la acumulación con estimaciones cada vez más precisas del presupuesto y la fecha de entrega. El proveedor debe ser contratado para reportar estas estadísticas al menos cada 2 semanas, con la opción de que el cliente se vaya en cualquier momento.
Al pagar por el tiempo y los materiales, el cliente puede cambiar el alcance y la integridad de la acumulación y, por lo tanto, puede controlar el presupuesto. En primer lugar, están motivados para priorizar sus historias de mayor prioridad/mayor riesgo, y al permitirles alejarse cuando lo deseen, deberían experimentar un retorno de la inversión positivo en todo momento.
depende de la metodología que esté utilizando, supongo. – fearofawhackplanet
estoy pensando en términos generales. ¿tienes un ejemplo más detallado? –
Esta pregunta parece estar fuera de tema porque se trata de la administración de proyectos, que está fuera del alcance actual de Stack Overflow. –