« Planning Interval : PI (SAFe) » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| (22 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 12 : | Ligne 12 : | ||
[[Fichier:PI 6.0 nav icon.png|left|border|link=https://scaledagileframework.com/]] ''Sans engagement, il n'y a que des promesses et des espoirs, mais pas de plans.''<br/> | [[Fichier:PI 6.0 nav icon.png|left|border|link=https://scaledagileframework.com/]] ''Sans engagement, il n'y a que des promesses et des espoirs, mais pas de plans.''<br/> | ||
<br/> | <br/> | ||
— Peter F. Drucker<br/> | |||
<br/> | <br/> | ||
__TOC__ | __TOC__ | ||
==Planning Interval, [https://v5.scaledagileframework.com/program-increment/ ex-Program Increment (PI) de SAFe v5]== | |||
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.<br/> | 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.<br/> | ||
<br/> | <br/> | ||
| Ligne 70 : | Ligne 71 : | ||
====Continuous Exploration (CE)==== | ====Continuous Exploration (CE)==== | ||
[https://scaledagileframework.com/continuous-exploration/ L'exploration continue] 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é. | [https://scaledagileframework.com/continuous-exploration/ 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)==== | ====Continuous Integration (CI)==== | ||
[https://scaledagileframework.com/continuous-integration/ L'intégration continue] 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. | [https://scaledagileframework.com/continuous-integration/ 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)==== | |||
[https://scaledagileframework.com/continuous-deployment/ 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)==== | |||
[https://scaledagileframework.com/release-on-demand/ 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=== | |||
Vue dans son ensemble, la livraison continue est un processus très complet. En fait, il s'agit peut-être de la capacité la plus vitale pour chaque ART. Les parties prenantes ont besoin de visualiser et de suivre le travail en cours, même lorsqu'une partie importante du pipeline est automatisée. L'ART doit établir des limites d'encours (''WIP limits'') afin d'améliorer le débit et d'identifier et traiter les goulets d'étranglement. C'est le rôle de l'ART Kanban. En outre, les événements de synchronisation Kanban gèrent le flux, le périmètre, le risque et les dépendances, comme le décrivent les paragraphes suivants. | |||
====Visualiser et limiter l'encours avec l'ART Kanban==== | |||
Le RTE, le Product Management et d'autres personnes utilisent l'ART Kanban pour visualiser, suivre et gérer le flux des features, de l'idéation à l'analyse, à leur implémentation et à leur mise en production à travers le [https://scaledagileframework.com/continuous-delivery-pipeline/ Continuous Delivery Pipeline]. La figure 3 illustre un ART Kanban classique avec des exemples de règles régissant l'entrée et la sortie des features dans chaque état du processus. Il aide l'ART à améliorer le flux en faisant correspondre la demande à la capacité, en appliquant des limites aux encours, en visualisant les goulets d'étranglement et en identifiant les opportunités d'amélioration continue. Le Product Management passe en revue le Kanban et tire davantage de travail, en respectant les limites d'encours en collaboration avec les Product Owners. Ce Kanban facilite également la révision et la priorisation des nouvelles features basées sur l'exploration continue et offre les informations nécessaires pour prendre les décisions de mise en production et de déploiement. | |||
<br/> | |||
[[Fichier:PI F03-2.png|border|link=|900px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 3. Tableau ART Kanban.'''</div> | |||
====Synchro sur le périmètre, les progrès et les dépendances==== | |||
Trois événements de synchro. permettent à l'ART de rester sur la bonne voie, comme l'illustre la figure 4. La synchronisation du coach (''Coach Sync'') se concentre sur l'exécution du PI en cours, y compris les risques, les dépendances, les progrès et les obstacles. La synchro PO (''PO Sync'') gère la portée du PI, examine les progrès réalisés, ajuste les priorités et prépare le PI suivant. Comme les Product Owners et les Scrum Masters/Team Coachs s'intéressent souvent à des sujets similaires et ont besoin de collaborer, il est parfois utile de combiner la Coach Sync et la PO Sync en un seul événement connu sous le nom d'ART Sync. L'ART Sync remplace généralement la Coach Sync et la PO Sync lors d'une itération donnée afin de réduire la charge de travail.<br/> | |||
<br/> | |||
[[Fichier:PI F04-3.png|border|link=|800px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 4. Exemple d'agenda Coach Sync et PO Sync.'''</div> | |||
====Traiter les risques avec le tableau ROAM==== | |||
Le tableau ROAM (''ROAM Board'') créé lors du PI Planning (figure 5) peut être revu lors de l'ART Sync. afin de s'assurer que les personnes en charge d'assumer ou d'atténuer un risque prennent les mesures nécessaires. L'ART peut également enregistrer tout nouvel élément apparu après la planification et le ROAM-er.<br/> | |||
<br/> | |||
[[Fichier:PI F05-1.png|border|link=|300px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 5. Exemple de tableau ROAM.'''</div> | |||
====Résoudre les dépendances avec le tableau de planification de l'ART==== | |||
Pendant les événements de synchronisation, le RTE, le Product Management, les Scrum Masters/Team Coachs et les autres parties prenantes peuvent utiliser le tableau de planification de l'ART (''ART Planning Board''), illustré à la figure 6, pour suivre et gérer les dépendances, en veillant à ce qu'elles ne bloquent pas les autres équipes.<br/> | |||
<br/> | |||
[[Fichier:PI F06-4.png|border|link=|900px|center]]<br/> | |||
<div style="text-align: center;">'''Figure 6. ART Planning Board.'''</div> | |||
Le tableau de planification de l'ART doit être utilisé pendant et après le PI Planning pour contribuer à identifier les moyens de réduire ou d'éliminer les dépendances, ce qui permet aux équipes de travailler de manière plus indépendante et d'augmenter le flux de valeur. | |||
