software - metodologia agile project management
¿Cómo cobrar/presupuesto en proyectos de desarrollo de software ágil? (5)
¿Cómo cobra a su cliente en un proyecto utilizando una metodología ágil?
¿Por hora? Entonces se debe establecer una gran confianza antes del proyecto.
¿Por iteración? Habrá muchas decisiones presupuestarias, que pueden llevar tiempo.
¿Por proyecto? ¿Cómo puedes hacer eso cuando no sabes el alcance? La esencia misma de ágil es no escribir un gran diseño / especificación inicial.
La respuesta corta es que no lo harás. Hay algunas empresas de servicios que están haciendo progresos, pero es un camino difícil. Su capacidad para vender la metodología y convencer al cliente que puede entregar será alta.
Los clientes no quieren arriesgarse a pagar por una solución que nunca se entregará.
Los enfoques típicos de este problema son poner "no excederá" el costo. Sin embargo, si no puede controlar el alcance, es usted quien asume todos los riesgos.
En resumen, está buscando clientes que se hayan suscrito a los contratos de T&M (tiempo y materiales) antes de que Agile se convirtiera en la última moda (soy parte de esa moda, pero es solo uno en una larga línea de procesos de desarrollo). De ello seguirá creciendo y alguna permutación tendrá un nombre diferente en unos pocos años).
Lo he visto funcionar bien cuando se aborda en 2 fases:
Fase 1) Incepción (caja de tiempo)
Un período de inicio de caja de tiempo con el cliente para abarcar el proyecto. (Un inicio intenso de un mes para un proyecto que se estima que durará un año es correcto). Los resultados de esta fase son un atraso total de historias de usuarios de gran tamaño, una estimación del caudal por par de desarrollo y parámetros para estimar los costos del proyecto según el Número de desarrolladores y gastos generales de tener equipos más grandes.
El inicio proporciona una estimación de presupuesto útil que se puede realizar un seguimiento a lo largo de la fase 2, una visión clara y compartida tanto para el cliente como para el proveedor, además de la opción de que cualquiera de los dos se aleje. Este no es un diseño inicial, las historias tienen el detalle suficiente para que un desarrollador / probador principal pueda asignar tamaños relativos.
Fase 2) Entrega (tiempo y materiales)
Un contrato de entrega basado en tiempo y materiales, con estimaciones de presupuesto basadas 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 acumulado, al medir regularmente el flujo real, es posible informar fácil y frecuentemente la tasa de flujo proyectada para el resto del trabajo acumulado con estimaciones de presupuesto y fecha de entrega cada vez más precisas. El proveedor debe ser contratado para reportar estas estadísticas al menos cada 2 semanas, con la opción de que el cliente se retire en cualquier momento.
Al pagar por tiempo y materiales, el cliente es libre de cambiar el alcance y la prioridad de la cartera de pedidos y, por lo tanto, controla el presupuesto. Están obligados a priorizar sus historias de mayor prioridad / mayor riesgo, y al permitirles alejarse cuando lo deseen, deben experimentar un retorno de la inversión positivo en todo momento.
Mi 2c como practicante no ágil ... en una búsqueda para saber más ...
Si está realizando un proyecto específico para un cliente, deberá conocer el alcance del proyecto para proporcionar un costo y una escala de tiempo. El costo de producir este alcance de trabajo es más a menudo que no forma parte del descubrimiento del proyecto, ya sea que tome un golpe en esto para obtener el trabajo o le cobre esto (explícita o implícitamente) En este caso, el costo de un proyecto puede ser trabajado 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; Una meta, al menos ciertamente se requiere. Debe haber alguna forma de especificación / requisito básico. Puede ser que necesite dividir el proyecto en objetivos más pequeños y aplicar los costos en consecuencia.
¿Las iteraciones que sospecho tienen más que ver con la metodología de desarrollo, es decir, para lograr los objetivos?
Si no hay suficientes especificaciones para producir un costo definitivamente preciso, yo diría que se debe dar una "estimación" pero el trabajo se debe cobrar a una tarifa por hora, ya que supondría que habría mayores cambios en las decisiones tomadas sobre el proyecto. sobre cada iteración.
Si su cliente ya ha aceptado el uso de una metodología ágil, entonces tiene un marco razonable para negociar el precio por iteración. Por ejemplo, usted sabe:
- Cuánto durará la iteración.
- Cuántas personas se comprometerán a trabajar en la iteración (y sus tarifas).
- Un alcance aproximado de trabajo.
- Un proceso de entrega y aceptación.
Eso es mucha más evidencia en la que basar las decisiones de fijación 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 involucra al cliente, 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 para establecer el alcance y las expectativas al menos una vez por iteración no es en absoluto ágil.
En cuanto al comentario de Mark, hay un modelo de precios muy común basado en contratos de precio fijo con un alcance definido y horarios optimistas. Un resultado común es que tanto el proveedor como el cliente encuentran que su optimismo inicial se ha extraviado. Ambos terminan negociando desde posiciones débiles sobre las cosas que realmente les importan, y ambos terminan siendo infelices.
Algunas de las técnicas que funcionan bien en la gestión de este tipo de contrato son muy similares a las que se utilizan en la gestión de contratos ágiles (entregas frecuentes, comercio de caballos en el ámbito, prioridades y precios, comunicación franca, ...) la principal diferencia es que estas no están incorporados en el acuerdo original, y el contrato puede no ser lo suficientemente flexible como para dar cabida a todos ellos.
Usted cobra a su cliente en base a los términos definidos por su contrato que serán ligeramente diferentes de un contrato de oferta fija tradicional. Llamemos a eso un contrato ágil.
Algunas opciones son discutidas por Alistair Cockburn en los contratos Agile .
Otro gran recurso son los 10 contratos para su próximo proyecto de software ágil por Peter Stevens.
Mary Poppendieck también tiene un gran material sobre este tema. Consulte agilecontracts , agilecontractsworkshop , Contratos Extracto de Lean Software Development , Lean Contracts . Más here .