Dar estimaciones para proyectos a gran escala en un entorno ágil [cerrado]

Question

Mi empresa acaba de recibir su primera investigación de proyectos de desarrollo a gran escala y me gustaría usar un proceso Agile. El cliente tiene una visión de la aplicación, pero admite abiertamente que tiene muy pocos requisitos y reconoce que tendremos que cobrar por hora. Debido a esto, casi lo he vendido con un enfoque ágil.

El problema es que él quiere una figura para presupuestar. He leído una serie de artículos que abogan por no renunciar a una estimación porque el cliente presupuestará ese número e incluso a medida que cambian los requisitos, el número en su cabeza y en los libros no.

He leído que hay varias maneras de tomar en cuenta el precio del contrato, pero casi todas (excepto una) incorporan un número inicial. Esto parece violar todo el conjunto de principios del desarrollo ágil.

Mi pregunta es, si eres una tienda Agile, ¿cómo te las arreglas para eludir este Catch-22 de desarrollo Agile?

Answer 1

Aquí está la pregunta fundamental.

¿Cuándo pensará el cliente que han terminado?

Si piensan que se terminarán en junio, entonces colocas un equipo Agile en su lugar. Eso es 4-6 personas durante 6 meses. Ese es el presupuesto. Esencialmente, haces la multiplicación por ellos. equipo * tarifa * 6 meses.

Si piensan que se terminarán en junio, pero habrá más trabajo después de eso, entonces posiblemente estés buscando 9 meses de trabajo. Nuevamente, solo estás haciendo una multiplicación que podrían hacer por sí mismos. equipo * tarifa * 9 meses.

Si piensan que usted será su equipo de desarrollo en el futuro inmediato, deles un precio que permita que el proyecto llegue a fin de año. equipo * tarifa * 12 meses.

Debido a que cada lanzamiento es una oportunidad para volver a priorizar, debe valorar cada lanzamiento como un trabajo separado basado en las cosas que hará en ese lanzamiento. Dado que es su esquema de prioridad, controlan lo que usted construye, controlan el presupuesto, fase por fase.

A menudo, su cliente realmente quiere saber cuánto costará un conjunto de características en particular. En lugar de preguntar eso, preguntan sobre el presupuesto general (lo cual es una tontería). Pase mucho tiempo en la primera versión que muestre lo que reciben y cuánto costará esa primera versión.

Eventualmente, verán la verdad fundamental.

Están comprando las funciones de la más importante a la menos importante . Si se priorizan correctamente, pueden dejar de gastar dinero en cualquier momento y tener algo útil.

Hecho es un término relativo. Algunos proyectos están " hechos " Porque no hay más dinero. Otros se hacen porque no hay más tiempo. Rara vez (al menos en el desarrollo de software) se hace un proyecto porque nos hemos quedado sin cosas que hacer.

Answer 2

Para esta situación, proporcionamos una estimación de la primera parte del trabajo, y luego permitimos que el cliente compre más sprints según sea necesario para completar el trabajo al nivel deseado.

A medida que obtenga una mayor parte del sistema desarrollado e incorpore los comentarios del cliente en los entregables del sprint, ambos tendrán una mejor idea de la cantidad de trabajo involucrado y, por lo tanto, de los costos involucrados.

Editar: Genial. Manera excelente! ¡Desde el hecho de que los ha vendido en un enfoque Agile, por cierto, es un buen momento! Es probable que pueda acercarse a ellos desde un punto de vista ágil en términos de características que se implementarán. Tal vez escuche este " Intro to Scrum " podcast Es posible que pueda venderlos porque probablemente no necesitarán tener todos los detalles que piensan que necesitan en este momento.

HTH

saludos,

Rob

Answer 3

Mira, hay un hecho central aquí. Se le pedirá que calcule el costo, el contrato para una fecha de entrega particular y que se comprometa con un conjunto completo de características entregadas.

No puedes hacer las tres cosas.

No " no deberías " o " sería prudente no " ;; Usted (para todos los propósitos prácticos) no puede. Lo que quiero decir es que la probabilidad de hacer las tres cosas con éxito es extremadamente pequeña.

