Ágil no fomenta mucho diseño inicial. Esto es bueno desde el punto de vista de la gestión de requisitos y el desarrollo de software, y permite que el proyecto se adapte a las necesidades cambiantes del negocio.
Sin embargo, ¿cómo se hace una planificación de recursos a largo plazo si realmente no sabe lo que va a construir cuando comience? Claro, tienes un modelo conceptual de lo que vas a construir, pero no tienes ningún detalle medible a partir del cual puedas calcular cuántos recursos necesitarás para completar el proyecto o cuánto costará.
¿Alguien tiene alguna sugerencia sobre cómo realizar una planificación a largo plazo en un entorno ágil?
project-management
agile
planning
Erik Funkenbusch
fuente
fuente
Respuestas:
Acabo de presionar a mi organización para que pruebe un enfoque ágil en uno de nuestros proyectos. Fue un desafío para la alta gerencia porque necesitan un presupuesto proyectado y un cronograma antes de que puedan siquiera financiar un proyecto (es una gran empresa).
Entonces, hice lo que siempre hago en esa situación, hacer una suposición educada. Observé el alcance que suponíamos que implicaría el proyecto, adiviné el tiempo de desarrollo de esos elementos, agregué un tiempo adicional para analistas de negocios, DBA, gerente de proyectos, etc., agregué algo de relleno y llamé a eso el presupuesto estimado. Tenga en cuenta que este tipo de estimación de "orden de magnitud aproximado" también se realiza en mi empresa antes de cada proyecto de cascada, por lo que no fue diferente.
Luego, cuando comenzamos el proyecto ágil, y tuvimos una idea de nuestra velocidad, proyectamos el punto final del proyecto en función de la velocidad y los puntos de historia restantes, y descubrimos que nos estamos adelantando a mi nivel superior original estimados. Pero eso está bien (y lo esperábamos).
Así que supongo que para generalizar una respuesta, depende de lo que usted quiera decir con "largo alcance", y cuando necesite estas estimaciones. Si los necesita antes de que comience el proyecto, puede usar mi método. Si los necesita durante la ejecución de un proyecto, puede usar el concepto de planificación de lanzamiento que menciona Matthew Kubicina.
Además, recomiendo el libro Agile Estimation and Planning de Mike Cohn, que ayuda a abordar este tipo de cosas.
fuente
Agile tiene un concepto de "Planificación de lanzamiento". Todo el equipo se reúne para planificar un próximo lanzamiento. Lo he hecho con hasta 2-3 meses de anticipación. Esto generalmente se hace después de que el propietario del producto ha determinado el "producto mínimo viable" y sabe exactamente qué se debe hacer para liberar el producto.
El equipo puede tomar las historias conocidas o historias épicas. Una epopeya es una gran historia o característica que aún no se ha definido completamente. Tal vez algo como "Permitir pagos internacionales". Debido a que esta historia o épica es tan general, las estimaciones serán grandes y darán cuenta de eso. El equipo puede hacer algo llamado tamaños de "camisetas" y dar a cada epopeya un "pequeño", "mediano" o "grande". Esto le da al propietario del producto una idea del tamaño de las historias en las preguntas y le permite al scrum master hacer algunas estimaciones sobre cuál será la fecha de lanzamiento real.
La clave es comenzar en algún lugar y continuar refinando los puntos o estimaciones de la historia a medida que se conozca más información.
Aquí hay un par de enlaces sobre la planificación del lanzamiento:
fuente
Pruebe la metodología Get Things Done de David Allen; Recordé un pasaje de su libro (el primero / principal sobre GTD) donde dice algo como "ser a largo plazo no significa que tengas mucho tiempo para comenzar a hacerlo".
GTD lo ayuda a pensar en términos procesables, para que pueda programar tareas reales que puede hacer o programar para hacer en un sistema propio. Esto es GTD en pocas palabras: http://lifedev.net/gtd-cheatsheet/
GTD funciona tanto para la vida como para el trabajo, y de corto a largo plazo, siempre y cuando sigas pensando en acciones y no solo en cosas que te preocupan a ti o a tu equipo. Si no tiene mucho tiempo para leer el libro, obtenga el audiolibro, realmente vale la pena.
También puedes probar Scrum (e incluso combinarlo con GTD) ... haces una lista de características, las encajonas en un mes de desarrollo y terminas con una versión funcional del producto.
Finalmente, le recomiendo que lea Rework de Jason Fried, donde hablan mucho sobre la priorización y algunas nociones informales de planificación de proyectos que son bastante útiles.
fuente
En ágil, esto se llama inspeccionar y adaptar. Usa la historia como tu guía.
Debe conocer su velocidad antes de comenzar a hacer una suposición acerca de qué tan rápido puede llegar a la meta. En otras palabras, ejecute un par de iteraciones para ver qué tan rápido se está ejecutando y luego use esa información para hacer planes.
La respuesta a su pregunta es que primero debe recopilar datos antes de intentar hacer una planificación a largo plazo.
fuente