La Livraison Agile Disciplinée (Disciplined Agile Delivery – DAD) : choix du cycle de vie, jalons communs, étapes communes

Choix du cycle de vie ?

• De nombreuses questions se posent, les plus importantes :
  • Quand devriez-vous adopter chaque cycle de vie ?
  • Chaque équipe doit choisir son propre cycle de vie, mais comment procéder ?
• Il est tentant de demander à votre équipe de gestion de portefeuille de faire ce choix, après tout, eh bien, au moins, c’est pour eux.
  • Au mieux, ils devraient faire une suggestion (espérons-le solide) lorsqu’ils initient une entreprise, mais en fin de compte, le choix du cycle de vie devrait être fait par l’équipe si vous voulez qu’il soit efficace.
    • Cela peut être un choix difficile, en particulier pour les équipes novices en matière d’agilité et de lean.
  • Une partie importante de l’échafaudage processus-décision fourni par DAD est le conseil pour choisir un cycle de vie.
    • Nous avons constaté qu’il s’agissait de facteurs importants, issus du cadre de contexte de situation (SCF), à prendre en compte lors de la sélection d’un cycle de vie.

Les facteurs de choix

• Compétences d’équipe.
  • Les deux cycles de vie de la livraison continue (Continuous Delivery – CD) exigent que l’équipe ait beaucoup de compétences et de discipline.
  • Les autres cycles de vie DAD nécessitent également des compétences et de la discipline, bien que les deux cycles de vie CD se démarquent.
  • Avec un cycle de vie en approche séquentielle du type série (Waterfall, Serial), vous pouvez vous en sortir avec des personnes moins qualifiées.
    • En raison de la nature axée sur le transfert de la série, vous pouvez doter chaque phase de spécialistes étroitement qualifiés.
    • Cela dit, nous avons vu de nombreuses équipes traditionnelles composées de personnes très qualifiées.
• Culture d’équipe et d’organisation.
  • Les cycles de vie Agile et de livraison continue nécessitent de la flexibilité au sein de l’équipe et des parties de l’organisation avec lesquelles l’équipe interagit.
  • Les stratégies Lean peuvent être appliquées dans des organisations avec une gamme variable de flexibilité.
  • Serial peut, et est souvent, appliqué dans des situations très rigides.
• La nature du problème.
  • Les cycles de vie de livraison continue fonctionnent très bien lorsque vous pouvez créer et publier par très petits incréments.
  • Les autres cycles de vie DAD fonctionnent très bien par petits incréments. Serial est vraiment adapté aux grandes versions.
• Contraintes commerciales.
  • La question clé ici est la disponibilité et la volonté des parties prenantes, bien que la flexibilité financière/de financement soit également essentielle.
    • Le cycle de vie exploratoire nécessite un état d’esprit flexible, orienté client et expérimental de la part des parties prenantes.
    • Agile, parce qu’il a tendance à libérer des fonctionnalités en termes de fonctionnalités complètes, nécessite également de la flexibilité dans la manière dont nous interagissons avec les parties prenantes.
    • Étonnamment, les cycles de vie de la livraison continue nécessitent moins de flexibilité pour les parties prenantes en raison de la possibilité de libérer des fonctionnalités désactivées, offrant ainsi un meilleur contrôle sur le moment où quelque chose est publié (en l’activant simplement).
  • L’objectif du processus “Faire évoluer sa façon de travailler (Way of Working – WoW)” ou “Evolve WoW” comprend un point de décision qui couvre les compromis associés aux six cycles de vie DAD, ainsi que quelques autres qui ne sont pas encore explicitement pris en charge par DAD (comme la série).
  • Aide au choix
    • Figure 6.14 Organigramme de choix d’un cycle de vie initial p101
    • Figure 6.15 Facteurs de sélection pour choisir un cycle de vie p102

Différents cycles de vie avec des étapes communes

