Planning Interval : PI (SAFe)

De Wiki Agile
Aller à la navigation Aller à la recherche

Auteur : © 2010-2023 Scaled Agile, Inc.
Source : Planning Interval (PI)
Date : 07/02/2023 (dernière mise à jour)


Traducteur : Fabrice Aimetti
Date : 21/08/2023


Traduction :

Sans engagement, il n'y a que des promesses et des espoirs, mais pas de plans.


—Peter F. Drucker

Un Planning Interval (PI) est une boîte de temps cadencée dans laquelle les Agile Release Trains (ART) apportent une valeur continue aux clients en accord avec les Objectifs du PI.

Les PI durent généralement de 8 à 12 semaines. Le modèle le plus courant pour un PI est de 4 itérations de développement, suivies d'une itération d'Innovation et de Planification (IP). Le PI est pour un ART ce qu'une itération est pour les Équipes Agiles. Il s'agit d'une boîte de temps fixe pour planifier, construire, valider, fournir de la valeur et obtenir un retour d'information rapide.

Au cours du PI, les Équipes Agiles utilisent la cadence et la synchronisation pour combiner le travail de plusieurs équipes en un ou plusieurs incréments livrables. Les équipes individuelles peuvent également produire de la valeur de manière indépendante, en fonction du contexte. La cadence et la synchronisation du PI permettent à l'ART de :

  • Planifier le prochain incrément de travail de l'ART
  • Limiter le travail en cours (WIP)
  • Résumer la valeur qui mérite d'être communiquée pour obtenir un feedback
  • Assurer la cohérence des rétrospectives de l'ART

En raison de sa large portée, le PI fournit une boîte de temps appropriée pour réfléchir au Portefeuille et établir une feuille de route.

Description détaillée

SAFe divise le calendrier de développement en une série d'itérations au sein d'un PI. La vue d'ensemble illustre comment un PI débute par l'événement du PI Planning (fr), suivi de quatre itérations d'exécution et se termine par une itération IP (Figure 1).


Figure 1. Boîte de temps classique pour un PI.


Ce modèle est indicatif et arbitraire, et il n'existe pas de règle fixe concernant le nombre d'itérations dans une IP. Toutefois, l'expérience a montré qu'une durée de PI comprise entre 8 et 12 semaines donne les meilleurs résultats, avec une préférence pour les durées les plus courtes. Les organisations qui adoptent le Lean Portfolio Management (LPM) trouvent souvent avantageux de faire coïncider le calendrier des événements de la Revue du Portefeuille Stratégique et de la Budgétisation Participative afin d'améliorer l'alignement de la stratégie sur l'exécution. (Veuillez lire la partie sur les événements dans l'article sur les compétences LPM pour plus d'informations).

Développer en cadence

Les PI fournissent le rythme de développement pour que les trains et les assets qu'ils construisent puissent être développés de manière itérative et incrémentale. L'expression "développer en cadence" désigne un ensemble coordonné de pratiques qui soutiennent les équipes agiles en proposant une succession fiable d'événements et d'activités selon un calendrier régulier et prévisible. Cependant, la cadence de planification est souvent différente de la cadence de livraison. Cette approche aide les entreprises centrées sur le client à créer un flux de valeur continu pour leurs clients.

L'entreprise détermine le calendrier des versions en fonction des besoins du marché et des clients et de la motivation de l'organisation à fournir de la valeur. Certaines entreprises publient fréquemment des versions pendant le PI, tandis que d'autres peuvent être contraintes par la conformité, les dépendances des fournisseurs ou d'autres exigences de l'entreprise et du marché, ce qui conduit à des versions moins fréquentes. Découpler les événements et les activités de développement qui soutiennent la création de valeur de la manière et du moment où cette valeur est livrée favorise encore plus l'Agilité de l'entreprise/du métier.

Les événements de l'ART pilotent le développement

Lors de l'exécution d'un ART, une double séquence d'événements Plan-Do-Check-Adjust (PDCA) crée un système en boucle fermée qui maintient le train sur les rails, comme l'illustre la figure 2. La boucle extérieure représente le cycle PDCA de l'ART pour le PI, tandis que la boucle intérieure représente le cycle PDCA d'une Équipe Agile pour une itération. Dans cet exemple, l'équipe utilise Scrum pour la boucle intérieure. La ligne diagonale (PI Start) montre qu'une fois que l'ART a terminé le PI Planning, les équipes à bord du train commencent la boucle PDCA interne.


Figure 2. Les événements ART déterminent la cadence de développement.


Les paragraphes suivants décrivent chaque événement ART. L'article sur SAFe Scrum offre des conseils pour les itérations présentées dans la figure 2, et SAFe Team Kanban décrit le cycle de la boucle interne lorsque l'on utilise cette méthode.

Planifier le PI

Chaque PI d'ART commence par un événement de PI Planning. Au cours de cet événement, les équipes estiment ce qui sera livré et mettent en évidence leurs dépendances avec d'autres équipes Agile et trains. L'un des principaux résultats du PI Planning est un ensemble d'Objectifs de PI détaillant ce que l'ART devrait avoir à démontrer à la fin du PI. De plus, les Équipes Agiles intègrent continuellement leur travail tout au long du PI et démontrent les fonctionnalités lors de l'Iteration Review et des System Demos.

