Livraison agile disciplinée - Disciplined agile delivery

La livraison agile disciplinée ( DAD ) est la partie développement logiciel de la boîte à outils agile disciplinée. DAD permet aux équipes de prendre des décisions de processus simplifiées autour de la livraison de solutions incrémentielles et itératives. DAD s'appuie sur les nombreuses pratiques adoptées par les défenseurs du développement logiciel agile , notamment Scrum , la modélisation agile , le développement logiciel lean et autres.

La principale référence pour une livraison agile disciplinée est le livre Choose Your WoW! , écrit par Scott Ambler et Mark Lines.

En particulier, DAD a été identifié comme un moyen d'aller au-delà de Scrum. Selon le consultant principal de Cutter, Bhuvan Unhelkar, « DAD fournit un mécanisme soigneusement conçu qui non seulement rationalise le travail informatique, mais, plus important encore, permet une mise à l'échelle. » Paul Gorans et Philippe Kruchten appellent à plus de discipline dans la mise en œuvre des approches agiles et indiquent que DAD, en tant qu'exemple de cadre, est "une approche agile hybride de la fourniture de solutions informatiques d'entreprise qui fournit une base solide à partir de laquelle évoluer".

Histoire

Scott Ambler et Mark Lines ont initialement dirigé le développement de DAD. Ambler et Lines continuent de diriger l'évolution de DAD. DAD a été développé pour fournir une approche plus cohérente du développement logiciel agile ; un qui essaie de combler les lacunes du processus qui sont (volontairement) ignorées par Scrum, et un qui est capable d'évoluer au niveau de l'entreprise. Selon Ambler, « de nombreuses méthodologies agiles, notamment Scrum, XP, AM, Agile Data, Kanban, etc. concoctez votre propre méthodologie agile pour faire le travail."

DAD a été développé à la suite de l'observation de modèles communs où l'agilité a été appliquée avec succès à grande échelle.

En 2015, le cadre Disciplined Agile (DA), qui deviendra plus tard le Disciplined Agile Toolkit, a été développé. Cela s'appelait Disciplined Agile 2.x. DAD a formé la fondation de DA. Une deuxième couche, DevOps disciplinée, a été ajoutée, ainsi qu'une troisième couche appelée Disciplined Agile IT (DAIT). Ces couches, respectivement, expliquaient comment aborder les processus DevOps et informatiques dans un environnement de classe entreprise.

Disciplined Agile 3.x a été publié en août 2017 pour introduire une quatrième couche, Disciplined Agile Enterprise (DAE), pour répondre à l'ensemble des processus requis pour l'agilité de l'entreprise.

En décembre 2018, Disciplined Agile 4, maintenant appelé Disciplined Agile Toolkit, a été publié. Il s'est concentré sur une description complètement remaniée de DAD et sur une stratégie d'amélioration en équipe appelée amélioration continue guidée (GCI).

En août 2019, Disciplined Agile a été racheté par Project Management Institute .

Aspects clés

De nombreux défis auxquels les équipes sont confrontées sont hors de portée de Scrum et les équipes doivent se tourner vers d'autres méthodes avec des parties qui se chevauchent et une terminologie contradictoire. DAD tente de relever ces défis en utilisant une approche hybride axée sur l'apprentissage et axée sur les personnes pour la livraison de solutions informatiques.

Les gens d'abord

La livraison agile disciplinée (DAD) identifie que « les personnes et la façon dont elles interagissent les unes avec les autres sont le principal facteur déterminant du succès d'une équipe de livraison de solutions ». DAD prend en charge un ensemble solide de rôles (voir la section ci-dessous), de droits et de responsabilités que vous pouvez adapter pour répondre aux besoins de votre situation. DAD promeut les idées selon lesquelles les membres de l'équipe devraient collaborer étroitement et apprendre les uns des autres, que l'équipe devrait investir des efforts pour apprendre de leurs expériences et faire évoluer leur approche, et que les individus devraient faire de même.

Hybride

