Le jeu de planification

Le jeu de planification de XP repose sur un principe simple : L'entreprise décide quoi construire. Les développeurs décident comment le construire.

Cette séparation est essentielle :

• L'entreprise comprend la valeur, la priorité et le calendrier. Elle sait quelles fonctionnalités comptent pour les clients et quand elles sont nécessaires.
• Les développeurs comprennent l'effort, la complexité et les contraintes techniques. Ils savent ce qui est difficile et ce qui est facile.

Ni l'un ni l'autre ne peut faire le travail de l'autre. L'entreprise ne peut pas estimer l'effort technique. Les développeurs ne peuvent pas décider de la priorité commerciale. Le jeu de planification les réunit avec des rôles clairs.

L'entreprise choisit :

• Quelles fonctionnalités construire
• Dans quel ordre les construire
• Quand livrer

Les développeurs fournissent :

• Des estimations pour chaque fonctionnalité
• Des options techniques et des compromis
• Des évaluations de risque

La planification de livraison répond à : Qu'est-ce qui sera dans la prochaine livraison et quand sera-t-elle livrée?

XP dit que vous pouvez fixer deux de ces trois variables :

• Portée : Quelles fonctionnalités sont incluses
• Échéancier : Quand la livraison est effectuée
• Ressources : Qui travaille dessus

Vous ne pouvez pas fixer les trois. Quelque chose doit être flexible.

Livraison à date fixe : « Nous livrons le 1er mars. Combien pouvons-nous accomplir? » La portée est négociable.

Livraison à portée fixe : « Nous avons besoin de ces fonctionnalités. Quand pouvons-nous les livrer? » La date est négociable.

Le processus du jeu de planification :

1. L'entreprise liste les fonctionnalités souhaitées par ordre de priorité
2. Les développeurs estiment chaque fonctionnalité
3. En fonction de la vélocité, calculez combien de fonctionnalités correspondent à la date (ou combien de temps pour compléter la portée)
4. L'entreprise ajuste les priorités si nécessaire
5. Engagez-vous sur un plan, mais attendez-vous à replanifier

Replanifiez régulièrement. Au fur et à mesure que vous en apprenez davantage, mettez à jour le plan de livraison. XP ne suppose pas que le plan initial est sacré.

La planification d'itération est plus détaillée. Elle se produit au début de chaque itération (généralement hebdomadaire ou bihebdomadaire).

Le processus :

1. L'entreprise présente les récits de priorité la plus élevée pour l'itération
2. Les développeurs divisent les récits en tâches (blocs de 2 à 4 heures)
3. Les développeurs s'inscrivent pour des tâches en fonction de l'intérêt et des compétences
4. L'équipe s'engage sur ce qu'elle complétera cette itération

Règles clés :

• Seule l'entreprise établit la priorité
• Seuls les développeurs estiment et s'engagent
• Ne vous surengagez pas (laissez du mou pour l'imprévu)
• Incluez le travail technique (infrastructure, refactorisation) dans le plan

Pendant l'itération :

• Suivez les progrès de manière visible (tableau kanban, burndown)
• Si hors trajectoire, signalez-le immédiatement
• N'ajoutez pas de portée en mi-itération (protégez la concentration)
• Si en avance, tirez le prochain récit

La planification d'itération est plus légère que la planification de livraison. Les récits sont déjà estimés. L'accent est mis sur la division en tâches et l'engagement sur des quantités réalistes.

Les plans changent. XP s'y attend et intègre l'adaptation.

Quand ajuster :

• Les estimations étaient erronées (le récit était plus gros que prévu)
• Les priorités ont changé (le client a découvert de nouvelles exigences)
• La capacité de l'équipe a changé (maladie, roulement)
• Les dépendances externes ont échoué (API pas prête)

Comment ajuster :

1. Faites remonter le problème immédiatement (transparence)
2. Quantifiez l'impact (nous avons 2 récits de retard)
3. Proposez des options (réduire la portée, prolonger ou réduire la qualité—mais jamais la qualité)
4. L'entreprise décide (elle possède la priorité)

Ce qui ne change jamais : La qualité. XP n'échange pas la qualité contre la portée ou l'échéancier. Si vous êtes en retard, vous livrez moins—pas de manière plus bâclée.

Le jeu de planification suppose un ajustement continu. Le plan initial est un point de départ, pas un engagement envers un résultat exact. Comme le dit Kent Beck : « Le but de la planification est la planification, pas le plan. »

Le jeu de planification nécessite un client—quelqu'un qui représente les priorités commerciales.

Cela pourrait être :

• L'utilisateur final réel (idéal mais rare)
• Un propriétaire de produit (terminologie Scrum)
• Un gestionnaire de produit
• Un analyste d'affaires

Le client doit :

• Être disponible pour répondre aux questions (idéalement quotidiennement)
• Prendre des décisions de priorité rapidement
• Accepter les compromis lorsque les choses changent
• Fournir des critères d'acceptation pour les récits

Le « client sur place » de XP signifiait à l'origine quelqu'un physiquement présent avec l'équipe. Dans les équipes distribuées modernes, « sur place » pourrait signifier « sur Slack » ou « dans la mêlée quotidienne ». La clé est la disponibilité, pas l'emplacement physique.

Sans client, la planification échoue. Les développeurs devinent la priorité. La portée s'étend parce que personne ne décide ce qui est exclu. L'équipe construit la mauvaise chose.