https://gestiondeprojetsorg.com

La Dynamic Systems Development Method est une méthode agile utilisée dans les projets informatiques. Vous trouverez ci-dessous des explications.

Le DSDM (Dynamic Systems Development Method) est un framework Agile très peu connu en France. Le DSDM est apparue en 1994 en Grande Bretagne pour dispenser au RAD d’une certaine discipline. Le DSDM est un framework agile qui a évolué avec le temps ; il se concentre plutôt sur une approche de gestion de projet et de livraison que sur une façon de faire du code.

DSDM, Méthode agile mais pas forcément IT
Si on en lit les 12 principes du manifeste agile, on est clairement en présence de projet IT ; pourtant le DSDM se veut être un framework agile mais également applicable sur d’autres projets que des projets IT.
Par contre le DSDM est sans conteste Agile avec son aspect incrémental et itératif ; le client est également au centre de cette méthodologie de travail.
La DSDM fixe le coût, la qualité et les délais et utilise le modèle MoSCoW pour prioriser les items du projet.

Le DSDM remis à jour en 2014 :
Etant tout à fait agile, cette méthode n’hésite pas à se remettre au goût du jour.
D’ailleurs, le DSDM n’hésite pas à proposer aujourd’hui de la travailler avec d’autres approches comme :
– PRINCE2
– Managing Successful Programmes
– PM-BOK
– Extreme Programming (une autre méthode agile).

Voici la liste des 9 principes fondateurs du DSDM :
1. Implication des utilisateurs -> ils doivent être présent tout au long du développement du projet
2. Autonomie -> L’équipe est autonome sur le développement et doit avoir un droit de décision imparable sur l’évolution des besoins.
3. Visibilité du résultat -> Livraison fréquente de l’application afin d’obtenir des feedback fréquents.
4. Adéquation -> L’application livrée doit être en adéquation avec le besoin des utilisateurs.
5. Développement itératif et incrémental -> Le produit doit constamment s’améliorer avec le feedback des utilisateurs.
6. Réversibilité ->En cas de besoin, tout développement doit pouvoir revenir en arrière.
7. Synthèse -> Un schéma directeur fixe le projet dans son ensemble que ce soit au niveau vision ou au niveau objectifs.
8. Tests -> Automatisation de tests fréquent afin de garantir une non régression au sein de l’application.
9. Coopération -> L’ensemble de l’équipe ou parties prenantes sur le projet doivent accepter d’éventuelles modifications des fonctionnalités demandées.

Les détails de chaque étape du Dynamic Systems Development Method :
– Étude de faisabilité : déterminer s’il est opportun de faire le projet en question -> évaluation des coûts et de la valeur ajoutée attendue. Dans cette étape, on produit un rapport de faisabilité ainsi qu’un plan global de développement. On développe parfois un prototype afin de démontrer la faisabilité technique.
– Étude business (ou analyse fonctionnelle) : définition des spécifications -> fonctionnalités que l’application doit apporter, priorisation de celles-ci, dans un document appelé Définition du Domaine Industriel, mais aussi quels types d’utilisateurs sont concernés par l’application, de manière à pouvoir les impliquer. On définit également l’architecture du système, dans un document appelé Définition de l’Architecture Système. Enfin, à partir du Plan Global de Développement, on définit un Plan Global de Prototypage.
– Modèle fonctionnel itératif et Conception et réalisation itératives : nous travaillons techniquement de façon itérative.
– Mise en œuvre : mise en production de l’application afin de mettre notre application à disposition des utilisateurs types ; ceci permettra d’avoir des feedback rapides de ceux-ci et d’incrémenter le produit d’améliorations.

Des points à savoir sur le DSDM :
– Timeboxe : Le DSDM est une méthode agile où on fonctionne avec des timeboxe. Rien n’empêcherait cependant un agiliste d’utiliser d’autres méthodes comme l’utilisation de points d’effort.
– Workshop : Il est essentiel dans le DSDM de faire des workshop avec les parties prenantes pour amener le projet à maturité.

Contrairement au Scrum, le DSDM est beaucoup plus précis sur les rôles qui doivent exister au sein des projets.
– Executive Sponsor / Project Champion :  cette personne est habilité à prendre des décisions. Il va aussi engager des fonds et des ressources.
– Le visionnaire : cette personne a la responsabilité d’initier un projet en assurant que les exigences essentielles sont présentes dès le début du projet. Il a la vision la plus précise des objectifs business du projet ; il devra également bien vérifier que les développements vont toujours dans le bon sens de la vision.
– L’ambassadeur : cette personne apporte les connaissances nécessaires venant des utilisateurs de l’application pendant le projet ; il assure aussi un maximum de feedback de ceux-ci tout au long du projet.
– Un conseiller : cette personne est un utilisateur qui peut apporter de bonnes connaissances quotidiennes au projet..
– Project Manager : cette personne vient de l’équipe IT et a pour but de manager le projet dans ses grandes lignes.
– Technical Coordinator : Cette personne est responsable dans la définition de l’architecture technique et le contrôle de la qualité technique.
– Team Leader : cette personne est un leadeur d’équipe qui assurera que le travail de l’équipe est efficace dans son ensemble.
– Solution Developer : cette personne interprète les exigences du système et de modélisation. Il fera également le développement des codes livrables et la construction des prototypes..
– Solution Tester : cette personne testera l’application en tentant de trouver des bugs et documentera l’ensemble de ses trouvailles.
– Scribe : cette personne sera responsable de rassembler et d’enregistrer les exigences, les accords et les décisions prises au cours des workshop.
– Facilitateur : cette personne sera là pour animer les workshop et s’assurer de leur bon déroulement.
– Rôles spécialisés :  Business Architect, Quality Manager, System Integrator, etc.
La présence de rôles comme le Product Manager en fait une  méthode moins appréciée par les coachs agiles français.