project-management - proyecto - metodologías agiles
Dando estimaciones para proyectos a gran escala en un entorno ágil (12)
Mi empresa acaba de recibir su primera consulta de proyecto de desarrollo a gran escala y me gustaría utilizar un proceso Agile. El cliente tiene una visión para la aplicación, pero admite abiertamente tener 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 cifra para presupuestar. He leído una serie de artículos que abogan bastante en contra de renunciar a una estimación porque el cliente presupuestará para ese número e incluso cuando los requisitos cambien, el número en su cabeza y en los libros no.
He leído que hay varias formas de tener en cuenta los precios en el contrato, pero casi todos (salvo uno) incorporan un número inicial. Esto parece violar todo el conjunto de principios de desarrollo Ágil.
Entonces, mi pregunta es, si usted es una tienda Agile, ¿cómo se las arregla para eludir este Catch-22 de desarrollo Ágil?
Antes que nada, quiero decir que creo que es genial que le hayas vendido con un enfoque ágil y con precios por hora. Eso es muy difícil de hacer.
Con respecto a su dilema, creo que debe presentarle una estimación de precios aproximada y las características / alcance que incluye. Durante el proceso de desarrollo, si ve surgir algo importante que cambiará el alcance / costo, le dirá al cliente "detenerse - esto es genial, pero entiendo que cambia el alcance original que discutimos".
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 de detener el nuevo desarrollo por el momento. En muchos mini-stages se crean muchos proyectos ágiles, por lo que puede proporcionar una estimación bastante precisa del precio / tiempo. Antes de que comience una nueva mini-etapa, es importante que usted y el cliente estén de acuerdo sobre lo que sucederá a continuación y cuánto tiempo / costo se gastará en ello.
Aquí está la pregunta fundamental.
¿Cuándo creerá el cliente que ya terminaron?
Si piensan que estarán listos para junio, entonces pones en marcha un equipo Ágil. Eso es 4-6 personas por 6 meses. Ese es el presupuesto. Esencialmente, haces la multiplicación para ellos. equipo * tasa * 6 meses.
Si creen que en su mayoría estarán listos para junio, pero habrá más trabajo después de eso, posiblemente estén considerando 9 meses de trabajo. De nuevo, solo está haciendo una multiplicación que podrían hacer por sí mismos. equipo * tasa * 9 meses.
Si piensan que usted será su equipo de desarrollo en el futuro previsible, proporcióneles un precio que permita que el proyecto finalice hasta el final del año. equipo * tasa * 12 meses.
Dado que cada versión es una oportunidad para volver a priorizar, debe fijar el precio de cada versión como una tarea separada en función de las cosas que se harán en esa versión. Como es su esquema de prioridad, controlan lo que construyes, 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 el primer lanzamiento mostrando lo que obtienen y cuánto costará ese primer lanzamiento.
Eventualmente, verán la verdad fundamental.
Están comprando las características de más importante a menos importante . Si priorizan correctamente, pueden dejar de gastar dinero en cualquier momento y tener algo útil.
Listo es un término relativo. Algunos proyectos están "listos" porque no hay más dinero. Otros están hechos porque no hay más tiempo. Raramente (al menos en el desarrollo de software) es un proyecto hecho alguna vez porque nos quedamos sin cosas que hacer.
Como siempre, hay calidad, funcionalidad y tiempo (= recursos) que son sus principales parámetros. Ya no estamos jugando con la calidad, por lo que solo quedan funciones y recursos. Muy a menudo puede salirse con la suya convenciéndole de que una cierta cantidad de recursos alcanzará, como mínimo, un determinado conjunto de características. Por lo tanto, siempre que pueda encontrar una cantidad de recursos que entregue un conjunto de características plausibles, creo que esto es suficiente para bastantes clientes. Lo bueno es que pueden controlar el progreso mientras están en movimiento, y siempre existe la opción de retroceder.
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 materiales en lugar de dar una estimación, porque no sabíamos lo que descubriríamos con respecto a la fontanería, el daño al 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, así que cuando surgió algo, se sintió libre de llamar a la puerta de nuestra oficina y discutirlo. Las decisiones se tomaron rápidamente y el trabajo se hizo de la manera que yo quería. Eso parece similar a la prioridad Ágil en la revisión frecuente de los clientes .
Por el contrario, el primo de mi esposa también está remodelando su casa. Es un médico de urgencias y no está disponible en el sitio durante la remodelación. Así que describió que los contratistas le sorprendían con regularidad al tomar decisiones importantes sin consultarlo ("¿Qué? ¡No quería que la ventana de la imagen se bloqueara!) ¡Arranca la pared y vuelve a enmarcar la ventana como estaba!"). Esto es, por supuesto, extremadamente costoso y saca el calendario del agua. Definitivamente no Agile.
Así que una forma de convencer a un cliente de que un modo de tiempo y materiales funcionará puede ser asegurarle que hará frecuentes informes de progreso para obtener sus comentarios. Creo que esto ya es una recomendación básica de la mayoría de las metodologías ágiles. Para empezar, por supuesto, esto requiere que el cliente confíe en el consultor.
Como recurso separado, busqué y encontré un libro sobre este tema: " Estimación ágil y planificación " por Mike Cohn. Lea las frases de elogio en esa página, de un impresionante conjunto de expertos de Agile.
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). Debería actualizar esto mientras comienza a planear la aplicación para que la estimación de rango sea cada vez mejor.
Por ejemplo, proporcione una estimación de 6 meses a 2 años (si está seguro de que demorará menos de 2 años. A medida que la desglosa en características, planifique esas características, se obtienen mejores y mejores estimaciones, que después de 6mos puedas decir confiablemente (sin ningún otro cambio), lo haremos en otros 2-3 meses (un total de 8-9 meses). Eventualmente, llegarás al punto en el que puedes decir, estaremos hecho después de la próxima iteración (2 semanas a 1 mes).
Debe emparejar esto con informar al cliente que agregar características aumentará el tiempo hasta la finalización, luego dejar que decida cómo proceder, ya sea abandonar 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 prácticamente 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.
Mira, hay un hecho central aquí. Se le pedirá que calcule el costo, el contrato para una fecha de entrega particular y se comprometerá con un conjunto completo de funciones entregadas.
No puedes hacer los tres.
No "no deberías" o "sería sensato no hacerlo"; usted (para todos los propósitos prácticos) no puede. Con lo que quiero decir que la probabilidad de hacer con éxito los tres 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 lo que se haga sin el costo fijo y el cronograma sea 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 te suscribes a los tres, lo mejor que podrás hacer es de todos modos dos de cada tres. Bien podría ser abierto al respecto.
Un enfoque que podría tomar es darle al cliente una estimación general que usted cree que es relativamente cercana. También da un porcentaje. El porcentaje será un aumento o disminución de la asignación en el presupuesto debido a los requisitos cambiantes.
Ejemplo: estimación general de $ 10,000 pero dado que los requisitos son imprecisos y el proyecto podría cambiar de curso fácilmente, existe una opción de ajuste de precio de +/- 30%.
De esta forma, el cliente puede tener una idea general de lo que debe presupuestar y usted tiene cierta flexibilidad para cobrar al proyecto.
Así es como un viejo contratista del gobierno que conozco recientemente lo expresó: "Como dicen las prostitutas, primero tienes que llevarlas arriba".
Eso no responde su pregunta, pero vale la pena recordar. Si no van a subir sin número al frente (y no lo harán), debes darles un número.
Cualquiera que patrocine un proyecto de software necesita tener una idea de qué tipo de retorno obtendrán de su inversión, de modo que puedan evaluar si la inversión vale la pena o no. Un proyecto puede valer la pena si cuesta $ 1m y demora 12 meses. Puede que no valga la pena si cuesta $ 2 millones y lleva 24 meses.
La verdadera pregunta es: ¿se puede hacer este proyecto dentro de un marco de tiempo y un presupuesto que haga posible que el cliente obtenga un rendimiento adecuado de su inversión? Si su respuesta a esa pregunta es todo menos "sí", entonces no deberían contratarlo para hacer el proyecto. De lo contrario, solo gastan dinero y tiran los dados.
Si su respuesta actual a esa pregunta es "todavía no lo sabemos", entonces no deberían contratarlo para realizar el proyecto. Pero eso no significa que no deberían contratarte para averiguar si el proyecto vale la pena o no. Una buena palabra de moda para la firma de consultoría es "ejercicio preliminar de alcance".
El desarrollo ágil se trata de gestionar 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 final, dadas esas restricciones. Pero puede saber si un conjunto de características que podrá producir dentro de esas restricciones se encuentra dentro de un rango que su cliente considerará aceptable.
Puedes saber esto y puedes averiguarlo. Descubrirlo es algo que su empresa puede hacer y su cliente no. Es un servicio que puede proporcionarles y que deben pagar por usted. Evite la tentación de hacer esto gratis 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. No estás haciendo esto para cerrar una venta; está haciendo esto para ayudar a su cliente a tomar una decisión comercial que aún no tiene suficiente información para hacer.
Pero primero tienes que hacer que suban las escaleras.
Este es un problema realmente 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 libros de Google ) .
Para esta situación, proporcionamos una estimación del primer tramo de 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 desarrolle más el sistema e incorpore la retroalimentación del cliente en los entregas del sprint, ambos tendrán una mejor idea de la cantidad de trabajo involucrado y, por lo tanto, los costos involucrados.
Editar: Genial. ¡Muy bueno! Por el hecho de que los ha vendido en un enfoque Agile, por cierto, es probable que los convenza de abordarlos desde un punto de vista ágil en términos de las características que se implementarán. Quizás escuche este podcast de " Introducción a Scrum ". Es posible que pueda venderlos por el hecho de que probablemente no necesiten todas las características que creen que necesitan en este momento.
HTH
aclamaciones,
Robar
Si ha vendido exitosamente al cliente en un enfoque Agile, y la facturación por hora, ¡no le dé un presupuesto 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 del costo llegará a tratarse como un compromiso definitivo; no importa cuántas veces diga que no es así, y cuántas veces el cliente dice que lo entiende, será tratado como un compromiso. Incluso si el cliente entiende, su jefe no lo hará, y aunque no podrán obligarlo legalmente a entregar por el precio que ha indicado, se lo conocerá como una empresa que no cumple con lo prometido. Proporcionar una estimación elimina toda la ventaja de ser ágil en primer lugar.
Lo que sugiero es decirles que no gastará más de tal cantidad antes de que finalice el año financiero (o cualquier otro período de facturación que le interese a su cliente). Eso debería ser suficiente para que planeen financieramente sin decir en modo alguno 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 macro estimación.
Cuando cambié a puntos, lo decidí solo si podía cumplir con los dos siguientes puntos; 1) encontrar y argumentar que justifican el cambio y eso convencerá al equipo 2) Encontrar un método fácil para usarlo.
Convincente
Me llevó mucho tiempo leer sobre el tema, pero finalmente encontré el argumento que nos convenció a mí y a mi equipo: es casi imposible encontrar dos programadores que acordarán el tiempo que tomará una tarea, pero los mismos dos programadores casi siempre acordarán qué tarea es la más grande cuando se muestran dos tareas diferentes.
Esta es la única habilidad que necesita para ''estimar'' su retraso. Aquí utilizo la palabra ''estimar'', pero en esta etapa inicial es más como ordenar el retraso de lo difícil a lo fácil.
Poniendo Puntos en la Lista de Atrasos
Este paso se realiza con la participación de todo el equipo scrum.
Comience a dejar las historias una a 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 inferior. Haz eso hasta que todas las historias estén en la lista.
Ahora es el momento de poner puntos en esas historias. Personalmente utilizo la Escala de planificación de póker (1 / 2,1,2,3,5,8,13,20,40,100) así que esto es lo que usaré para este ejemplo. Al final de la lista, es probable que tengas micro tareas (cosas que tardan 4 horas o menos en hacerlo). Dé 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 quede claro que la 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 debe tener un 3 en lugar de un 2. Continúe este proceso hasta el final de la lista.
NOTA: trate de mantener la gran mayoría de los puntos entre 1 y 13. La primera vez puede tener un montón de historias importantes (20, 40 y 100) y tendrá que frenarlas en trozos más pequeños o iguales 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 o más pequeño) y dale el valor de sus vecinos.
Velocidad y Estimación (macro planificación)
Para calcular cuánto tiempo le tomará atravesar ese retraso, haga la primera planificación de sprints. Haga el total de los puntos adjuntos a las historias que eligieron los equipos y ¡VOILA !, esa es su primera medida de velocidad. A continuación, puede dividir el total de puntos en la acumulación de esa velocidad, para saber cuántos sprints se necesitarán.
Esa velocidad cambiará y se estabilizará en los primeros 2-3 sprints, así que siempre es bueno vigilar ese valor