Faire est un saut quantique d’imaginer.

—Barbara Sher

Incrément de programme

Un incrément de programme (PI) est une boîte de temps pendant laquelle un Agile Release Train (ART) offre une valeur incrémentielle sous la forme de logiciels et de systèmes fonctionnels et testés. Les PI durent généralement entre 8 et 12 semaines. Le modèle le plus courant pour un PI est constitué de quatre itérations de développement, suivies d’une itération Innovation et planification (IP).

Un incrément de programme est destiné à un ART (ou un train de solutions), tout comme « Une itération est destinée à l’équipe Agile », c’est une boîte de temps fixe pour la création et la validation d’un incrément système complet, la démonstration de la valeur et l’obtention d’un retour rapide. Chaque PI utilise la cadence et la synchronisation pour:

  • Faciliter la planification
  • Travail en cours limité (WIP)
  • Résumer la valeur digne d’intérêt pour les commentaires
  • Assurez des rétrospectives cohérentes au niveau du programme

En raison de sa portée, le PI fournit plusieurs observations appropriées pour la prise en compte au niveau du portefeuille et la «feuille de route».

Détails

SAFe divise la chronologie du développement en un ensemble d’itérations au sein d’un PI. La vue d’ensemble montre comment un PI est lancé par une session PI Planning et est ensuite suivi de quatre itérations d’exécution, se terminant par une itération Innovation et Planification. Ce modèle est suggestif mais arbitraire, et il n’y a pas de règle fixe pour le nombre d’itérations dans un PI. L’expérience a toutefois montré qu’une durée d’IP comprise entre 8 et 12 semaines donne les meilleurs résultats, en privilégiant la durée la plus courte.

Un train de solutions et ses Agile Release Trains associés utilisent la même cadence PI, comme le montre la figure 1.

Figure 1. Les trains Solution Solution et Agile Release suivent la même cadence PI.

Le PI représente la boucle externe du cycle PDCA de Shewhart, comme indiqué en haut de la figure 1. Il combine la valeur développée par chaque équipe agile dans un jalon significatif pour mesurer objectivement la solution en développement.

Le cycle d’apprentissage PDCA (illustré à la figure 1) est représenté par les événements suivants dans SAFe pour le PI (boucle externe):

Développer sur la cadence. Libération à la demande

L’exécution continue des PI donne le rythme aux trains, et les actifs qu’ils créent se développent de manière itérative et incrémentielle. La publication de solutions, cependant, est une préoccupation distincte, qui est traitée dans l’article de Release on Demand. Tandis que les trains déterminent le meilleur rythme de développement de produits, l’entreprise est en mesure de déployer des versions chaque fois que cela est nécessaire, ou sur le marché.

La cadence pour le PI peut être différente de la cadence de relâchement. Cependant, dans certaines situations, les cadences de PI et de relâchement sont les mêmes, ce qui peut être très pratique. D’autres ART peuvent avoir besoin de libérer moins ou plus fréquemment que la cadence PI. Cependant, d’autres disposeront de plusieurs cycles de publication indépendants pour les divers composants de la solution.

Exécution de l’incrément de programme

Comme il est expliqué dans la figure 2, une séquence d’événements de programme crée un système en boucle fermée permettant de maintenir le train sur les voies, en ce qui concerne l’exécution du PI pour un seul ART.

Figure 2. Événements d’exécution du programme

Chaque événement du programme est décrit dans les sections suivantes.

PI Planning

Chaque PI commence par un événement de PI Planning. Comme la planification des PI se produit à une cadence fixe, toute l’année civile des événements peut être programmée bien à l’avance. En planifiant à l’avance les événements de planification PI, l’entreprise peut réduire les coûts de déplacement et de logistique. Il aide également les personnes dans le train, en particulier les Business Owners, à gérer leur calendrier personnel afin de garantir leur présence lors de ces événements critiques.

Lors de la planification des PI, les équipes estiment ce qui va être livré et mettent en évidence leurs dépendances avec d’autres équipes et trains Agiles. La planification PI crée également un rythme pour l’intégration des démonstrations de travail et de système. L’un des résultats de la planification de l’IP est un ensemble d’objectifs d’IP du programme, détaillant ce que l’ART devrait avoir prêt pour l’intégration et la démonstration à la fin de l’IP. Bien entendu, les équipes Agiles intègrent en permanence leur travail et en font la démonstration lors de la Iteration Review et de la System Demo (ou de la Solution Demo pour les trains de solutions).

Scrum of Scrums

Le RTE (Release Train Engineer) organise généralement une réunion Scrum of Scrums (SoS) hebdomadaire (ou plus souvent, en fonction des besoins). Le SoS aide à coordonner les dépendances des ART et donne une visibilité sur les progrès et les obstacles. Le RTE, les Scrum Masters et d’autres (le cas échéant) se rencontrent pour examiner leurs progrès par rapport aux jalons, aux objectifs de l’IP du programme et aux dépendances internes des équipes. La réunion dure moins de 30 minutes et est suivie d’un «rendez-vous après» pour résoudre tous les problèmes. Un exemple d’ordre du jour pour la réunion sur le système de sécurité est décrit à la figure 3.

Figure 3. Exemple d’agenda de SoS

Product Owner Sync