La mejor respuesta es comprometerse con un costo y un cronograma, y ??con un proceso iterativo con iteraciones rápidas y comentarios regulares, y luego escribir el acuerdo para que se haga hecho unde el costo fijo y el cronograma. Es lo que se entregará. Es decir, seguirás ofreciendo nuevas funciones (y modificaciones) hasta que se acabe el tiempo y el dinero.

La verdad es que, incluso si haces te registras en los tres, lo mejor que podrás hacer es dos de cada tres. También podría ser abierto al respecto.

Answer 4

Así es como lo dijo recientemente un contratista de gobierno viejo y crujiente: "Como dicen las prostitutas, primero hay que subirlas". ""

Eso no responde a tu pregunta, pero vale la pena recordarlo. Si no van a subir las escaleras sin un número al frente (y no lo harán), tiene que darles un número.

Cualquier persona que patrocine un proyecto de software debe tener una idea de qué tipo de retorno obtendrán de su inversión, para que puedan evaluar si vale la pena o no la inversión. Un proyecto puede valer la pena si cuesta $ 1m y toma 12 meses. Puede que no valga la pena hacerlo si cuesta $ 2 millones y toma 24 meses.

La verdadera pregunta es: ¿puede hacer este proyecto dentro de un marco de tiempo y presupuesto que permita al cliente obtener un rendimiento adecuado de su inversión? Si su respuesta a esa pregunta es otra cosa que " sí, " entonces no deberían contratarte para hacer el proyecto. De lo contrario, solo están gastando dinero y tirando los dados.

Si su respuesta actual a esa pregunta es " aún no lo sabemos, " entonces no deberían contratarte para hacer el proyecto. Pero eso no significa que no deban contratarte para averiguar si vale la pena hacer el proyecto. Una buena palabra de moda para esta empresa de consultoría es el "ejercicio preliminar de alcance". & Quot;

El desarrollo ágil consiste en administrar una curva en tres dimensiones: dinero gastado, tiempo de calendario y conjunto de características. Es un hecho que si el presupuesto y el cronograma son fijos, el conjunto de características debe ser variable. No puede saber cuál será el conjunto de características finales de el , dadas esas restricciones. Pero puede saber si un conjunto de características que podrá producir dentro de esas restricciones dentro de un rango que su cliente encontrará aceptable.

Puedes saber esto, y puedes averiguarlo. Descubrirlo es algo que su empresa puede hacer y su cliente no puede. Es un servicio que puede brindarles y que deberían pagarle. Evite la tentación de hacer esto gratis y llámelo un costo de ventas. El alcance del proyecto es tan parte de los servicios profesionales como del desarrollo de software. No estás haciendo esto para cerrar una venta; está haciendo esto para ayudar a su cliente a tomar una decisión comercial que todavía no tiene suficiente información para hacer.

Pero primero debes hacer que suban las escaleras.

Answer 5

Estas respuestas son realmente geniales. No tengo mucha experiencia para compartir, pero pensé en una analogía:

El año pasado mi esposa y yo remodelamos nuestra cocina. El contratista propuso la facturación a tiempo y amp; materiales en lugar de dar una estimación, porque no sabíamos lo que descubriríamos con respecto a la plomería, daños en el subsuelo, etc. Estuvimos de acuerdo, porque estoy trabajando desde casa y estaba disponible continuamente para responder preguntas. El contratista y yo tuvimos una buena relación, de modo que cuando surgió algo, se sintió libre de llamar a la puerta de mi oficina y lo discutimos. Las decisiones se tomaron rápidamente y el trabajo se realizó de la manera que yo quería. Eso parece similar a la prioridad Agile en revisión frecuente de clientes .

En contraste, el primo de mi esposa también está remodelando su casa. Él es un médico de urgencias y no está disponible en el sitio durante la remodelación. Entonces, describió que los contratistas estaban sorprendidos de que los contratistas tomaban decisiones importantes sin consultarlo ("¿Qué? ¡No quería que la ventana de imagen estuviera bloqueada! ¡Rompa la pared y vuelva a encuadrar la ventana como estaba!"). Esto, por supuesto, es dolorosamente caro y elimina el horario del agua. Definitivamente no es ágil.

