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

Le cycle de vie Agile de DAD

• Voir figure page 88
• Le cycle de vie agile de DAD repose en grande partie sur le cycle de vie du framework Scrum avec des concepts de gouvernance éprouvés adoptés à partir du processus unifié (UP) pour le rendre prêt pour l’entreprise.
  • Ce cycle de vie est souvent adopté par les équipes de projet axées sur le développement d’une seule version d’une solution, même si parfois une équipe restera ensemble et la suivra à nouveau pour la prochaine version (et la prochaine version après cela, et ainsi de suite).
  • À bien des égards, ce cycle de vie décrit le fonctionnement d’un cycle de vie de projet basé sur Scrum dans un environnement de classe entreprise.
  • Nous avons travaillé avec plusieurs équipes qui aiment considérer cela comme Scrum++, sans être contraints par l’impératif culturel de la communauté Scrum de passer sous silence les activités de livraison de solutions qu’ils trouvent gênantes.
• Il y a plusieurs aspects critiques à ce cycle de vie.
  • La phase de démarrage / création (Inception)
  • La phase de construction (Construction)
  • La phase de transition / déploiement (Transition)

La phase de création (ou de démarrage)

• Comme nous l’avons décrit précédemment, l’objectif de l’équipe est de faire juste assez de travail pour s’organiser et aller dans la bonne direction.
  • DAD vise à rationaliser l’ensemble du cycle de vie du début à la fin, y compris les activités d’initiation abordées par Inception.
  • La création se termine lorsque nous avons une vision convenue concernant les résultats attendus pour l’équipe et comment nous allons les atteindre.

La phase de construction

• La construction est organisée en courtes itérations.
  • Une itération est une courte période de temps, généralement de 2 semaines ou moins, au cours de laquelle l’équipe de livraison produit une nouvelle version potentiellement consommable de sa solution.
  • Bien sûr, pour un nouveau produit ou une nouvelle solution, vous ne disposerez peut-être de quelque chose de vraiment consommable qu’après avoir effectué plusieurs itérations.
  • Cette phase se termine lorsque nous avons une valeur client suffisante, également appelée incrément commercial minimum (MBI).
• Les équipes traitent les éléments de travail par petits lots.
  • Travailler en petits lots est un élément fondamental de Scrum, et parce que ce cycle de vie est basé sur Scrum, c’est un aspect important de celui-ci.
  • Les équipes DAD, quel que soit le cycle de vie, sont susceptibles de travailler sur une gamme de choses : mettre en œuvre de nouvelles fonctionnalités, fournir aux parties prenantes des résultats positifs, mener des expériences, répondre aux demandes de modification des utilisateurs finaux provenant de l’utilisation de la solution actuelle en cours d’exécution, payer réduire la dette technique, suivre une formation et bien d’autres.
• Les éléments de travail sont généralement classés par ordre de priorité par le propriétaire du produit (Product Owner – PO), principalement en fonction de la valeur commerciale, bien que le risque, les dates d’échéance et la gravité (dans le cas des demandes de modification) puissent également être pris en compte.
  • L’objectif du processus de travail d’admission fournit une gamme d’options pour la gestion des éléments de travail.
  • À chaque itération, l’équipe extrait un petit lot de travail de la liste des éléments de travail qu’elle pense pouvoir réaliser au cours de cette itération.
• Les cérémonies critiques ont une cadence définie.
  • Comme dans le framework Scrum, ce cycle de vie planifie plusieurs cérémonies agiles sur des cadences spécifiques.
    • Nous organisons une rétrospective pour faire évoluer notre façon de travailler (Way of Working – WoW), et nous prenons une décision pour aller de l’avant.
    • Nous tenons également une réunion de coordination quotidienne (Daily Standup Meeting ou Daily Scrum).
    • Le fait est qu’en prescrivant quand tenir ces importantes séances de travail, nous éliminons certaines conjectures du processus.
    • L’inconvénient est que Scrum injecte une bonne partie des frais généraux du processus avec les cérémonies.
  • C’est un problème auquel le cycle de vie Lean répond.

La phase de transition

• L’objectif de la phase de transition est de s’assurer que la solution est prête à être déployée et, si oui, de la déployer.
  • Cette “phase” peut être automatisée (ce qui est exactement ce qui se passe lors de l’évolution vers les deux cycles de vie de livraison continue).

Jalons explicites

• Ce cycle de vie prend en charge la gamme complète de jalons simples et basés sur les risques, comme vous le voyez illustré au bas du cycle de vie.
  • Les jalons permettent aux dirigeants de gouverner efficacement, nous en reparlerons plus tard.
  • Par « léger », nous entendons que les jalons n’ont pas besoin d’être un examen bureaucratique formel des artefacts.
  • Idéalement, ils ne sont que des espaces réservés pour les discussions concernant le statut et la santé de l’initiative.
  • Les conseils pour l’entreprise et les feuilles de route sont explicitement affichés.
  • Sur le côté gauche du cycle de vie, vous voyez que des flux importants entrent dans l’équipe depuis l’extérieur du cycle de vie de livraison.

L’approche DevOps

• L’approche DevOps
  • La livraison de solutions n’est qu’une partie de la stratégie DevOps globale de votre organisation, qui à son tour fait partie de votre stratégie informatique globale.
    • Par exemple, la vision initiale et le financement de votre entreprise peuvent provenir d’un groupe de gestion de produits, et les feuilles de route et les conseils d’autres domaines tels que l’architecture d’entreprise, la gestion des données et la sécurité (pour n’en nommer que quelques-uns).
  • N’oubliez pas que les équipes DAD travaillent d’une manière adaptée à l’entreprise, et l’un des aspects de cette démarche consiste à adopter et à suivre les conseils appropriés.
    • Les opérations et le soutien sont représentés.
  • Si votre équipe travaille sur la nouvelle version d’une solution existante, vous êtes susceptible de recevoir des demandes de modification d’utilisateurs finaux existants, qui vous parviennent généralement via vos opérations et vos efforts de support.
  • Pour les équipes travaillant dans un environnement DevOps, il se peut que vous soyez responsable de l’exécution et du support de votre solution en production.

Créé le 27/12/2022.