Lorsque l’agilité se déploie à l’échelle, une difficulté réside dans le fait de pouvoir faire travailler ensemble des équipes agiles et être en capacité d’intégrer les différents éléments d’un système produits par ces dernières. Autant l’agilité à petite échelle, c’est-à-dire au niveau d’une équipe, est bien maîtrisée aujourd’hui, autant la mise à échelle nécessite une organisation rigoureuse et une attention particulière.
La System Team, un support aux équipes de réalisation
Ce que dit SAFe
Dans SAFe (le “framework” d’agilité à l’échelle le plus répandu), les équipes agiles ne sont pas des unités totalement autonomes. Au lieu de cela, elles font partie d’un ensemble que l’on appelle un Agile Release Train (ART). Ce train est responsable collectivement de la fourniture d’un système complet et d’une valeur de solution plus importants. Les pratiques de qualité intégrées nécessitent généralement un travail d’infrastructure supplémentaire pour créer, intégrer, déployer et publier des artefacts de solution plus fréquemment et en continu à travers plusieurs étapes d’une chaîne que l’on appelle pipeline.
Pour soutenir cela, une ou plusieurs équipes systèmes spécialisées sont souvent formées, appelées System Team (ST). Concrètement, en tant que type d’équipe agile « habilitante », les System Team aident à créer les environnements et à intégrer le système et la solution. Les ST peuvent aussi accélérer les vitesses des équipes agiles en effectuant certains des tests les plus lents, de bout en bout et non fonctionnels (NFR). Elles aident également à faire la démonstration de la solution au fur et à mesure de son évolution.
Une mission claire, des responsabilités et des activités diverses et variées
Mission et responsabilités d’une System Team (toujours selon SAFe)
La mission d’une ST est d’aider à créer et à prendre en charge l’environnement de développement agile. Principalement, elle réalise le développement et la maintenance de la chaîne d’outils qui constitue le “pipeline de livraison continue”. Si besoin, elle prend en charge l’intégration des actifs des équipes agiles, effectue des tests de solution de bout en bout si nécessaire et aide au déploiement et à la publication des fonctionnalités à la demande (Deploy and Release).
Sur l’intégration de l’infrastructure de développement agile, l’équipe doit créer et maintenir la chaîne d’outils du pipeline de livraison continue, y compris l’intégration continue, les builds automatisés, les tests de vérification de build automatisés et le déploiement automatisé. Elle doit créer des plates-formes et des environnements pour le développement, les démonstrations de solutions et les tests d’acceptation utilisateurs. Enfin, elle doit faciliter les aspects techniques de la collaboration avec des tiers, tels que les fournisseurs de données ou de services et les installations d’hébergement.
Sur l’intégration de la solution, l’équipe doit participer au PI Planning et aux événements pré et post-PI Planning dans la Large Solution SAFe et au raffinement du backlog pour définir l’intégration et tester les éléments du backlog. Elle doit déterminer et aider à maintenir les décisions et les politiques pour la gestion des versions. Elle doit exécuter des scripts de génération et d’intégration au niveau de la solution ou intégrer manuellement là où l’automatisation n’existe pas encore. Enfin, elle doit se tenir informée de l’avancement pour soutenir les activités quotidiennes des autres équipes.
Sur les tests de bout-en-bout de la solution, elle participe aux activités de test comme la création de nouveaux scénarios de tests automatisés, l’organisation des cas de test conçus par les équipes individuelles en suites ordonnées, l’exécution de certains tests manuels et des tests automatisés pour les nouvelles fonctionnalités, l’aide aux équipes dans la création de « smoke tests » ou de suites de tests réduits qui pourront être exécutés rapidement et indépendamment pour les versions des développeurs, le test des performances de la solution par rapport aux NFR (Non Functionnal Requirements) et le support aux System Architect (SA) et System Engineering (SE) du train et de la solution dans l’identification des lacunes et des goulots d’étranglement du système.
Sur la démonstration au niveau système et au niveau solution, l’équipe doit aider à préparer les environnements techniques pour une démonstration la plus fiable possible de la nouvelle fonctionnalité.
Sur la livraison de la solution, l’équipe doit soutenir l’ART ou le Solution Train pour préparer, packager et déployer une solution dans le cadre des activités DevOps et du pipeline de livraison continue.
La System Team, une équipe à géométrie variable
Nos retours d’expérience montrent que les System Team sont à géométrie variable en termes d’activités. Des équipes peuvent être plus ou moins engagées dans la réalisation des tâches d’intégration de la solution, la mise en oeuvre des tests de bout-en-bout ou les gestion des environnements de production et hors-production.
Composition et organisation d’une System Team
Une ST est une équipe agile spécialisée. Agile, cela veut dire qu’elle doit comprendre et appliquer le cadre de travail agile en mettant en œuvre les pratiques adéquates. Pour cela la présence d’un coach pour l’équipe est fortement conseillée en tant que garant et facilitateur. L’équipe System Team travaille sur le pipeline d’intégration continue (CI) et de déploiement continu (CD). Elle est en étroite collaboration avec les System Architect (SA) et les System Engineering (SE) du train. Agile, cela veut dire aussi qu’une personne de l’équipe doit jouer le rôle de « owner » pour définir la vision du produit de l’équipe (le pipeline CI/CD en l’occurrence) et sa feuille de route, gérer le backlog de l’équipe (maturation des sujets, priorisation des sujets en fonction de la valeur, …) et participer aux cérémonies de l’équipe et du train.
La System Team, des compétences d’OPS, mais pas uniquement !
SAFe n’impose pas de rôle particulier dans la ST, mais nous voyons bien que pour fonctionner correctement, cette équipe doit rassembler a minima des compétences d’OPS agissant sur l’infrastructure du système et des compétences d’architecture œuvrant sur la conception du système et l’environnement de développement agile. SAFe indique que des System Architect/ System Engineering peuvent faire partie de cette équipe mais cela ne revêt pas de caractère obligatoire. Il peut être intéressant que l’équipe dispose de compétences dans le développement avec des profils LeadDEV ou les techniques avec des LeadTECH.
Différentes configurations possibles dans l’organisation SAFe
Une ST aide un ou plusieurs ART à créer et à utiliser l’infrastructure de l’environnement de développement agile. SAFe laisse le choix du nombre et du positionnement des ST dans l’organisation agile.
Plusieurs scénarios peuvent être envisagés :
- Scénario 1 : Il y a une équipe système par ART qui coordonne l’intégration et la validation de la solution
- Scénario 2 : Il existe une seule équipe système pour l’ensemble du train de solutions, qui peut assumer ces responsabilités pour tous les ART
- Scénario 3 : Il existe des équipes système pour les ART et le train de solutions
En fonction du contexte et de la maturité de l’organisation, en fonction du type de produits et de solutions réalisés, nous voyons qu’il n’y a pas une seule manière de faire. Il est fortement recommandé que l’organisation soit accompagnée par un coach agile ou le LACE dans SAFe.
Nous verrons dans un prochain article les avantages et les inconvénients de ces différents scénarios et nous décrirons plus précisément le fonctionnement d’une System Team aux travers des rôles et des activités de ses membres.
Article extrait de la série publiée par Modern Product Agility, dans la rubrique "ÉCLAIRAGE SUR L'AGILITÉ"