Flujo de trabajo actual en nuestra empresa:
Entiendo que el dimensionamiento relativo funciona mejor que el dimensionamiento por horas y por eso me gustaría pasar a los puntos de historia. Pero, ¿cómo es posible dar una estimación de presupuesto para el cliente usando puntos de historia?
¿Cómo cumplir con el presupuesto adecuado, pero al mismo tiempo usar puntos de historia para estimar el proyecto?
Para proyectos ágiles, una fórmula básica para estimar el presupuesto es:
(totalStoryPoints / velocity * teamHoursPerSprint) + nonLaborCosts = budgetEstimate
Los resultados deben informarse como un rango estimado usando intervalos de confianza estadísticos o un método de "alto, bajo, promedio".
El "secreto" para estimar presupuestos ágiles es estimar la cantidad de iteraciones necesarias para eliminar el trabajo pendiente o alcanzar un hito de lanzamiento. Por ejemplo:
Este método brinda una imagen razonable del presupuesto planificado mientras se sigue calculando el Proyecto pendiente en puntos de la historia. Este método no se basa en conversiones de puntos ↔ horas incómodas o engañosas.
Suponga que tiene 20 historias de usuarios en su backlog y un Equipo Scrum de 6 personas, incluido el Scrum Master y el Product Owner. Cada historia se estima en 5 puntos de historia y su velocidad promedio histórica es de 10 puntos de historia por sprint.
20 historias @ 5 puntos cada una = 100 puntos de historia
100 storyPoints/promedioVelocity = 10 sprints
- costo de mano de obra por semana para equipo de 6 personas: $3,200
- costo de mano de obra por sprint para un equipo de seis personas: $6,400
- costo de mano de obra para el proyecto: $6,400 por sprint * 10 sprints = $64,000
- Servidores y estaciones de trabajo.
- Licencias de software.
- Tarifas de servicio mensuales por la duración planificada del proyecto.
- Etcétera.
$104,000
- Extremo bajo razonable (80%):
$104k * 0.80 = $83,200- Presupuesto calculado real (100%):
$104k * 1.00 = $104,000- Gama alta aceptable (120%):
$104k * 1.20 = $124,800
En su plan de proyecto, informa su presupuesto calculado como el pronóstico del presupuesto (también conocido como su valor de planificación), el extremo inferior como su "objetivo de extensión" y el extremo superior como el punto más allá del cual la administración considerará que el proyecto está fuera de tolerancia. Esto brinda una imagen razonable de los costos planificados mientras se sigue calculando el Proyecto pendiente y el cronograma de entrega a partir de los puntos de la historia.
Comenzaré diciendo que hacer Scrum en un entorno de consultoría es un verdadero desafío. Con Scrum, buscamos continuamente comentarios del propietario del producto y las partes interesadas y ajustamos nuestra acumulación de trabajo para reflejarlo. Esto hace que sea difícil dar una estimación fija por adelantado. El objetivo de Scrum es lograr el máximo valor comercial entregando lo que el cliente necesita. Esto no siempre es compatible con un alcance fijo.
Habiendo dicho eso, es posible usar puntos de historia para proporcionar una estimación del proyecto. Lo que hace es hacer que el equipo haga estimaciones de puntos de historia en todas las historias en el alcance del proyecto. Luego, usa la velocidad del equipo para adivinar cuántos sprints se necesitarán para completar el proyecto. Conociendo el costo por sprint, puede calcular el costo del proyecto.
Tenga en cuenta que es poco probable que obtenga una estimación precisa del costo del proyecto para todos los proyectos, excepto para los más cortos. En el desarrollo existen incógnitas técnicas y de requisitos que generan errores de estimación que aumentan cuanto más largo es el proyecto que se está estimando. A esto lo llamamos el 'cono de incertidumbre', donde nuestra certeza de la precisión de una estimación disminuye con la duración del proyecto.
Un equipo Scrum a menudo revisará continuamente su estimación para un proyecto. A medida que se completa cada sprint, el equipo puede volver a calcular su velocidad y revisar el trabajo pendiente (y las estimaciones del trabajo pendiente). Con este enfoque, sus estimaciones mejoran con el tiempo, pero esto no sirve de nada si se ve obligado a dar una estimación antes de que el trabajo haya comenzado.
He estado usando puntos de la historia durante muchos años y considero que son un enfoque de estimación mucho más efectivo que usar el tiempo absoluto. Dicho esto, necesitas conocer sus limitaciones. El hecho de que exista una acumulación no significa que un equipo lo revise e incluso con una precisión moderada lo dimensione.
Un equipo debe tener suficiente información sobre una historia para relacionarla con algo que hayan hecho en el pasado. El simple hecho de tener una descripción de una línea de una historia (como administrador del Sistema XI debe poder...) normalmente no proporciona suficiente información al equipo para dimensionar la historia a menos que sea algo muy simple.
La preparación y el dimensionamiento de la cartera de pedidos es un proceso continuo en el que el equipo, el propietario del producto, las partes interesadas, etc. discuten los qué y cómo de la historia. Las epopeyas y las historias se dividen y/o generan nuevas historias, mientras que los tamaños se refinan aún más. El punto es intentar llegar a una estimación a nivel de proyecto utilizando el tamaño de todas las historias por adelantado, es solo una planificación inicial grande apenas velada.
Es mucho mejor mirar el historial de su proyecto y encontrar 2 o 3 proyectos que sean de naturaleza similar para darle un rango de tiempo y costo. Luego determine si el valor que está tratando de lograr con el proyecto está justificado en términos de costos. Puede validar aún más esa decisión haciendo una implementación limitada de algunas piezas clave en un puñado de sprints. Eso le brinda información real para salir frente a la especulación. La información confiable no es gratuita. No obtiene información más confiable al hacer una estimación más detallada. Obtiene información más confiable al comenzar la implementación, lo que por supuesto cuesta dinero. Puede continuar con ese enfoque y, si en algún momento determina que ya no vale la pena la inversión restante, cancela el proyecto. Demasiadas empresas asumen que una vez que comienza un proyecto, debe completarse. Matar proyectos cuando ya no brindan el valor necesario es algo saludable y debe considerarse una victoria, no un fracaso. La mayoría de las empresas asumen que pueden planificar la mayor parte del riesgo antes de gastar parte de la inversión. ¿Adivina qué? Eso simplemente no es la realidad. Es como pedirle a un corredor de bolsa que garantice un ROI en una acción antes de comprarla.
Entiendo el dilema con el mundo de la consultoría y es un problema fundamental con la forma en que la mayoría de las empresas hacen negocios con proveedores/consultores. Nuevamente, quieren una garantía sobre algo que es extremadamente difícil de predecir con exactitud y precisión, pero usted se ve obligado a hacerlo porque es la única forma de obtener el negocio. Es disfuncional porque la empresa que licita el negocio piensa que ha limitado su riesgo al obligar al postor a fijar el precio y el alcance. La realidad es que el riesgo no ha sido verdaderamente mitigado. La empresa que gana la oferta sabe con frecuencia que la ha ofertado por debajo de lo esperado y tratará de compensarla en el camino a través de una variedad de métodos diferentes. El punto es que el proyecto está preparado para el fracaso desde el principio. Ninguno de los lados normalmente gana en esa situación.
Ewan