Compte tenu d'un changement constant, à quel point une période de planification est-elle trop courte?

Le changement n'est pas rare, le changement des exigences, le changement des spécifications, le changement du flux de travail. J'ai accepté qu'il y aura du changement, mais je me demande: sachant que le changement va se produire, à quel point une période de planification est-elle trop courte? (Les justifications sont encouragées)

• Une itération (2-4 semaines)?
• Une semaine?
• Une période de 2-3 jours?
• Un jour?
• 1/2 journée?

Supposons que l'entreprise «planifie» 1 [intervalle de temps (ci-dessus)] à l'avance par rapport au courant afin que tout plan ressemble à:

« [ce matin / jour / semaine / etc.] vous travaillerez sur ce et [cet après - midi / demain / semaine prochaine / etc.] vous travaillerez sur ce .

Supposons également que les changements de mise au point / direction se produiront de manière cohérente tous les seconde à troisième intervalle de temps.

Je suis un Scrum Practitionner donc je vais vous suggérer de l'utiliser.

1. Définissez la durée de votre itération. J'aime deux semaines d'itération dans les startups et un mois dans les grands projets d'entreprise
2. Au début d'une itération, sélectionnez parmi les fonctionnalités que vous développerez à partir du backlog de produit. Personne n'a le droit de modifier le plan d'itération, pas même le chef de produit.
3. Les modifications se produisent dans le backlog du produit, pas dans le plan d'itération. Par conséquent, vous n'êtes jamais affecté dans votre travail.

Plus de détails sur Scrum

La planification a souvent tendance à faire perdre la vue d'ensemble dans tous les détails, et vous finissez par faire tourner vos roues. C'est un énorme risque.

Je préfère utiliser XP (ou Scrum) qui dit que vous devez planifier une fois au début de chaque itération, ce que je trouve le plus efficace lorsqu'elles durent de 1 à 2 semaines.

Cela dit, il y a des choses très intéressantes dans Kanban qui encouragent la planification en cas de besoin, bien que je pense personnellement que Kanban est mieux adapté aux situations de maintenance et de support plutôt qu'au démarrage du développement à partir de zéro.

Je décompose les choses comme ceci:

1. Tout projet important / développement d'application - 1 semaine.
2. De simples améliorations ponctuelles sont jetées dans une liste, classées par ordre de priorité, et chacune est traitée en demi-journée ou en journée complète.
3. Les corrections de bogues sont généralement prioritaires et passent par un processus similaire à celui du n ° 2, mais peuvent parfois être corrigées beaucoup plus rapidement.

Le facteur clé ici est de savoir combien de planification pouvez-vous réellement faire pour une tâche donnée? Démarrage d'un tout nouveau site Web qui fait yadda, yadda, yadda, il y a plus de planification à l'avance que de corriger un bug. Qui planifie les bugs à l'avance? Le responsable du département découvre qu'il a oublié quelque chose et en a besoin pour le rapport de fin de trimestre, vous devez mettre les choses de côté et y travailler.

Une itération hebdomadaire peut avoir 10 heures ou 50 heures. Tout dépend de combien d'autres choses sont immédiates. Je pense qu'il est beaucoup plus facile pour la direction de comprendre les contraintes de temps lorsque vous demandez, si vous devez mettre un projet de côté pour faire un petit ajout? Je suis agréablement surpris quand ils identifient ce petit changement comme inutile et je devrais continuer à travailler sur le site Web yadda-yadda-yadda.