De manière similaire au SoS, un PO Sync est souvent organisée pour les POs et les Products Managers. Cette réunion a généralement lieu chaque semaine ou plus souvent, selon les besoins. Le PO Sync est également limitée dans le temps (30 à 60 minutes) et est suivie d’une rencontre après pour résoudre tous les problèmes.

Le PO Sync peut être facilitée par le RTE ou le Product Manager. L’objectif est d’obtenir une visibilité sur la progression de l’ART dans la réalisation des objectifs du PI du programme, de discuter des problèmes ou des opportunités liés au développement des Features et d’évaluer les éventuels ajustements de la portée. La réunion peut également être utilisée pour préparer le prochain IP (voir ci-dessous) et peut inclure le raffinement du Program Backlog et la hiérarchisation des tâches pondérées les plus courtes en premier (WSJF) avant la prochaine réunion de planification des IP.

Remarque: comme l’illustre la figure 2, les synchronisations SoS et PO sont parfois combinées en une seule réunion, souvent appelée synchronisation ART.

Release Management Meetings

Les réunions de gestion des versions fournissent une gouvernance pour toutes les versions à venir, ainsi qu’une communication avec la direction. Pour en savoir plus, lisez l’article Release on Demand.

System Demo

Une démonstration du système est un événement bihebdomadaire qui fournit des informations en retour sur l’efficacité et la convivialité du système en développement. Cette démo aide également à garantir que l’intégration entre les équipes d’un même ART se produit régulièrement, pas moins que chaque itération. Et en tant que «développement du produit de contrôle des points d’intégration» [1], le PI est le point de routine auquel le comportement significatif et émergent du système complet ou de la solution peut être évalué.

Préparer le prochain événement de planification PI

Bien que nous notions cette fonction en tant qu’événement à la figure 3, en réalité, la préparation du prochain IP est un processus continu, avec trois domaines d’intervention principaux:

  • Alignement de la direction et préparation de l’organisation à la planification
  • Préparation du backlog
  • La logistique réelle de l’événement – état de préparation des installations

Étant donné que chacun d’entre eux peut interférer avec le résultat potentiel – un plan de PI spécifique et engagé -, un examen attentif de ces trois facteurs est nécessaire.

Inspect and Adapt

Le PI est terminé lorsque son timebox expire. Chaque PI est suivi d’une démo finale du système, événement digne de mention qui illustre toutes les Features réalisées au cours de la PI. Cela se fait généralement dans le cadre de l’atelier I&A, qui est un temps normal pour réfléchir, résoudre les problèmes et prendre les mesures d’amélioration nécessaires pour augmenter la vitesse, la qualité et la fiabilité du prochain PI. Le résultat de l’atelier est un ensemble de feature ou Stories d’amélioration qui peuvent être ajoutées au backlog pour la planification à venir de l’IP. De cette manière, chaque ART s’améliore à chaque PI.

Solution Train Exécution PI

Le niveau de solution étendu comporte d’autres événements et activités importants, qui apportent une attention similaire à l’avancement de la solution.

Planification pré et post-PI

Les Pre- et Post-PI Planning sont utilisés pour la préparation et la coordination de la planification des PI entre plusieurs ART et fournisseurs dans un train de solutions. Le but de ces événements est de créer une vision et une mission communes ainsi qu’un ensemble de fonctionnalités qui feront progresser la solution dans l’alignement.

L’événement de planification pré-PI est utilisé pour coordonner les entrées (par exemple, objectifs, jalons clés, contexte métier et contexte de solution) pour les sessions de planification ART. L’événement de planification post-PI est utilisé pour intégrer les résultats des sessions de planification ART individuelles dans la vision et la feuille de route pour le train de solutions.

À la fin de la réunion de planification post-PI, il devrait y avoir un ensemble convenu d’objectifs PI de solution à mettre en œuvre d’ici la fin de du PI et à démontrer lors de la démonstration de solution suivante.

Incrément de solution et démonstration de solution

Pendant la période du PI, les ART créent plusieurs incréments de valeur qui se transforment en capacités de solution. Les nouvelles fonctionnalités doivent être conçues, développées, testées et validées globalement, ainsi que les fonctionnalités existantes du système. La démonstration de la solution est un aspect crucial du cycle d’apprentissage du PI. Cet événement de grande envergure permet aux principaux acteurs de la solution, aux clients (ou à leurs mandataires internes) et à la direction de visualiser les progrès réalisés par la solution au cours des dernières PI.

Lors de cet événement, le Train de Solution présente ses réalisations pour l’ensemble de l’IP. Les cadres supérieurs et les parties prenantes examinent les progrès réalisés dans le contexte plus large de la solution. Cela peut également éclairer les décisions quant à l’opportunité de pivoter ou de persévérer avec les capacités, ainsi que les modifications apportées aux budgets lean pour les divers flux de valeur.

Solution Train Inspect and Adapt

À la fin du PI, un atelier I&A supplémentaire peut être requis pour le niveau de solution large. Il suit le même format que le niveau de programme I&A. En raison du nombre important de personnes impliquées, les participants à la solution Solution I&A ne peuvent pas inclure tous les acteurs des ART, aussi les représentants les mieux adaptés sont-ils sélectionnés pour traiter ce contexte. Cela inclut les principales parties prenantes de la solution Solution, ainsi que des représentants des différents ART et fournisseurs.

Apprendre encore plus

[1] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

© Scaled Agile, Inc.

Source de l'article