La Livraison Agile Disciplinée (Disciplined Agile Delivery – DAD) : le cycle de vie Programme

Le Cycle de vie Programme DAD pour une « équipe d’équipes »

• Voir figure 6.12 Le cycle de vie du programme p98
• Le cycle de vie du programme DAD décrit comment organiser une équipe d’équipes. Les grandes équipes agiles sont rares dans la pratique, mais elles existent.
  • C’est exactement la situation à laquelle s’attaquent les frameworks de mise à l’échelle tels que SAFe, LeSS et Nexus.

Aspects

• Phase de démarrage explicite
• Notion de sous-équipes
• Coordination à 3 niveaux
• Intégration et tests en parallèle
• Déploiement possible à tout moment
• Mise à l’échelle difficile

Phase de démarrage explicite

• Qu’on le veuille ou non, lorsqu’une équipe est nouvelle, nous devons investir du temps en amont pour nous organiser, et cela est particulièrement vrai pour les grandes équipes étant donné le risque supplémentaire auquel nous sommes confrontés.
• Nous devons le faire le plus rapidement possible, et le meilleur moyen est de reconnaître explicitement ce que nous devons faire et comment nous allons le faire.

La notion de sous-équipes

• Nous avons constitué une équipe d’équipes, appelons celles-ci : sous-équipes
• Les sous-équipes
  • Les sous-équipes/escouades choisissent puis font évoluer leur façon de travailler (Way of Working – WoW).
  • Les sous-équipes, parfois appelées escouades (squads), devraient être autorisées à choisir leur propre façon de travailler (Way of Working – WoW) comme n’importe quelle autre équipe le ferait.
    • Cela inclut le choix de leurs propres cycles de vie ainsi que de leurs propres pratiques. Pour être clair, certaines équipes peuvent suivre le cycle de vie Agile, d’autres le cycle de vie Livraison continue : Lean, etc.
  • Nous pouvons choisir d’imposer certaines contraintes aux équipes, telles que suivre des conseils communs et des stratégies communes autour de la coordination au sein du programme (capturé par l’objectif du processus Coordonner les activités).
    • Nous devrons parvenir à un accord sur la manière dont nous procéderons à l’intégration du système inter-équipes et aux tests inter-équipes (si nécessaire), dont les options sont capturées par l’objectif de processus Accélérer la livraison de valeur et l’objectif de processus Développer une stratégie de test, respectivement.
  • Là où un cadre tel que SAFe prescrirait une stratégie telle que la mise en place d’un train de livraison Agile (Agile Release Train – ART) pour ce faire, DAD propose des choix et vous aide à choisir la meilleure stratégie pour votre situation.
  • Les sous-équipes peuvent être des équipes de fonctionnalités ou des équipes de composants.
    • Pendant des années au sein de la communauté agile, il y a eu un débat entre les équipes de fonctionnalités et les équipes de composants.
      • Une équipe technique travaille sur des tranches verticales de fonctionnalités, implémentant une histoire ou traitant une demande de modification de l’interface utilisateur jusqu’à la base de données.
      • Une équipe de composants travaille sur un aspect spécifique d’un système, tel que la fonctionnalité de sécurité, le traitement des transactions ou la journalisation.
    • Notre expérience est que les deux types d’équipes ont leur place, elles sont applicables dans certains contextes mais pas dans d’autres, et les stratégies peuvent et sont souvent combinées dans la pratique.

La coordination se fait à trois niveaux