Por lo tanto, una forma de convencer a un cliente de que una vez & amp; El modo de materiales funcionará para asegurarles que hará informes de progreso frecuentes para obtener sus comentarios. Creo que esta ya es una recomendación fundamental de la mayoría de las metodologías ágiles. Para comenzar, por supuesto, esto requiere que el cliente dé su confianza al consultor.

Como recurso separado, busqué y encontré un libro sobre este tema: " Ágil Estimación y planificación " por Mike Cohn. Lea las citas de alabanza en esa página, de un impresionante conjunto de expertos de Agile.

Answer 6

En primer lugar, quiero decir que creo que es genial que le haya vendido un enfoque ágil y precios por hora. Eso es muy difícil de hacer.

Con respecto a su dilema, creo que debería presentarle una estimación aproximada de los precios y las características / alcance que incluye. Durante el proceso de desarrollo, si ve que se avecina algo importante que cambiará el alcance / costo, le dirá al cliente "detener". Esto es genial, pero entiendo que cambia el alcance original que discutimos. & Quot;

En este punto, el cliente tiene el privilegio de aceptar, ser consciente de que pagará más de lo que pensó originalmente, o detener el nuevo desarrollo por ahora. Muchos proyectos ágiles se construyen en muchas mini etapas, por lo que puede dar una estimación bastante precisa del precio / tiempo. Antes de que comience cualquier nuevo mini-stage, es importante que usted y el cliente estén pendientes de lo que viene a continuación y cuánto tiempo / costo se gastará en él.

Answer 7

Como siempre, hay calidad, funcionalidad y tiempo (= recursos) que son sus parámetros principales. Ya no estamos jugando con la calidad, por lo que solo nos quedan características y recursos. Con bastante frecuencia, puedes convencerte de que cierta cantidad de recursos alcanzará, como mínimo, cierto conjunto de características. Entonces, siempre que pueda encontrar una cantidad de recursos que ofrezca un conjunto de características plausibles, creo que esto es suficiente para bastantes clientes. La ventaja es que pueden controlar el progreso mientras están en movimiento, y siempre existe la opción de retirarse.

Answer 8

La forma en que lo he hecho es usar mi velocidad actual y estimar un rango basado en estimaciones aproximadas de complejidad (cantidad de historias). Usted actualizará esto a medida que comience a planificar la aplicación para que la estimación del rango sea cada vez mejor.

Por ejemplo, proporcione una estimación de 6mos a 2 años (si está seguro de que tomará menos tiempo que 2 años. A medida que lo desglosa en características, planifique esas características, obtendrá mejores resultados). mejores estimaciones para que después de 6mos pueda decir de manera confiable (sin ningún otro cambio), lo haremos en otros 2-3 meses (un total de 8-9 meses). Finalmente, llegará al punto en el que puede decir, Se realizará después de la próxima iteración (2 semanas a 1 mes).

Debe emparejar esto para que el cliente sepa que agregar funciones aumentará el tiempo de finalización, luego dejar que ellos decidan cómo proceder, ya sea descartar la función o aumentar el tiempo. Para cualquier proyecto dado, el alcance y el tiempo son realmente las únicas variables que puede cambiar efectivamente. La calidad y los recursos son bastante fijos. En realidad, puede agregar recursos, pero generalmente ve un aumento en el tiempo y una disminución en la calidad inicialmente, por lo que esto solo funciona si su horizonte de tiempo es largo.

Answer 9

Un enfoque que podría tomar es dar al cliente una estimación general que considere relativamente cercana. También da un porcentaje. El porcentaje será un aumento o una disminución de la asignación en el presupuesto debido a los requisitos cambiantes.

Ejemplo: estimación general de $ 10,000, pero como los requisitos son vagos y el proyecto podría cambiar de rumbo fácilmente, existe una opción de ajuste de precios de +/- 30%.

De esta manera, el cliente puede tener una idea general de lo que debe presupuestar y usted tiene cierta flexibilidad para cobrar al proyecto.

Answer 10

Este es un tema realmente difícil. Vea lo que Robert Glass tiene que decir sobre el tema en su libro " Hechos y falacias del software Ingeniería " ;. ( ¡Tenga en cuenta que Amazon tiene libros disponibles nuevos por menos de lo que están disponibles de segunda mano! [a partir del 2009-01-05 12:20 -08: 00]; también en Google books. )

