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

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

A medida que obtenga más del sistema desarrollado e incorpore los comentarios del cliente en los entregables de sprint, ambos obtendrán una mejor sensación de la cantidad de trabajo involucrado y, por lo tanto, los costos involucrados.

Editar: Genial. ¡Excelente! Por el hecho de que los has vendido en un Enfoque ágil, POR cierto buena!, lo más probable es que usted será capaz de seel al acercarse desde un punto de vista ágil en términos de características a implementar. Tal vez escuchar este podcast "Intro to Scrum". Es posible que pueda venderlos en el hecho de que probablemente no necesitarán tener todas las campanas y silbatos que piensan que necesitan en este momento.

HTH

Salud,

Rob

Mira, hay un hecho central aquí. Se le pedirá que estime el costo, contrate una fecha de entrega en particular y se comprometa a un conjunto completo de funciones entregadas.

No puedes hacer las tres.

No "no deberías" o "sería prudente no hacerlo"; tú (para todos los propósitos prácticos) no puedes.

La mejor respuesta es comprometerse con un costo y un cronograma, y con una iterativa procese con iteraciones rápidas y comentarios regulares, y luego escriba el acuerdo para que lo que se haga unde el costo fijo y el calendario es lo que se entregará. Es decir, sigue entregando nuevas características (y modificaciones) hasta que se agote el tiempo y el dinero.

La verdad es que, incluso si haces suscribirte a los tres, lo mejor que podrás hacer es dos de cada tres de todos modos. Bien podría ser abierto al respecto.

Así es como lo expresó recientemente un viejo contratista gubernamental que conozco: "Como dicen las prostitutas, primero tienes que subirlas."

Eso no responde a tu pregunta, pero vale la pena recordarlo. Si no suben sin número por adelantado (y no lo harán), tienes que darles un número.

Cualquiera que patrocine un proyecto de software necesita tener una idea de qué tipo de retorno van a obtener en su inversión, para que puedan evaluar si el vale la pena invertir. Un proyecto puede valer la pena si cuesta $1 millón y tarda 12 meses. Puede que no valga la pena hacerlo si cuesta 2 2 millones y tarda 24 meses.

La verdadera pregunta es: ¿puede hacer este proyecto dentro de un marco de tiempo y presupuesto que haga posible que el cliente obtenga un retorno adecuado de su inversión? Si tu respuesta a esa pregunta es cualquier cosa menos "sí", entonces no deberían contratarte para hacer el proyecto. De lo contrario, sólo están gastando dinero y rodando dados.

Si tu 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 el proyecto vale la pena o no. Una buena palabra de moda de la consultora para esto es " ejercicio preliminar de alcance."

El desarrollo ágil se trata de 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 calendario son fijos, el conjunto de características debe ser variable. No puede saber qué será el conjunto final de características, dadas esas restricciones. Pero puedesaber si un conjunto de características que podrá producir dentro de esas restricciones cae dentro de un rango que su cliente encontrará aceptable.

Puedes saber esto, y puedes averiguarlo. Encontrar que es algo que su empresa puede hacer y su cliente no puede. Es un servicio que puede proporcionar para ellos y que deben pagar para ti. Evite la tentación de hacer esto de forma gratuita y llámelo un costo de ventas. El alcance del proyecto es una parte tan importante de los servicios profesionales como el desarrollo de software. Usted no está haciendo esto para cerrar una venta; usted está haciendo esto para ayudar a su cliente a tomar una decisión de negocio que todavía no tienen suficiente información para hacer.

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

Por el contrario, el primo de mi esposa también está remodelando su casa. Es médico de urgencias y no está disponible en el lugar durante la remodelación. Así que describió ser sorprendido regularmente por los contratistas que toman decisiones importantes sin consultarlo ("¿Qué? ¡No quería que bloquearan esa ventana! ¡Arranca la pared y vuelve a enmarcar la ventana como estaba!"). Esto es, por supuesto, dolorosamente caro y sopla el horario fuera del agua. Definitivamente no Ágil.

Así que una forma de convencer a un cliente de que un modo de tiempo y materiales funcionará puede ser asegurarle que hará informes de progreso frecuentes para obtener sus comentarios. Creo que esto ya es una recomendación central de la mayoría de las metodologías ágiles. Para empezar, por supuesto, esto requiere el cliente da su confianza al consultor.

Como recurso separado, busqué y encontré un libro sobre este tema: " Agile Estimating and Planning" de Mike Cohn. Lea las citas de elogios en esa página, de un impresionante conjunto de expertos ágiles.

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

Con respecto a su dilema, creo que debe presentarle una estimación aproximada de precios y las características / alcance que incluye. Durante el proceso de desarrollo, si ves algo importante que va a cambiar el alcance / costo, le dices al cliente "stop-esto es genial, pero entiende que cambia el alcance original que discutir."