• Dans une approche systémique évidente, nous devons procéder à la coordination des différentes sous-équipes.
  • Lorsque nous coordonnons entre des sous-équipes, nous devons nous préoccuper de trois questions : la coordination du travail à faire, la coordination des problèmes techniques/architecturaux et la coordination des problèmes liés aux personnes.
  • Cette coordination est effectuée respectivement par les propriétaires de produits, les propriétaires d’architecture et les chefs d’équipe.
    • Les propriétaires de produit de chaque sous-équipe s’auto-organiseront et traiteront entre eux les problèmes de gestion du travail/des exigences, en s’assurant que chaque équipe effectue le travail approprié au moment approprié.
    • De même, l’équipe propriétaire de l’architecture s’organisera pour faire évoluer l’architecture au fil du temps et les chefs d’équipe s’organiseront pour gérer les problèmes de personnes survenant dans les équipes.
    • Les trois sous-équipes de direction sont capables de gérer le type de petites corrections de cap qui sont typiques au fil du temps.
• L’équipe peut constater qu’elle doit se réunir occasionnellement pour planifier le prochain bloc de travail, il s’agit d’une technique que SAFe appelle la planification par incréments de programme (Program Increment – PI) et suggère qu’elle se produise tous les trimestres.
  • Nous vous suggérons de le faire quand et si cela a du sens.
• Voir figure 6.13 Une structure potentielle pour organiser une grande équipe d’équipes page 99

L’intégration et les tests du système se déroulent en parallèle

• Il existe une équipe distincte, l’équipe de coordination (System Team) pour effectuer l’intégration globale du système et les tests inter-équipes.
  • Idéalement, ce travail devrait être minimal et entièrement automatisé dans le temps.
  • Nous avons souvent besoin d’une équipe distincte au début, souvent en raison d’un manque d’automatisation, mais notre objectif devrait être d’automatiser autant que possible ce travail et de pousser le reste dans les sous-équipes.
  • Cela dit, nous avons constaté que les tests d’utilisabilité sur l’ensemble de la solution, et de même les tests d’acceptation des utilisateurs (User Acceptance Test – UAT), nécessitent un effort distinct pour des raisons logistiques.

Les sous-équipes sont aussi entières que possible

• La majorité de l’effort de test devrait se produire au sein des sous-équipes, comme dans une équipe agile normale, avec l’intégration continue (Continuous Integration – CI) et le déploiement continu (Continuous Deploiement – CD) de façon native en utilisant les techniques DevOps.

Déploiement possible à tout moment

• Nous pouvons déployer à tout moment.
  • Nous préférons une approche (Continuous Deploiement – CD) à cela, bien que les équipes novices dans les programmes agiles puissent commencer par publier tous les trimestres (ou même moins souvent) puis améliorer la cadence de publication au fil du temps.
  • Les équipes qui sont nouvelles dans ce domaine auront probablement besoin d’une phase de transition, certaines personnes appellent ces « sprints de durcissement » (hardening sprints) ou « sprints de déploiement » (deployment sprints) les premières fois.
• L’objectif de processus “Accélérer la livraison de valeur” capture diverses options de version pour les équipes de livraison et le panneau de processus de gestion des versions [Release Management] capture les options pour le niveau de l’organisation.
• Les lames de processus
  • Une lame de processus englobe un ensemble cohérent d’options de processus, telles que des pratiques et des stratégies, qui doivent être choisies puis appliquées de manière contextuelle.
  • Chaque lame de processus répond à une capacité spécifique, telle que la finance, la gestion des données, le marketing ou la gestion des fournisseurs. Tout comme les objectifs de processus sont décrits à l’aide de diagrammes d’objectifs de processus, les lames de processus le sont également.

La mise à l’échelle est difficile

• Certains problèmes nécessitent une grande équipe, mais pour réussir, vous devez bien savoir ce que vous faites.
  • Si vous rencontrez des difficultés avec l’agilité en petite équipe, vous n’êtes pas prêt pour l’agilité en grande équipe.
  • De plus, la taille de l’équipe n’est que l’un des six facteurs d’échelle auxquels notre équipe peut avoir à faire face, les autres étant la répartition géographique, la complexité du domaine, la complexité technique, la répartition organisationnelle et la conformité réglementaire.
• Nous couvrons ces questions plus en détail sur PMI.org/disciplined-agile/agility-at-scale.

Créé le 27/12/2022.