Vous découvrez l’univers du framework SAFe ? Vous désirez comprendre ce qu’est un Agile Release Train (ART) ? Alors cet article est fait pour vous.
Définition Agile Release Train
Premièrement, l’Agile Release Train (ART) est la constitution d’une grande équipe qui travaillera ensemble sur une chaîne de valeur (pour simplifier un programme) ; elle est constituée elle-même de plusieurs équipes de réalisation (scrum), des parties prenantes et des profils transverses indispensables à cette chaîne de valeur.
Cet ART amènera entre 50 et 125 personnes à travailler ensemble régulièrement (mais pas constamment). Celui-ci alignera l’ensemble de ses membres autour d’un contexte business commun et d’une mission technologique commune.
Ainsi, l’objectif de l’ART sera de délivrer ensemble un maximum de valeur pour les utilisateurs finaux.
Multi-compétences pour délivrer un incrément
L’Agile Release Train devra contenir l’ensemble des compétences nécessaires pour réaliser le produit :
- software
- hardware
- firmware
- design
- test
- déploiement en continue
Principes clés de l’Agile Release Train
Voici les principes clés cités par l’auteur du framework SAFe que j’ai traduit en français pour définir l’ART :
L’horaire est fixe
Le train quitte la gare selon un horaire connu et fiable, déterminé par la cadence du program increment (PI) choisie. Si une fonction manque un départ programmé et n’est pas planifiée dans le PI actuel, elle prendra le train suivant.
Un nouvel incrément du programme toutes les 2 semaines
Chaque train délivre un nouvel incrément du programme toutes les deux semaines. La démo du programme dans sa globalité fournit un mécanisme d’évaluation du travail réalisé, qui est un incrément intégré de toutes les équipes.
La synchronisation des équipes
Toutes les équipes du train sont synchronisées sur la même durée PI (généralement 8 à 12 semaines) et ont des itérations communes définit par une date de démarrage et une durée
Le train a une vitesse connue
Chaque train peut estimer de manière fiable la quantité de marchandises (nouvelles fonctionnalités) pouvant être livrées dans un PI.
Équipes Agiles
Les équipes Agiles adoptent le «Manifeste Agile» et les valeurs et principes fondamentaux SAFe. Elles appliquent Scrum, Extreme Programming (XP), Kanban et d’autres pratiques d’excellence qualité.
Personnes dévouées
La plupart des personnes dont l’Agile Release Train a besoin sont consacrées à plein temps au train, quelle que soit leur structure hiérarchique fonctionnelle.
Planification d’IP en face à face
L’Agile Release Train planifie son travail lors des événements de planification appelé PI planning de façon périodiques. Cette planification rassemble tous les membres de l’ART pour favoriser au maximum la communication face à face.
Innovation et planification (IP)
Les itérations IP se produisent à la fin de chaque PI et dédient du temps au PI planning, à l’innovation, à la formation continue et aux travaux d’infrastructure.
Inspecter et adapter (I&A)
Un événement I&A a lieu à la fin de chaque IP. L’état actuel de la solution est démontré et évalué. Les équipes et la direction identifient ensuite les items du backlog d’amélioration via un atelier structuré de résolution de problèmes.
Develop on Cadence, Release on Demand
Les Agile Release Train appliquent la cadence et la synchronisation pour aider à gérer la variabilité inhérente de la recherche et du développement. Cependant, la libération est généralement découplée de la cadence de développement. Les ART peuvent publier une solution ou des éléments d’une solution, à tout moment, sous réserve de critères de gouvernance et de publication.
Agile Release Train : rôles clés
Dans l’ART, il y aura des rôles clés pour aider cette grande organisation a bien fonctionner. N’hésitez pas à aller lire sur les 2 rôles particuliers spécifiques au framework SAFe. Ceux-ci sont :
- RTE (Release Train Engineer)
- Le product Management
- Architectes et ingénieurs systèmes
- Business Owners
- Clients
La raison d’être de votre ART
Afin d’avoir une réelle identité et une véritable raison d’être, chaque ART devra être définie à l’aide du Canvas proposé par les auteurs du SAFe que vous pouvez-voir ci-dessous :
En remplissant ce canvas, l’organisation complexe de cette grande équipe sera plus claire pour l’ensemble de l’organisation.
La cadence de votre ART
Votre Agile Release Train comme je le disais plus haut, propose une cadence qui est assez complexe au premier abord mais qui permet de synchroniser le travail de l’ensemble de ses membres.
Se voulant agile, cela fonctionnera sous forme d’itérations complexes ; le schéma ci-dessous, vous décrit la cadence de cet ART :
Comme expliqué dans les principes clés de l’ART, les itérations de chaque équipe ( en général 2 semaines) seront de même durée et seront synchronisées. Cela permettra d’avoir un increment de programme toutes les 4 itérations classiques.
Conclusion Agile Release Train
Plus complexe en image qu’en réalité, les ART permettent de faire travailler toutes les personnes indispensables sur une même chaîne de valeur (ou programme pour simplifier).
Si certains lui trouveront une certaine rigidité pour ne pas dire « non agile », d’autres verront en lui une véritable solution de fonctionnement. N’hésitez pas à profiter des commentaires pour offrir aux lecteurs votre retour d’expérience ou votre avis sur ce concept qui est tout simplement un pilier du framework SAFe.
Liens utiles en anglais :
Le site officiel de SAFe
SAFe 5.0, the news!
Stretch objectives in SAFe
Program Board SAFe
Business owners in SAFe
Salut,
Tu parles de « Un nouvel incrément du programme toutes les 2 semaines », ne voulais tu pas évoquer plutôt les itérations produits car dans « La synchronisation des équipes » tu dis que le PI dure entre 8 et 12 semaines.
Dans 5 les rôles importants, tu as déjà créé 2 articles pour le RTE et le Business Owner, pourrais-tu prochainement réalisé un article sur « Architectes et ingénieurs systèmes » ?
Merci !
L’incrément se fait au rythme d’itérations de deux semaines (itération scrum). Le PI est le résultat de 4 à 6 itérations scrum.
Architectes et ingénieurs systèmes -> oui je peux mettre cela dans le pipe sans soucis 🙂