• Dans de nombreuses organisations que nous avons aidées à adopter DA, la haute direction, et souvent la direction intermédiaire, sont très réticentes au début à autoriser les équipes de livraison à choisir leur façon de travailler (Way of Working – WoW).
  • Le défi est que leur état d’esprit traditionnel leur dit souvent que les équipes doivent suivre le même « processus reproductible » afin que la haute direction puisse les superviser et les guider.
  • Il y a deux idées fausses importantes avec cet état d’esprit.
    • 1-Premièrement, nous pouvons avoir une gouvernance commune entre les équipes sans appliquer un processus commun.
      • Un catalyseur fondamental de cela est d’adopter des jalons communs, basés sur les risques (et non sur les artefacts) tout au long des cycles de vie.
      • C’est exactement ce que fait DAD.
    • 2-Deuxièmement, les résultats reproductibles sont bien plus importants que les processus reproductibles.
      • Nos parties prenantes veulent que nous dépensions judicieusement leur investissement informatique.
      • ElIes veulent que nous produisions – et que nous fassions évoluer – des solutions qui répondent à leurs besoins réels.
      • ElIes veulent ces solutions rapidement.
      • ElIes veulent des solutions qui leur permettent d’être compétitifs sur le marché.
      • Ce sont les types de résultats que les parties prenantes aimeraient avoir encore et encore (par exemple, à plusieurs reprises), et malheureusement elIes ne sont vraiment pas concernés par les processus que nous suivons pour le faire.
• Pour en savoir plus sur les stratégies de gouvernance efficaces pour les équipes agiles/lean, consultez l’objectif du processus “Gouverner l’équipe”.
  • Figure 6.16 Jalons communs à travers les cycles de vie p103
