Considerando un cambio constante, ¿qué tan corto de un período de planificación es demasiado corto?

El cambio no es infrecuente, cambio en los requisitos, cambio en las especificaciones, cambio en el flujo de trabajo. He aceptado que habrá cambios, pero me pregunto: sabiendo que el cambio va a suceder, ¿qué tan corto de un período de planificación es demasiado corto? (Se alientan las justificaciones)

• ¿Una iteración (2-4 semanas)?
• ¿Una semana?
• ¿Un período de 2-3 días?
• ¿Un día?
• 1/2 al día?

Suponga que la compañía 'planea' 1 [intervalo de tiempo (desde arriba)] antes de la actual para que cualquier plan suene como:

"[esta mañana / hoy / esta semana / etc.] trabajarás en esto y [esta tarde / mañana / la próxima semana / etc.] estarás trabajando en eso .

También suponga que los cambios en el enfoque / dirección ocurrirán de manera consistente cada segundo o tercer intervalo de tiempo.

Soy un practicante de Scrum, así que te sugeriré que lo uses.

1. Defina la duración de su iteración. Me gustan las iteraciones de dos semanas en startups y un mes en proyectos de grandes empresas.
2. Al comienzo de una iteración, seleccione entre las características que desarrollará a partir de la cartera de pedidos del producto. Nadie tiene derecho a cambiar el plan de iteración, ni siquiera el gerente de producto.
3. Los cambios se producen en la cartera de productos, no en el plan de iteración. Por lo tanto, nunca se ve afectado en su trabajo.

Más detalles sobre Scrum

La planificación a menudo tiende a hacer que la imagen más grande se pierda en todos los detalles, y terminas girando las ruedas. Ese es un gran riesgo.

Prefiero usar XP (o Scrum) que dice que debes planear una vez al comienzo de cada iteración, lo que me parece más efectivo cuando tienen 1-2 semanas de duración.

Dicho esto, hay algunas cosas muy interesantes en Kanban que alientan la planificación para que suceda cuando sea necesario, aunque personalmente creo que Kanban es más adecuado para situaciones de mantenimiento y soporte en lugar de comenzar el desarrollo desde cero.

Desgloso las cosas así:

1. Cualquier proyecto significativo / desarrollo de aplicaciones - 1 semana.
2. Las mejoras simples y únicas se incluyen en una lista, se priorizan y cada una se aborda en períodos de medio día a día completo.
3. Las correcciones de errores generalmente tienen prioridad y pasan por un proceso similar al # 2, pero a veces se pueden solucionar mucho más rápido.

El factor clave aquí es ¿cuánta planificación puedes hacer realmente para una tarea determinada? Al iniciar un sitio web completamente nuevo que hace yadda, yadda, yadda, hay más planificación por adelantado que corregir un error. ¿Quién planea los errores de antemano? El gerente del departamento descubre que olvidaron algo y lo necesitan para los informes de fin de trimestre, hay que dejar las cosas a un lado y trabajar en ello.

Una iteración semanal puede tener 10 horas o 50. Todo depende de cuánto otras cosas sean inmediatas. Creo que es mucho más fácil para la gerencia comprender las limitaciones de tiempo cuando pregunta, si debe dejar de lado un proyecto para hacer una pequeña adición. Estoy gratamente sorprendido cuando identifican ese pequeño cambio como innecesario y debo seguir trabajando en el sitio web yadda-yadda-yadda.