Voir la source de PI Planning (SAFe)

[[Category: Agilité à grande échelle]]
[[Category: SAFe]]
Auteur : &copy; 2010-2022 Scaled Agile, Inc.<br />
Source : [https://www.scaledagileframework.com/pi-planning/ PI Planning - Scaled Agile Framework]<br />
Date : 10/02/2021 (dernière mise à jour)<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 12/09/2022<br />
----
Traduction :<br />
<br />
[[Fichier:PI Planning 5.1 nav icon.png|left|border|link=https://www.scaledagileframework.com/]] ''Les futures étapes du développement d'un produit ne peuvent être prédéterminées. Attribuez la planification et le contrôle à ceux qui peuvent comprendre et réagir vis-à-vis des résultats obtenus.''<br/>
<br/>
- Michael Kennedy, ''Product Development for the Lean Enterprise''<br/>
<br/>
''Il n'y a pas de magie dans SAFe... sauf peut-être pour le PI Planning.<br/>
<br/>
- Auteurs
__TOC__
==PI Planning==
Le Program Increment (PI) Planning est un événement en face-à-face basé sur la cadence qui sert de battement de cœur à l'Agile Release Train (ART), alignant toutes les équipes de l'ART sur une mission et une vision communes.<br/>
<br/>
Le PI Planning est un élément essentiel de SAFe : si vous ne le faites pas, vous ne pratiquez pas SAFe.

==Description détaillée==
Le Manifeste Agile déclare : "La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face." SAFe fait passer ce principe au niveau supérieur avec le PI Planning.<br/>
<br/>
Lorsque c'est possible, cela implique une colocalisation physique, et ces événements de PI Planning à grande échelle ont aujourd'hui lieu dans de nombreuses entreprises du monde entier. Ils ont clairement démontré un réel retour sur investissement financier, sans parler des avantages indirects qui se présentent lorsque l'équipe des équipes Agile crée une cohésion sociale qui est personnellement et collectivement gratifiante.<br/>
<br/>
Néanmoins, il n'est pas toujours pratique pour la totalité de [https://www.scaledagileframework.com/agile-release-train/ l'Agile Release Train (ART)] de se trouver dans un même lieu, et à notre époque, la COVID-19 a créé une situation où ce n'est pas une option. Bien que la planification physique en face à face ait ses avantages, la "règle" non écrite de SAFe est "les personnes qui font le travail planifient le travail". Lorsque la présence physique n'est pas possible, la planification en temps réel, de manière simultanée, virtuelle et en face à face a maintenant prouvé son efficacité. En effet, de nombreux ART ont réussi à créer une situation hybride où plusieurs équipes se réunissent à distance, comme le montre la figure 1 ci-dessous.<br/><br/>
L'article consacré au sujet [https://www.scaledagileframework.com/distributed-pi-planning/ Distributed PI Planning with SAFe], fournit des conseils et des éléments supplémentaires pour gérer avec succès ces scénarios.
[[Fichier:F1-Large-scale-PI-Planning.png|border|center|link=]]
<div style="text-align: center;">'''Figure 1. PI Planning en face à face. Des équipes distantes planifient en même temps grâce à la visioconférence.'''</div>
<br/>
Le PI Planning a un ordre du jour type qui comprend une présentation du contexte et de la [https://www.scaledagileframework.com/vision/ vision] de l'entreprise, suivie de réunions de planification d'équipe - où les équipes créent leurs plans d'[https://www.scaledagileframework.com/iterations/ itération] et leurs objectifs pour le [https://www.scaledagileframework.com/program-increment/ Program Increment (PI)] à venir. Facilité par le [https://www.scaledagileframework.com/release-train-engineer/ Release Train Engineer (RTE)], cet événement inclut tous les membres de l'ART et se déroule pendant [https://www.scaledagileframework.com/innovation-and-planning-iteration/ l'itération Innovation et Planning (IP)]. La tenue de l'événement pendant l'itération IP évite d'affecter le calendrier ou la capacité des autres itérations du PI. Le PI Planning se déroule sur deux jours, bien que ce délai soit souvent prolongé pour permettre une planification sur plusieurs fuseaux horaires.

===Bénéfices du PI Planning pour l'entreprise===
Le PI Planning offre de nombreux bénéfices pour l'entreprise, notamment :
* L'établissement d'une communication en face à face entre tous les membres de l'équipe et toutes les parties prenantes
* La création du réseau social sur lequel repose l'ART
* L'alignement du développement sur les objectifs de l'entreprise avec le contexte métier, la vision et [https://www.scaledagileframework.com/pi-objectives/ les objectifs du PI Program et de l'équipe]
* L'identification des dépendances et la promotion de la collaboration entre les équipes transversales et entre ART 
* L'opportunité d'une architecture "juste comme il faut" et des orientations d'une [https://www.scaledagileframework.com/lean-ux/ Expérience Utilisateur (UX) Lean]
* L'adaptation de la demande à la capacité et l'élimination de l'excès de travail en cours (WIP)
* Une prise de décision rapide

===Entrées et sorties du PI Planning===
Les données d'entrée du PI planning sont les suivantes : 
* Le contexte de l'entreprise (voir "préparation du contenu" ci-dessous)
* La feuille de route et la vision
* Les 10 principales [https://www.scaledagileframework.com/features-and-capabilities/ features] du Program Backlog
Un événement PI Planning réussi génère deux principales sorties :
* '''Engagement sur les objectifs du PI''' - Un ensemble d'objectifs [https://www.scaledagileframework.com/pi-objectives/ SMART] créés par chaque équipe avec la valeur métier attribuée par les Business Owners. 
* '''Le Program board''' - qui fait apparaître les dates de livraison des nouvelles features, les dépendances entre les équipes et les [https://www.scaledagileframework.com/milestones/ jalons] importants.

===Préparation===
Le PI Planning est un événement important qui nécessite préparation, coordination et communication. Il est facilité par le RTE et les participants à l'événement sont notamment les [https://www.scaledagileframework.com/business-owners/ Business Owners], le [https://www.scaledagileframework.com/product-management/ Product Management], les [https://www.scaledagileframework.com/agile-teams/ Équipes Agiles], les [https://www.scaledagileframework.com/solution-architect-engineering/ Architectes/Ingénieurs Système et Solution], l'[https://www.scaledagileframework.com/system-team/ Équipe Système] et d'autres parties prenantes, qui doivent tous être informés à l'avance pour être bien préparés. La participation active des Business Owners à cet événement constitue un [https://www.scaledagileframework.com/guardrails/ Garde-fou] important sur les dépenses budgétaires.<br/>
<br/>
Pour que l'événement soit réussi, une préparation est nécessaire dans trois domaines majeurs : 
* '''Préparation organisationnelle''' - Alignement stratégique et mise en place d'équipes et de trains
* '''Préparation du contenu''' - Préparation du Management et du Développement
* '''Préparation logistique''' - Considérations pour le bon déroulement de l'événement
Vous trouverez ci-dessous les grandes lignes de la Check-list de préparation de l'ART. (La check-list complète est fournie dans le [https://www.scaledagile.com/spc-resources/?_ga=2.59156453.912400902.1663504170-1082990040.1662205503 SAFe PI Planning Toolkit], disponible pour les [https://www.scaledagileframework.com/safe-program-consultant/ SPC]).
====Préparation organisationnelle====
Avant le PI Planning, il doit y avoir un alignement de la stratégie entre les participants, les parties prenantes et les Business Owners. Les rôles critiques sont attribués. Pour anticiper cette question, les organisateurs doivent toutefois tenir compte des éléments suivants : 
* '''Périmètre et contexte de la planification''' - Le périmètre (produit, système, domaine technologique) du processus de planification est-il compris ? Sait-on quelles équipes doivent effectuer la planification ensemble ? 
* '''Alignement de l'entreprise'''  - Y a-t-il un accord raisonnable sur les priorités entre les Business Owners ?
* '''Équipes agiles''' - Avons-nous des équipes agiles ? Y a-t-il des membres d'équipe dédiés et un [https://www.scaledagileframework.com/scrum-master/ Scrum Master] et un [https://www.scaledagileframework.com/product-owner/ Product Owner] identifiés pour chaque équipe ?

====Préparation du contenu====
Il est tout aussi important de s'assurer que la vision et le contexte soient clairs et que les bonnes parties prenantes puissent participer. Par conséquent, Le PI Planing doit inclure : 
* '''Briefing de la direction''' - Un briefing qui définit le contexte actuel de l'entreprise
* '''Briefing(s) sur la vision du produit''' - Des briefings préparés par le Product Management, y compris les 10 principales features du [https://www.scaledagileframework.com/program-and-solution-backlogs/ Program Backlog]
* '''Briefing sur la vision de l'architecture''' - Une présentation faite par le CTO, l'[https://www.scaledagileframework.com/enterprise-architect/ Enterprise Architect] ou le System Architect pour communiquer les nouveaux [https://www.scaledagileframework.com/enablers/ Enablers], features et [https://www.scaledagileframework.com/nonfunctional-requirements/ Nonfunctional Requirements] (NFRs).

====Préparation logistique====
Préparer un événement pour accueillir un grand nombre de participants n'est pas une mince affaire. Pour une planification dans des locaux physiques, cela peut inclure la sécurisation et la préparation de l'espace physique. Pour les participants à distance, ou pour un PI Planning entièrement distribué, cela inclut également l'investissement dans l'infrastructure technique nécessaire. Les points à prendre en compte sont les suivants :
* '''Lieux''' - Chaque lieu de planification doit être préparé à l'avance
* '''Technologie et outillage''' - Accès en temps réel aux informations et à l'outillage pour prendre en charge la planification distribuée ou les participants à distance
* '''Canaux de communication''' - Les canaux audio, vidéo et de présentation doivent être disponibles.

===Agenda type===
L'événement suit un ordre du jour similaire à celui de la figure 2. La description de chaque élément suit. Pour obtenir des conseils sur l'adaptation de cet ordre du jour afin de prendre en charge la planification sur plusieurs fuseaux horaires, reportez-vous à la page consacrée à ce sujet avancé, [https://www.scaledagileframework.com/distributed-pi-planning/ PI Planning distribué avec SAFe].
[[Fichier:F2-Standard-two-day-agenda.png|border|center|link=]]
<div style="text-align: center;">'''Figure 2. Agenda type du PI Planning sur deux jours'''</div>
=====Agenda du 1er jour=====
* '''Contexte de l'entreprise''' - Un Business Owner ou un dirigeant décrit l'état actuel de l'entreprise, partage la [[Portfolio Vision (SAFe)|Vision du Portefeuille]] et présente une perspective sur l'efficacité des solutions existantes à répondre aux besoins actuels des clients. 
* '''Vision du produit/de la solution''' - Le Product Management présente la vision actuelle (généralement représentée par les 10 prochaines features à venir) et insiste sur les changements par rapport au précédent événement de PI Planning, ainsi que sur les prochains [https://www.scaledagileframework.com/milestones/ jalons]. 
* '''Vision de l'architecture et pratiques de développement''' - L'architecte/ingénieur système présente la vision de l'architecture. En outre, un responsable du développement peut présenter les changements apportés aux pratiques de développement, tels que l'automatisation des tests, [https://www.scaledagileframework.com/devops/ DevOps], l'[https://www.scaledagileframework.com/continuous-integration/ Intégration Continue] et le [https://www.scaledagileframework.com/continuous-deployment Déploiement Continu], qui sont mis en oeuvre dans le PI à venir. 
* '''Contexte de la planification et déjeuner''' - Le RTE présente le processus de planification et les résultats attendus. 
* '''Séances d'équipe n°1''' - Lors de ces séances, les équipes estiment leur capacité pour chaque [https://www.scaledagileframework.com/iterations/ itération] et identifient les éléments du backlog dont elles auront probablement besoin pour réaliser les fonctionnalités. Chaque équipe crée ses propositions de planification, visibles par tous, itération par itération.
Au cours de ce processus, les équipes identifient les risques et les dépendances et ébauchent leurs objectifs initiaux pour le PI de l'équipe. Les objectifs du PI comprennent généralement des "objectifs non engagés", qui sont des buts intégrés dans la planification (par exemple, les histoires qui ont été définies et intégrées pour ces objectifs), mais qui ne sont pas engagés par l'équipe en raison de trop d'inconnues ou de risques. Les objectifs non engagés ne sont ''pas'' des choses supplémentaires à faire au cas où il y aurait du temps. Au contraire, ils augmentent la fiabilité de la planification et alertent rapidement le management sur les objectifs que l'ART pourrait ne pas être en mesure de réaliser. Les équipes ajoutent également les features et les dépendances associées au Program board, comme le montre la figure 3.<br/>
<br/>
[[Fichier:F3-Program-Board.png|border|center|link=]]
<div style="text-align: center;">'''Figure 3. Program board montrant les features et les dépendances'''</div>
* '''Revue de l'ébauche de planification''' - Au cours de la revue de l'ébauche de planification, les équipes présentent les principaux résultats de la planification, notamment la capacité et la charge, les objectifs proposés pour le PI, les risques potentiels et les dépendances. Les Business Owners, le Product Management et d'autres équipes et parties prenantes passent en revue et apportent leur contribution.
* '''Revue de management et résolution des problèmes''' - Il est probable que les ébauches de planification présentent des points problématiques tels que le périmètre, les contraintes en termes de personnel et de ressources, et les dépendances. Au cours de la réunion de résolution des problèmes, le management peut négocier des changements de périmètre et résoudre d'autres problèmes en acceptant divers ajustements de planification. Le RTE facilite et fait en sorte que les principales parties prenantes restent ensemble aussi longtemps que nécessaire pour prendre les décisions requises pour atteindre des objectifs réalisables.
Dans les [https://www.scaledagileframework.com/solution-train/ Trains de Solution] multi-ART, un événement similaire peut être organisé après le premier jour de planification pour résoudre les problèmes inter-ART qui ont été soulevés. Par ailleurs, les RTE des trains concernés peuvent discuter entre eux pour soulever des questions qui sont ensuite résolues lors de la réunion de revue de management et de résolution de problèmes spécifique à chaque ART. Le [https://www.scaledagileframework.com/solution-train-engineer/ Solution Train Engineer (STE)] aide à faciliter et à résoudre les problèmes entre les ART.

=====Agenda du 2ème jour=====
* '''Ajustements de la planification''' - Le lendemain, l'événement commence par la présentation par le management des changements apportés au périmètre de planification, aux personnes et aux ressources. 
* '''Séances d'équipe n°2''' - Les équipes poursuivent la planification sur la base de leur agenda de la veille, en apportant les ajustements nécessaires. Elles finalisent leurs objectifs pour le PI, auxquels les Business Owners attribuent une valeur métier, comme le montre la figure 4.
[[Fichier:PI-Objectives F04-v2.png|border|center|link=]]
<div style="text-align: center;">'''Figure 4. Fiche d'objectifs du PI d'une équipe avec valeur métier attribuée'''</div>
* '''Revue finale de la planification et déjeuner''' - Au cours de cette session, toutes les équipes présentent leurs planifications au groupe. À la fin du créneau alloué à chaque équipe, celle-ci expose ses risques et ses obstacles et transmet les risques au RTE pour qu'il les utilise plus tard dans l'exercice de ROAMing. L'équipe demande ensuite aux Business Owners si la planification est acceptable. Si la planification est acceptée, l'équipe porte sa feuille d'objectifs de PI d'équipe à l'avant de la salle afin que tout le monde puisse voir les objectifs agrégés se déployer en temps réel. Si les Business Owners ont des réserves, les équipes ont la possibilité d'ajuster la planification selon les besoins pour résoudre les problèmes identifiés. L'équipe présente ensuite sa version révisée de la planification.
* '''Risques liés au programme''' - Au cours de la planification, les équipes ont identifié les risques et les obstacles liés au programme qui pourraient avoir une incidence sur leur capacité à atteindre leurs objectifs. Ceux-ci sont résolus dans un contexte de management plus large, devant l'ensemble du train. Un par un, les risques sont discutés et traités avec franchise et transparence, puis classés dans l'une des catégories suivantes : 
** '''Résolu''' - Les équipes conviennent que le risque n'est plus une préoccupation. 
** '''Pris en charge''' - Une personne du train prend en charge le risque car il ne peut être résolu pendant la planification du PI. 
** '''Accepté''' - Certains risques ne sont que des faits ou des problèmes potentiels qui doivent être compris et acceptés. 
** '''Atténué''' - Les équipes définissent un plan pour réduire l'impact du risque.
* '''Vote de confiance''' - Une fois que les risques du programme ont été traités, les équipes votent leur confiance dans l'atteinte des objectifs de leur PI.
Chaque équipe procède à un vote "avec les cinq doigts de la main". Si la moyenne est de trois doigts ou plus, le management doit accepter l'engagement. Si la moyenne est inférieure à trois, l'équipe modifie la planification. Toute personne votant avec deux doigts ou moins doit avoir l'occasion d'exprimer ses préoccupations. Cela peut compléter la liste des risques, nécessiter une nouvelle planification ou simplement être informatif. Une fois que chaque équipe a voté, le processus est répété pour l'ensemble de l'ART, chacun exprimant sa confiance dans la planification collective, comme illustré à la figure 5.
[[Fichier:F5-Confidence-Vote-for-an-ART.png|border|center|link=]]
<div style="text-align: center;">'''Figure 5. Vote de confiance pour un ART'''</div>
* '''Modification de la planification''' - Si nécessaire, les équipes modifient leurs planifications jusqu'à ce qu'un niveau de confiance élevé puisse être atteint. À cette occasion, l'alignement et l'engagement sont plus importants que le respect des délais. 
* '''Rétrospective de la planification et marche en avant''' - Pour finir, le RTE mène une brève rétrospective de l'événement de planification du PI afin de recenser ce qui a bien marché, ce qui n'a pas marché et ce qui pourra être amélioré la prochaine fois, comme le montre la figure 6.
[[Fichier:F6-Planning-Retrospective-1.jpg|border|center|link=]]
<div style="text-align: center;">'''Figure 6. Rétrospective du PI Planning'''</div>
* En général, il s'ensuit une discussion sur les prochaines étapes, ainsi que des instructions finales pour les équipes. Cela peut inclure :
** Nettoyer les salles utilisées pour la planification. 
** Capturer les objectifs et les stories du PI de l'équipe dans un outil de gestion de projet Agile.
** Examiner les calendriers des événements de l'équipe et de l'ART. 
** Déterminer les lieux et les horaires de l'[https://www.scaledagileframework.com/iteration-planning/ Iteration Planning] et des stand-up quotidiens (DSU).
Une fois l'événement de planification terminé, le RTE et les autres parties prenantes de l'ART résument les objectifs du PI de chacune des équipes en l'ensemble des objectifs du PI du programme (Figure 7) et les utilisent pour communiquer en externe et pour suivre la progression vers les objectifs.<br/>
<br/>
Le Product Management utilise les objectifs du PI du programme pour mettre à jour la feuille de route et va améliorer les prévisions pour les deux prochains PI, sur la base de ce qui vient d'être appris.<br/>
<br/>
Le program board est souvent utilisé pendant le [https://www.scaledagileframework.com/program-increment/ Scrum of Scrums] pour suivre les dépendances. Il peut, ou non, être mis à jour (manuellement) une fois la planification terminée. Cela dépend de l'outil de gestion de projet Agile en place et des besoins de l'ART.<br/>
<br/>
Les équipes quittent l'événement de planification du PI avec un iteration backlog pré-rempli pour le PI à venir. Elles rapportent les objectifs du PI, les plans d'itération et les risques de leur équipe dans leur espace de travail habituel. Les risques du programme sont confiés au RTE, qui s'assure que les personnes responsables de la prise en charge ou de l'atténuation d'un risque ont saisi l'information et gèrent effectivement le risque.<br/>
<br/>
Plus important encore, l'ART passe à l'exécution du PI, en suivant la progression et en s'adaptant si nécessaire aux changements qui surviennent à mesure que de nouvelles informations émergent. L'exécution du PI commence par la planification de la première itération par toutes les équipes, qui utilisent leurs planifications du PI comme point de départ. Il s'agit d'une nouvelle entrée pour les processus de planification des itérations qui suivent. Étant donné que les planifications d'itération créées au cours de la planification du PI n'ont pas pris en compte les critères d'acceptation détaillés au niveau de la story, il est probable que des ajustements devront être apportés aux planifications de la première itération et des itérations suivantes.<br/>
<br/>
[[Fichier:PI-Planning F07 web.jpg|border|center|link=]]
<div style="text-align: center;">'''Figure 7. Objectifs du PI du programme'''</div>

===PI Planning du Solution Train===
Cet article se concentre sur les activités de planification d'un seul ART. Cependant, les grands [https://www.scaledagileframework.com/development-value-streams/ Value Streams] peuvent contenir plusieurs ARTs et de multiples fournisseurs. Dans ce cas, le Solution Train assure la coordination à l'aide d'un événement de [https://www.scaledagileframework.com/pre-and-post-pi-planning/ Pre-PI Planning], qui définit le contexte et fournit les entrées pour les événements de PI Planning de chaque ART. Un événement de [https://www.scaledagileframework.com/pre-and-post-pi-planning/ Post-PI planning] suit le PI Planning de l'ART et est utilisé pour intégrer les résultats de la planification des ART qui contribuent à la solution.
[[Fichier:PI Planning F08 WEB-2.png|border|center|link=]]
<div style="text-align: center;">'''Figure 8. Pre et Post-PI Planning</div>
L'article sur l'[https://www.scaledagileframework.com/innovation-and-planning-iteration/ itération d'innovation et de planification] fournit un exemple de calendrier permettant de tenir compte des événements Pre- et Post-PI Planning.

==En savoir plus==
[1] Leffingwell, Dean. ''Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.'' Addison-Wesley, 2011.<br/>
[2] Kennedy, Michael. ''Product Development for the Lean Enterprise.'' Oaklea Press, 2003.

==Autres ressources==
[https://www.scaledagileframework.com/posters/ Télécharger les posters]