Estoy realmente confundido sobre cómo se presupuestan los proyectos ágiles por costo y esfuerzo antes de que comience el proyecto. Porque las historias de usuario nunca se discuten y estiman por completo como una práctica en ágil. Entonces, si hacemos una conjetura y llegamos a una serie de puntos de la historia (por parte del gerente de producto durante el inicio) que, por definición, estarán lejos de ser precisos, ¿cómo se finaliza el presupuesto del cine en función de esa suposición descabellada?
Cualquier idea ayudaría...
Bueno, la respuesta fácil y probablemente no del todo útil es que la agilidad requiere un cambio en la forma en que se planifica el negocio. Financias equipos, no proyectos.
Eso no es del todo útil, así que déjame intentar cerrar la brecha.
El éxito de un proyecto ágil se reduce a tener un buen backlog y equipos dedicados.
Si no dedica tiempo a planificar una cartera de pedidos, nunca obtendrá una estimación precisa y, como resultado, no obtendrá un buen presupuesto. Eso no quiere decir que deba descomponer todo el trabajo pendiente en las tareas que lo componen. Necesitas descomponer lo suficiente para obtener la respuesta que necesitas. La clave crítica son los criterios de aceptación. Podría tener una epopeya masiva de "Proporcionar servicios de spa en el hotel" y si tiene criterios de aceptación para "Masajes, tratamientos faciales, baños de barro, sala de espera zen", entonces puede estimar y, por lo tanto, presupuestar.
Un equipo bien formado y en funcionamiento podrá tomar un alto nivel de trabajo pendiente y generar una estimación razonable del tiempo de entrega. Más importante aún, un equipo bien formado que trabaje con un buen propietario del producto (o propietario del producto) puede priorizar las historias de los usuarios. ¿Porque es esto importante?
Al usar Scrum la fecha es fija. Esto le permite presupuestar el esfuerzo. Lo que entonces se vuelve fluido es el alcance. Debido a que priorizó el trabajo pendiente correctamente, si algo no se construye, será uno de los elementos menos importantes (y bien puede caer en el 60% de las funciones que nunca se usan o se usan solo en raras ocasiones).
¿Es esto perfecto? No. Por otra parte, un estudio de Harvard Business Review mostró que uno de cada seis proyectos de TI tiene un sobrecosto del 200 % o más. No se excederá del presupuesto con un proyecto ágil. Es posible que simplemente no envíe todo lo que planeó y cuando profundice, puede encontrar que está completamente bien.
Hay un buen artículo de HBR sobre presupuestos ágiles aquí: https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate
Una forma de pensarlo es usar la curva clásica de "precisión versus esfuerzo". Claro, puede dedicar mucho tiempo a la planificación por adelantado, pero rápidamente obtiene rendimientos decrecientes en la precisión y definitivamente perderá el tiempo planificando cosas que no llegarán al producto final (colocándose muy lejos en la curva).
O puede adoptar una mentalidad ágil y planificar solo lo suficiente para comenzar, incluso si eso significa un rango de presupuesto o un alcance flexible como mencionó Joel (estar más abajo en la curva pero aceptando que podría subir o bajar en algún %).
En mi práctica, los proyectos ágiles se configuran y presupuestan de la misma manera que los regulares. Tenemos un caso de negocio / alcance de alto nivel, en base a esto hacemos una estimación preliminar del costo y el cronograma, lo comparamos con nuestras experiencias pasadas (o métricas de proyectos anteriores) y lo documentamos en el acta de constitución del proyecto.
La mayoría de los métodos ágiles no cubren todo el ciclo de vida del proyecto, por lo que los proyectos de alto nivel (por ejemplo, desde el nivel de alta dirección) que son ágiles son iguales a los proyectos que se ejecutan de una manera más tradicional. Por supuesto, por razones de gestión de expectativas, es bueno comunicar la metodología (para que entiendan e incluso anticipen los cambios de alcance).
Puede haber una diferencia significativa al estimar proyectos ágiles: por lo general, es una configuración muy mala si solo tiene tiempo / presupuesto para los requisitos obligatorios, por lo tanto, incluya algunos opcionales en el alcance inicial, o tenga un gran (30-40% o aún más) reserva para características adicionales que pueden venir más adelante. De esta manera, su equipo (propietario del producto, etc.) podrá manejar los cambios de alcance de manera flexible.
Debe tener la guía fiduciaria al asignar un presupuesto para un flujo de valor, una vez que llegue al nivel de flujo de valor, puede estimar las historias y dimensionar las características y capacidades
firooz