DAD est une boîte à outils hybride qui adopte et adapte des stratégies éprouvées à partir de méthodes existantes telles que Scrum , la programmation extrême (XP), SAFe , la modélisation agile (AM), Unified Process (UP), Kanban , le développement de logiciels externes , les données agiles (AD ) et le modèle de développement de Spotify . Plutôt que de prendre le temps d'adapter l'un de ces cadres existants, avec DAD, tous les efforts de combinaison des éléments pertinents de chaque technique ont déjà été effectués.

Cycle de vie complet de la livraison

Contrairement aux méthodes agiles de première génération qui se concentrent généralement sur les aspects de construction du cycle de vie, DAD aborde le cycle de vie complet de la livraison, de l'initiation de l'équipe jusqu'à la livraison d'une solution à vos utilisateurs finaux.

Prise en charge de plusieurs cycles de vie

DAD prend en charge six cycles de vie parmi lesquels choisir : les versions agile, allégée, à livraison continue, exploratoire et pour grande équipe du cycle de vie. DAD ne prescrit pas un cycle de vie unique car il reconnaît qu'une approche ne convient pas à tous.

Compléter

DAD montre comment le développement, la modélisation, l'architecture, la gestion, les exigences/résultats, la documentation, la gouvernance et d'autres stratégies s'intègrent dans un tout rationalisé. DAD fait le "processus de levage lourd" que d'autres méthodes vous laissent. 

Sensible au contexte

L'approche est axée sur les objectifs ou sur les résultats plutôt que normative. Ce faisant, DAD fournit des conseils contextuels concernant les alternatives viables - ce qui fonctionne, ce qui ne fonctionne pas et surtout pourquoi - et leurs compromis, vous permettant d'adapter votre façon de travailler pour faire face à la situation dans laquelle vous vous trouvez et le faire de manière simplifiée.

Des solutions consommables sur un logiciel fonctionnel

DAD se concentre sur la simple production de logiciels pour fournir des solutions consommables qui offrent une réelle valeur commerciale aux parties prenantes. Bien que le logiciel soit clairement une partie importante du livrable, être axé sur la solution signifie adopter une vision holistique du problème global. Cela peut conduire à des suggestions de mises à jour du matériel, des processus commerciaux et organisationnels et des structures organisationnelles globales.

Auto-organisation avec une gouvernance appropriée

Les équipes agiles et lean sont auto-organisées, ce qui signifie que les personnes qui font le travail sont celles qui le planifient et l'évaluent. Ils doivent toujours travailler d'une manière consciente de l'entreprise qui reflète les priorités de leur organisation, et pour ce faire, ils devront être gouvernés de manière appropriée par la haute direction.

Des cycles de vie

Disciplined prenait en charge à l'origine un cycle de vie de projet agile (basé sur Scrum) et un cycle de vie de projet Lean (basé sur Kanban). Il a depuis été étendu pour prendre en charge six cycles de vie :

  1. Agile . Un cycle de vie de projet en trois phases basé sur Scrum. Les phases sont Inception (ce qu'on appelle parfois « Sprint 0 »), Construction et Transition (ce qu'on appelle parfois un sprint de sortie).
  2. Maigre . Un cycle de vie de projet en trois phases basé sur Kanban.
  3. Livraison continue : Agile . Un cycle de vie de produit basé sur Agile qui prend en charge un flux de travail continu entraînant des versions incrémentielles (généralement une fois par semaine).
  4. Livraison continue : Lean . Un cycle de vie de produit basé sur le lean qui prend en charge un flux de travail continu.
  5. Exploratoire . Un cycle de vie basé sur l'expérimentation et basé sur le lean startup qui a été étendu pour traiter le développement parallèle de produits minimum viables selon les conseils de cynefin .
  6. Programme . Un cycle de vie pour coordonner une équipe d'équipes.

Objectifs du processus