Le PI Planning a un ordre du jour standard qui comprend une présentation du contexte et de la vision de l'entreprise, suivie par des réunions de planification d'équipe - où chaque équipe crée ses plans d'itération et ses objectifs pour le PI à venir. Facilitée par le Release Train Engineer (RTE), le PI Planning inclut tous les membres de l'ART et se déroule dans le cadre de l'itération Innovation et Planification (IP).

Mener des System Demos

L'événement de la system demo test et évalue la solution dans un environnement de type production (souvent recette) pour recueillir les retours des parties prenantes, y compris les Business Owners, les sponsors exécutifs, les autres Agile Teams, les responsables du développement, et les clients (ou leurs représentants). Ce retour des parties prenantes est crucial, car elles seules peuvent évaluer l'efficacité et la facilité d'utilisation de la solution en cours de développement et offrir les indications dont l'ART a besoin pour rester sur la bonne voie ou s'adapter. L'événement de la system demo a lieu à la fin de chaque itération, fournissant une vue intégrée et globale des nouvelles Features livrées par l'ART.

Inspect & Adapt

Chaque PI se termine par un événement Inspect & Adapt (I&A), un moment privilégié pour réfléchir, appliquer des techniques de résolution de problèmes et identifier les actions d'amélioration nécessaires pour augmenter la vélocité, la qualité et la fiabilité du PI suivant. Au cours de l'événement I&A, le Product Management ou d'autres membres de l'équipe présentent toutes les features finalisées au cours de la system demo finale du PI. La démonstration est suivie de mesures quantitatives et qualitatives et d'un atelier de rétrospective pour la résolution de problèmes. Le résultat de l'I&A est un ensemble de features ou de stories d'amélioration que le RTE ou les équipes peuvent ajouter au backlog pour le PI Planning à venir. De cette manière, chaque ART améliore chaque PI, y compris les corrections de trajectoire vers la solution.

Les itérations déterminent la cadence de l'ART

Toutes les équipes agiles contribuent aux itérations de l'ART. Cependant, les modalités de planification et d'exécution pendant l'itération peuvent différer selon que l'équipe travaille en Scrum ou en Kanban. Les équipes Kanban travaillent généralement dans un modèle de flux continu, contribuant à l'incrément de l'ART au cours de chaque itération.

Puisque les équipes Agiles travaillent dans le cadre d'un ART, leur coopération est essentielle pour atteindre les Objectifs de l'équipe et du PI de l'ART. Pour parvenir à cette collaboration, les équipes doivent s'aligner sur la même cadence et la même durée d'itération.

Livrer continuellement et Publier à la demande

La construction et le maintien d'un pipeline de livraison continue (CDP) permet à chaque ART de définir, construire, valider et publier de nouvelles fonctionnalités pour atteindre les objectifs du PI. Plusieurs équipes agiles de l'ART partagent le même CDP lorsqu'elles collaborent dans le cadre d'itérations tout au long du PI. Chaque aspect du CDP est décrit ci-dessous :

Note : Pour certains ART, la livraison continue signifie une publication plusieurs fois par jour. Pour d'autres, le terme "continu" signifie une publication hebdomadaire ou mensuelle, ou tout autre cycle satisfaisant les demandes du marché et les objectifs de l'entreprise.

Continuous Exploration (CE)

L'exploration continue (CE) se concentre sur la création d'un alignement sur ce qui doit être construit. Dans le cadre de la CE, le design thinking permet à l'entreprise de comprendre le problème du marché, les besoins des clients et la solution requise pour répondre à ce besoin. Elle commence par une idée ou une hypothèse de quelque chose qui apportera de la valeur aux clients, généralement en réponse au feedback des clients ou à une étude de marché. Le concept est ensuite analysé et étudié pour comprendre les exigences d'une Minimum Marketable Feature (MMF) ou d'un Minimum Viable Product (MVP). Finalement, la convergence se produit en comprenant quelles features sont susceptibles de répondre aux besoins des clients et du marché.

Continuous Integration (CI)

L'intégration continue (CI) se concentre sur l'extraction de features du backlog de l'ART, l'application d'outils de design thinking dans l'espace de problèmes pour affiner les features, la réalisation d'études sur les utilisateurs et la collecte de feedbacks. Une fois qu'elles sont clairement comprises, les Équipes Agiles les implémentent. Le travail réalisé est soumis à un contrôle de version, construit et intégré dans un système ou une solution incrémentale, et testé de bout en bout avant d'être validé dans un environnement de recette.

Continuous Deployment (CD)

Le déploiement continu (CD) prend les modifications de l'environnement de recette et les déploie en production. À ce stade, elles sont vérifiées et supervisées pour s'assurer qu'elles fonctionnent correctement. Cette étape permet aux features d'être disponibles en production, où le métier détermine le moment opportun pour les diffuser/publier auprès des clients. Cette étape permet à l'organisation de réagir, de revenir en arrière (rollback) ou d'apporter des correctifs (fix forward).

Release on Demand (RoD)

La diffusion à la demande (RoD) permet de mettre à disposition des clients la valeur en une seule fois ou de manière incrémentale en fonction des besoins du marché et de l'entreprise. La diffusion à la demande (RoD) permet à l'entreprise de mettre à disposition au moment optimal pour le marché et de gérer soigneusement le risque associé à chaque diffusion.

Gérer les flux, le périmètre, les risques et les dépendances