En este punto el cliente tiene el privilegio de estar de acuerdo, siendo consciente de que pagará más de lo que originalmente pensó, o detener el nuevo desarrollo por ahora. Muchos proyectos ágiles se construyen en muchas mini-etapas , para las cuales puede dar una estimación bastante precisa de precio / tiempo. Antes de que comience cualquier nueva mini-etapa, es importante que usted y el cliente estén de acuerdo en lo que sigue y cuánto tiempo / costo se invertirá en ello.

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 quedan funciones y recursos. Con bastante frecuencia, puede salirse con la suya convenciendo de que una cierta cantidad de recursos alcanzará, como mínimo, un determinado conjunto de características. Así que mientras 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 progresa mientras está en movimiento, y siempre existe la opción de retroceder.

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

Por ejemplo, dé una estimación de 6mos a 2 años (si está seguro de que tomará menos de 2 años. A medida que lo desglosas en características, luego planificas esas características, se te ocurren mejores y mejores estimaciones para que después de 6mos pueda decir de manera confiable (sin ningún otro cambio), terminaremos en otros 2-3 meses (total de 8-9 meses). Eventualmente, llegas al punto donde puedes decir, terminaremos después de la siguiente iteración (2 semanas a 1 mes).

Debe emparejar esto con hacerle saber al cliente que la adición de características aumentará el tiempo hasta la finalización, luego déjele decidir cómo proceder, ya sea eliminar la característica o aumentar el tiempo. Para cualquier proyecto, alcance y tiempo son realmente las únicas variables que se pueden cambiar de manera efectiva. 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 temporal es largo.

Un enfoque que podría tomar es darle al cliente una estimación general que usted cree que es relativamente cercana. También dar un porcentaje. El porcentaje será un aumento o una disminución de la habilitación de créditos en el presupuesto debido a los cambios en las necesidades.

Ejemplo: Estimación general de $10,000 pero dado que los requisitos son vagos y el proyecto podría cambiar de curso fácilmente, hay una opción de ajuste de precio de +/- 30%.

De esta manera el cliente puede tener una idea general de lo que debe presupuestar y usted tiene cierta flexibilidad en la carga al proyecto.

Este es un tema muy difícil. Vea lo que Robert Glass tiene que decir sobre el tema en su libro "Facts and Falacies of Software Engineering". (Tenga en cuenta que Amazon tiene libros disponibles nuevos por menos de lo que están disponibles de segunda mano! [a partir de 2009-01-05 12:20 -08:00]; también en Google books.)

Si ha vendido con éxito al cliente un enfoque Ágil, y la facturación por hora, no les dé una estimación de cuánto costará completar el proyecto!. Incluso si dicen que lo quieren solo con fines presupuestarios, ¡no lo hagan!.

La razón es que cualquier estimación del costo llegará a ser tratado como un compromiso definido; no importa cuántas veces usted diga que no lo es, y cuántas veces el cliente dice que lo entiende, será tratado como un compromiso. Incluso si el cliente lo entiende, su jefe no lo hará, y aunque no podrá obligarlo legalmente a entregar por el precio que dijo, llegará a ser conocido como una empresa que no entrega lo que prometió. Proporcionar una estimación elimina toda la ventaja de ser ágil en primer lugar.

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

Esta fue mi respuesta a una pregunta cerrada relacionada con los puntos de la historia. Uso esto todo el tiempo para la estimación macro.

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

Convincente

Me llevó mucho leer sobre el tema, pero finalmente encontré el argumento de que me convenció a mí y a 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 siempre estarán de acuerdo en qué tarea es la más grande cuando se muestran dos tareas diferentes.

Esta es la única habilidad que necesitas para 'estimar' tu backlog. Aquí uso la palabra 'estimación', pero en esta etapa temprana es más como ordenar el backlog de difícil a fácil.

Poniendo puntos en el Backlog

Este paso está hecho con la participación de todo el equipo de scrum.

Comience a soltar 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. 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 Poker (1/2,1,2,3,5,8,13,20,40,100) así que esto es lo que voy a utilizar para este ejemplo. En la parte inferior de esa lista, probablemente tendrá micro tareas (cosas que toman 4 horas o menos para hacer). Dar a cada micro tareas el valor de 1/2. Luego continúe en la lista dando el valor 1 (siguiente en la escala) a las historias hasta que esté claro que una historia es mucho más grande (2 en lugar de 1, por lo tanto, dos veces más grande). Ahora usando 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 la parte superior de la lista.

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

Eso es todo para los puntos y el atraso original. Si alguna vez tienes una nueva historia, 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.

Velocidad y estimación (planificación macro)

Para estimar cuánto tiempo le llevará pasar por ese backlog, haga el planificación del primer sprint. Hacer el total de los puntos adjuntos a las historias que los equipos recogieron y VOILA!, esa es tu primera medida de velocidad. A continuación, puede dividir el total de puntos en el backlog por esa velocidad, para saber cuántos sprints se necesitarán.

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