Answer 11

Si ha vendido exitosamente al cliente con un enfoque ágil y con la facturación por hora, no le dé un estimado de cuánto costará completar el proyecto. . Incluso si dicen que lo quieren solo para fines presupuestarios, ¡no lo hagas! .

La razón es que cualquier estimación de costo se tratará como un compromiso definido; no importa cuántas veces diga que no, y cuántas veces el cliente diga que entienden eso, será tratado como un compromiso. Incluso si el cliente entiende, su jefe no lo hará, y aunque no podrán forzarlo legalmente a que realice la entrega por el precio que usted dijo, llegará a ser conocida como una compañía que no cumple lo que prometió. Proporcionar un presupuesto elimina toda la ventaja de ser ágil en primer lugar.

Lo que sugiero es decirles que no gastará más de esa cantidad antes del final del año financiero (o cualquier otro período de facturación en el que esté interesado su cliente). Eso debería ser suficiente para que puedan planificar financieramente sin decir de ninguna manera que el proyecto estará terminado para entonces.

Answer 12

  

Este fue mi responda a una pregunta cerrada relacionado con los puntos de la historia. Lo uso todo el tiempo para la estimación de macros.

Cuando cambié a puntos, decidí hacerlo solo si podía cumplir los dos puntos siguientes; 1) encontrar un argumento que justifique el cambio y convencerá al equipo 2) Encontrar un método fácil de usar.

Convinciendo

Me tomó mucha lectura sobre el tema, pero finalmente encontré el argumento que me convenció a mí ya mi equipo: es casi imposible encontrar dos programadores que estén de acuerdo en el tiempo que tomará una tarea, pero los mismos dos programadores casi lo harán. siempre acuerde qué tarea es la más grande cuando se muestran dos tareas diferentes.

Esta es la única habilidad que necesita para "estimar" su acumulación. Aquí utilizo la palabra "estimación", pero en esta primera etapa es más bien como ordenar el atraso de difícil a fácil.

Poner puntos en la acumulación

Este paso se realiza con la participación de todo el equipo de scrum.

Comience a colocar las historias una por una en una nueva hoja de cálculo manteniendo el siguiente orden: la historia más grande en la parte superior y la más pequeña en la parte inferior. Haz eso hasta que todas las historias estén en la lista.

Ahora es el momento de poner puntos en esas historias. Personalmente uso la escala de planificación de póquer (1 / 2,1,2,3,5,8,13,20,40,100), así que esto es lo que usaré para este ejemplo. En la parte inferior de esa lista probablemente tendrás micro tareas (cosas que demoran 4 horas o menos). Dar a cada micro tareas el valor de 1/2. Luego continúe en la lista asignando el valor 1 (siguiente en la escala) a las historias hasta que quede claro que una historia es mucho más grande (2 en lugar de 1, por lo tanto, dos veces más grande). Ahora, utilizando el valor '2', continúe en la lista hasta que encuentre una historia que claramente debería tener un 3 en lugar de un 2. Continúe este proceso hasta el tope de la lista.

NOTA: intente mantener la gran mayoría de los puntos entre 1 y 13. La primera vez puede que tenga un montón de historias importantes (20, 40 y 100) y tendrá que romperlos en trozos más pequeños o igual a 13.

Eso es todo por los puntos y la acumulación original. Si alguna vez tienes una historia nueva, compárala con esa lista para ver dónde encaja (proceso más grande / más pequeño) y dale el valor de sus vecinos.

Velocity & amp; Estimación (planificación macro)

Para estimar cuánto tiempo le tomará pasar por ese retraso, haga la primera planificación del sprint. Haz el total de los puntos adjuntos a las historias que los equipos seleccionaron y ¡VOILA !, esa es tu primera medida de velocidad. Luego, puede dividir el total de puntos en el registro atrasado por esa velocidad, para saber cuántos sprints se necesitarán.

Esa velocidad cambiará y se establecerá en los primeros 2-3 sprints, por lo que siempre es bueno vigilar ese valor