• Jalons basés sur les risques de DAD
  • Vision des parties prenantes.
    • L’objectif de la phase de démarrage est de passer un temps court mais suffisant, généralement de quelques jours à quelques semaines, pour obtenir l’accord des parties prenantes sur le fait que l’initiative a du sens et doit se poursuivre dans la phase de construction.
    • En abordant chacun des objectifs DAD de la phase démarrage (Inception), l’équipe de livraison saisira les informations traditionnelles du projet liées à la portée initiale, à la technologie, au calendrier, au budget, aux risques et à d’autres informations, mais de la manière la plus simple possible (approche haut niveau).
    • Ces informations sont consolidées et présentées aux parties prenantes sous la forme d’un énoncé de vision tel que décrit par l’objectif du processus Développer une vision commune.
      • Le format de la vision et la formalité de l’examen varieront en fonction de votre situation.
      • Une pratique typique consiste à examiner une courte série de diapositives avec les principales parties prenantes à la fin de la phase de démarrage pour s’assurer que tout le monde est sur la même page en ce qui concerne l’intention du projet et l’approche de livraison.
  • Architecture éprouvée.
    • L’atténuation précoce des risques fait partie de toute bonne discipline d’ingénierie.
    • Comme l’indique l’objectif du processus “Prouvez l’architecture” à un stade précoce, vous pouvez choisir d’adopter plusieurs stratégies.
      • La plus efficace consiste à créer un squelette de bout en bout de code de travail qui implémente des exigences métier techniquement risquées. L’une des principales responsabilités du rôle de propriétaire de l’architecture de DAD est d’identifier les risques pendant la phase de démarrage.
    • On s’attend à ce que ces risques aient été réduits ou éliminés en mettant en œuvre des fonctionnalités connexes entre une et trois itérations dans la phase de construction.
      • Suite à l’application de cette approche, les revues/démos des premières itérations montrent souvent la capacité de la solution à prendre en charge des exigences non fonctionnelles en plus ou à la place des exigences fonctionnelles.
      • Pour cette raison, il est important que les parties prenantes connaissant bien l’architecture aient la possibilité de participer à ces révisions d’étape.
  • Viabilité continue.
    • Une étape facultative à inclure dans votre calendrier de publication est liée à la viabilité du projet.
      • À certains moments d’un projet, les parties prenantes peuvent demander un point de contrôle pour s’assurer que l’équipe travaille à la vision convenue à la fin de Inception.
        • La planification de ces jalons garantit que les parties prenantes sont au courant des dates clés auxquelles elles doivent se réunir avec l’équipe pour évaluer l’état du projet et accepter les modifications si nécessaire.
        • Ces changements pourraient inclure n’importe quoi comme les niveaux de financement, la composition de l’équipe, la portée, l’évaluation des risques ou même potentiellement l’annulation du projet.
      • Il pourrait y avoir plusieurs de ces jalons dans un projet de longue durée.
      • Cependant, au lieu d’avoir cet examen d’étape, la vraie solution est de mettre en production plus souvent.
        • L’utilisation réelle, ou son absence, fournira une indication très claire de la viabilité de votre solution.
  • Fonctionnalité suffisante.
    • S’il vaut la peine de poursuivre un objectif de solution consommable (ce que le framework Scrum appelle un incrément potentiellement livrable) à la fin de chaque itération, il est plus courant d’exiger un certain nombre d’itérations de Construction avant que l’équipe ait implémenté suffisamment de fonctionnalités à déployer.
    • Incrément et MVP
      • Bien que cela soit parfois appelé un produit minimum viable (MVP), cela n’est pas techniquement précis car, classiquement, un MVP est destiné à tester la viabilité d’un produit plutôt qu’une indication de la fonctionnalité déployable minimale.
    • Incrément et MBI
      • Le terme le plus précis à comparer à cette étape serait “ensemble de fonctionnalités minimum” ou “incrément d’activité minimum” (Minimum Business Increment – MBI).
        • Un MBI est la plus petite amélioration viable d’un produit/service existant qui offre une valeur réalisée pour un client.
        • Un MBI comprendra une ou plusieurs fonctionnalités commercialisables minimales (MMF), et un MMF fournit un résultat positif aux utilisateurs finaux de notre solution.
    • Un résultat peut devoir être implémenté via plusieurs user stories.
      • Par exemple, la recherche d’un article sur un système de commerce électronique n’ajoute aucune valeur à un utilisateur final s’il ne peut pas également ajouter les articles trouvés à son panier. Le jalon de fonctionnalité suffisante de DAD est atteint à la fin de la phase de construction lorsqu’un MBI est disponible, et le coût de la transition de la version aux parties prenantes est justifié.
      • Par exemple, alors qu’un incrément d’une solution consommable peut être disponible à chaque itération de 2 semaines, il peut prendre plusieurs semaines pour le déployer dans un environnement hautement conforme, de sorte que le coût du déploiement peut ne pas être justifié jusqu’à ce qu’une plus grande quantité de la fonctionnalité est terminée.
  • Prêt pour la fabrication.
    • Une fois que des fonctionnalités suffisantes ont été développées et testées, les activités liées à la transition telles que les conversions de données, les tests d’acceptation finale, la production et la documentation liée au support doivent normalement être terminées (si elles ont été intégrées dans la Definition of Done (DoD).
      • Idéalement, une grande partie du travail a été effectuée en continu pendant la phase de construction dans le cadre de l’achèvement de chaque incrément de fonctionnalité.
      • À un moment donné, il faut décider que la solution est prête pour la production, ce qui est l’objectif de cette étape.
      • Les deux cycles de vie basés sur des projets incluent une phase de transition où le jalon Production Ready est généralement mis en œuvre sous forme de révision.
      • Les deux cycles de vie de livraison continue, d’autre part, ont une activité de transition/version entièrement automatisée où cette étape est abordée par programme. En règle générale, la solution doit passer des tests de régression automatisés et les outils d’analyse automatisés doivent déterminer que la solution est de qualité suffisante.
    • MVP contre MBI
      • Considérez un MVP comme quelque chose que l’organisation fait pour des raisons égoïstes.
      • Il s’agit d’apprendre, pas de fournir au client une solution à part entière (ou parfois même vaguement fonctionnelle), alors qu’un MBI est altruiste, il s’agit avant tout des besoins du client.
  • Des intervenants ravis.
    • Les organes de gouvernance et les autres parties prenantes aiment évidemment savoir quand l’initiative est officiellement terminée afin de pouvoir commencer un autre déblocage ou diriger des fonds ailleurs.
    • Néanmoins l’initiative ne s’arrête pas lorsque la solution est déployée puisqu’il faudra assurer le maintien en conditions opérationnelles (MCO) du Produit.
      • Avec les projets, il y a souvent des activités de clôture telles que la formation, le réglage du déploiement, les transferts de support, les revues post-implémentation ou même les périodes de garantie avant que la solution ne soit considérée comme complète.
    • L’un des principes de DA est de ravir les clients, ce qui suggère que les clients « satisfaits » mettent la barre trop bas.
      • Nous devons vérifier si nous avons ravi nos parties prenantes, généralement par la collecte et l’analyse de mesures appropriées (Monitoring), parfois appelées « réalisation des avantages ».

Les cycles de vie ne sont que des points de départ

• Les équipes DAD évolueront souvent d’un cycle de vie à l’autre.
  • En effet, les équipes DAD s’efforcent toujours d’optimiser le flux, d’améliorer leur WoW au fur et à mesure qu’elles apprennent grâce à leurs expériences et à des expérimentations ciblées.
• Lorsque vous aidez une équipe traditionnelle à passer à une façon de travailler (Way of Working – WoW) plus efficace, une approche courante consiste à commencer par le cycle de vie Agile.
  • Il s’agit d’une approche « couler ou nager » dont l’expérience montre qu’elle peut être très efficace, mais qui peut s’avérer difficile dans les cultures qui résistent au changement.
• Une deuxième voie illustrée dans ce diagramme consiste à démarrer des équipes traditionnelles avec une approche Lean Kanban dans laquelle l’équipe commence avec sa façon de travailler (Way of Working – WoW) existant et l’évolue au fil du temps via de petits changements dans le cycle de vie Lean.
  • Bien que cela soit moins perturbateur, cela peut entraîner un rythme d’amélioration beaucoup plus lent puisque les équipes continuent souvent à travailler en silo avec des colonnes de tableau kanban représentant des spécialités traditionnelles.
• Approche Programme
  • Premièrement, à certains égards, cela s’applique au cycle de vie du programme.
    • Vous pouvez adopter une approche de programme Agile (similaire à ce que font en pratique les frameworks de mise à l’échelle tels que Nexus, SAFe et LeSS), où le programme publie de grands incréments à une cadence régulière (par exemple, tous les trimestres).
      • Vous pouvez également adopter une approche de programme allégée, où les sous-équipes diffusent les fonctionnalités dans la production, puis au niveau du programme, cela est activé lorsque cela a du sens.
  • Deuxièmement, le diagramme se concentre sur les cycles de vie de livraison complète, alors que le cycle de vie exploratoire n’est pas un cycle de vie de livraison complète à part entière.
    • Il est généralement utilisé pour tester une hypothèse concernant une offre de marché potentielle, et lorsque l’idée a été suffisamment étoffée et qu’il semble que le produit réussira, l’équipe passe alors à l’un des cycles de vie de livraison.
    • De cette façon, cela remplace une bonne partie des efforts de la phase de démarrage pour l’équipe.
    • Un autre scénario courant est qu’une équipe est en cours de développement et se rend compte qu’elle a une nouvelle idée pour une fonctionnalité majeure qui doit être mieux explorée avant d’y investir de sérieux efforts de développement.
    • Ainsi, l’équipe passera au cycle de vie Exploratoire aussi longtemps qu’il le faudra pour étoffer l’idée de la fonctionnalité ou pour réfuter sa viabilité sur le marché.
• Voir figure 6.17 Chemins d’évolution courants du cycle de vie page 106

En résumé

• Certaines équipes au sein de votre organisation suivront toujours un cycle de vie en série, DAD le reconnaît explicitement mais ne fournit pas de support pour cette catégorie de travail en diminution.
• DAD fournit l’échafaudage nécessaire pour choisir entre, puis faire évoluer, six cycles de vie de livraison de solutions (SDLC) basés sur des stratégies agiles ou allégées.
• Les cycles de vie basés sur des projets, même agiles et allégés, passent par des phases.
• Chaque cycle de vie a ses avantages et ses inconvénients, chaque équipe doit choisir celle qui reflète le mieux son contexte.
• Des jalons communs basés sur les risques permettent une gouvernance cohérente : vous n’avez pas besoin d’imposer le même processus à toutes vos équipes pour pouvoir les gouverner.
• Une équipe commencera par un cycle de vie donné et s’en éloignera souvent à mesure qu’elle améliorera continuellement sa façon de travailler (Way of Working – WoW).

Créé le 27/12/2022.