DAD est décrit comme un ensemble de vingt et un objectifs de processus , ou résultats de processus. Ces objectifs guident les équipes à travers un processus plus léger vers des décisions qui tiennent compte du contexte de la situation à laquelle elles sont confrontées. Il permet aux équipes de se concentrer sur les résultats et non sur la conformité des processus et sur les conjectures de l'extension des méthodes agiles. Il permet la mise à l'échelle en fournissant des stratégies suffisamment sophistiquées pour répondre aux complexités auxquelles vous êtes confronté.

Phase de lancement Phase de construction Phase de transition
Mettez l'équipe dans la bonne direction. Créez progressivement une solution consommable. Lancez la solution en production.
  • Former l'équipe
  • Aligner avec la direction de l'entreprise
  • Développer une vision commune du projet
  • Explorer la portée
  • Identifier la stratégie d'architecture
  • Planifier la sortie
  • Développer une stratégie de test
  • Développer une vision commune
  • Financement sécurisé
  • Prouvez l'architecture tôt
  • Répondre aux besoins changeants des intervenants
  • Produire une solution potentiellement consommable
  • Améliorer la qualité
  • Accélérer la livraison de valeur
  • Assurer la préparation de la production
  • Déployer la solution
Objectifs en cours

Améliorer et travailler de manière consciente de l'entreprise.

  • Développer les membres de l'équipe
  • Coordonner les activités
  • Gérer le risque
  • Faire évoluer WoW
  • Exploiter et améliorer l'infrastructure existante
  • Gouverner l'équipe de livraison

Les rôles

Rôles principaux

Ces cinq rôles principaux dans la livraison agile disciplinée se trouvent généralement quelle que soit l'échelle.

  • Intervenant . Quelqu'un qui est matériellement touché par le résultat de la solution. Plus qu'un simple utilisateur final ou client, il s'agit de toute personne potentiellement concernée par le développement et le déploiement d'un projet logiciel.
  • Propriétaire du produit . La personne de l'équipe qui parle comme la "voix unique du client", représentant les besoins de la communauté des parties prenantes à l'équipe de livraison agile.
  • Membre de l'équipe . Le membre de l'équipe se concentre sur la production de la solution réelle pour les parties prenantes, y compris, mais sans s'y limiter : les tests, l'analyse, l'architecture, la conception, la programmation, la planification et l'estimation. Ils auront un sous-ensemble des compétences globales nécessaires et ils s'efforceront d'en acquérir davantage pour devenir des spécialistes généralistes.
  • Chef d'équipe . Le chef d'équipe est un leader d'accueil et également un coach agile, chargé de faciliter la communication, de leur permettre de choisir leur façon de travailler et de s'assurer que l'équipe dispose des ressources dont elle a besoin et est libre d'obstacles.
  • Propriétaire d'architecture . Possède les décisions d'architecture pour l'équipe et facilite la création et l'évolution de la conception globale de la solution.

Rôles de soutien potentiels

Ces rôles de soutien sont introduits (parfois sur une base temporaire) pour résoudre les problèmes de mise à l'échelle.

  • Spécialiste . Bien que la plupart des membres de l'équipe agile soient des spécialistes généralistes, d'autres spécialistes sont parfois nécessaires en fonction des besoins du projet.
  • Expert du domaine . Alors que le propriétaire du produit représente un large éventail de parties prenantes, un expert de domaine est parfois requis pour des domaines complexes où une compréhension plus nuancée est requise.
  • Expert technique . Dans les cas où un problème particulièrement difficile est rencontré, un expert technique peut être sollicité en cas de besoin. Il peut s'agir de build-masters, d'administrateurs de bases de données agiles, de concepteurs d'expérience utilisateur (UX) ou d'experts en sécurité.
  • Testeur indépendant . Bien que la majorité des tests soient effectués par les membres de l'équipe DAD, dans les cas de domaines ou de technologies complexes, une équipe de test indépendante peut être amenée à travailler en parallèle pour valider le travail.
  • Intégrateur . Pour les solutions techniques complexes à grande échelle, un intégrateur (ou plusieurs intégrateurs) peut être utilisé pour construire l'ensemble du système à partir de ses différents sous-systèmes.

Les références

Lectures complémentaires