Qu’est-ce que DSDM (Méthode de Développement des Systèmes Dynamiques) ?
Qu'est-ce que DSDM ?
La méthode de développement de systèmes dynamiques (DSDM) est un cadre agile de gestion de projet qui a vu le jour en 1994 et était, à l'époque, utilisée pour le développement logiciel. Elle visait à améliorer le développement rapide d'applications (RAD), qui privilégiait le prototypage rapide et l'itération basée sur les retours des utilisateurs. Comme beaucoup de méthodes agiles, le cadre DSDM Agile Project Framework est passé d'une solution exclusivement logicielle à un outil de gestion de projet plus généraliste.
Les éléments de la méthode de développement de systèmes dynamiques incluent :
- Se distingue des autres méthodes par sa dépendance à de solides bases et une gouvernance forte
- Approche incrémentale et itérative de la progression
- Les retours des utilisateurs ou des clients sont essentiels pour des améliorations continues
- Repose sur des contraintes strictes de coûts, de qualité et de temps
- Hiérarchise le périmètre selon Must Have, Should Have, Could Have ou Won’t Have
Au-delà de la pratique elle-même, DSDM a également conduit à la création du Consortium DSDM en 1994. Des ingénieurs logiciels et d'autres experts se sont réunis pour développer et améliorer le cadre en tant qu'alternative valable face aux méthodes de développement rapide d'applications plus courantes. À l'époque, le groupe comptait parmi ses membres des représentants de British Airways, American Express, Oracle, Logica, Data Sciences et Allied Domecq. Le groupe s'est depuis rebrandé et s'appelle désormais le Agile Business Consortium.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Le Manuel DSDM a été rendu gratuit à la consultation et à l'usage en ligne en 2014.
DSDM vs RAD vs Agile
La méthodologie RAD était très populaire au début des années 1990 en tant que méthode de développement de systèmes pour les logiciels et autres projets informatiques. À cette époque, il y a eu un passage de l'UX traditionnelle « écran vert » aux interfaces graphiques qui sont désormais synonymes de toute technologie. Ce changement signifiait que le cycle de développement pouvait évoluer, utilisant ce nouveau type d'interface visuelle pour communiquer, prototyper rapidement et itérer.
La méthodologie RAD était en quelque sorte un système de développement agile chaotique. Elle ne possédait aucune approche ni définition unique. La DSDM agile était une approche plus structurée de ce type de modèle de développement logiciel. La méthode de développement de systèmes dynamiques mettait un accent particulier sur les budgets de temps et de coût grâce à une priorisation stricte du périmètre. Elle accorde également une priorité à la communication (et aux actions qui en résultent) entre toutes les parties prenantes.
Non seulement DSDM est stricte sur les délais et le budget, mais elle tend également à avoir un ordre d'exécution précis : phase pré-projet, phase cycle de vie du projet et phase post-projet. Les méthodes de développement RAD sont davantage axées sur le travail libre, laissant la créativité et l'indépendance dominer même au détriment de la consommation des ressources.
Scrum vs DSDM
Scrum et DSDM partagent de nombreuses similitudes mais présentent également quelques différences importantes. Certaines ne concernent que la terminologie : par exemple, DSDM divise le travail entre l’« activité d’ingénierie » (c'est-à-dire la phase de développement) et la « solution émergente » (c'est-à-dire le livrable). Tandis qu’avec Scrum, le livrable est appelé « incrément potentiellement livrable ».
Les deux méthodes comportent des listes de sous-tâches à réaliser dans le respect de délais serrés. Les deux méthodologies visent également à aboutir à un projet terminé, que Scrum signale une fois que le projet atteint la « Définition de Terminé ». Cependant, il n'y a pas de moment précis dans le projet où cette « Définition de Terminé » est convenue. C’est la différence clé entre Scrum et DSDM.
Dans DSDM, il existe une phase spécifique durant laquelle la définition du travail (et du travail achevé) est validée : la phase Fondation du projet. Cela intervient assez tôt, ce qui peut parfois signifier que des hypothèses non vérifiées colorent le processus de planification. Pour pallier cela, la définition du travail « fini » doit être revue périodiquement tout au long du cycle de vie du projet. Un autre point d'attention est que les chefs d’équipes doivent éviter le « Big Design Up-Front » (BDUF), qui est plus caractéristique des méthodologies en cascade que de l’Agile.
Principes DSDM
Les principes agiles DSDM sont la force directrice derrière chaque projet. Ils sont au nombre de 8.
- Se concentrer sur le besoin métier
- Livrer à temps
- Collaborer
- Ne jamais compromettre la qualité
- Bâtir de façon incrémentale sur des bases solides
- Développer de façon itérative
- Communiquer de façon continue et claire
- Démontrer la maîtrise
Techniques et Pratiques DSDM
Ce qui fait que DSDM se distingue des autres méthodes de développement de systèmes, ce sont les techniques et pratiques suivantes.
La technique du timeboxing : DSDM respecte des standards stricts de délais. Pour ce faire, il faut décomposer l’ensemble du projet en éléments plus petits, chacun ayant un budget et une période bien définis. Pour gérer cela, il est nécessaire de hiérarchiser les exigences. Si le temps ou l’argent commence à manquer, les exigences de plus faible priorité sont supprimées. Le projet abouti résulte alors uniquement des éléments d’exigence les plus essentiels.
MoSCoW : Il s’agit des groupes de priorisation utilisés pour classer les éléments du plus haut niveau d’importance au plus faible. Les groupes de priorisation sont Must Have (Doit avoir), Should Have (Devrait avoir), Could Have (Pourrait avoir) et Won’t Have (N’aura pas). La gestion de configuration aide à encadrer tous ces livrables concurrents, souvent développés simultanément.
Modélisation et développement itératif : La modélisation permet de visualiser différents aspects du projet tout au long du processus. Cela aide à présenter chaque élément en cours de développement et à permettre un développement itératif grâce à des retours réguliers et à l’implémentation d’améliorations.
Prototypage : Comme pour de nombreuses méthodologies agiles, le prototypage est essentiel pour tester le projet dès une phase conceptuelle précoce. C’est un moyen de cartographier les fonctions de base, de découvrir les faiblesses flagrantes et de permettre aux utilisateurs de tester le logiciel.
Ateliers : Les utilisateurs et parties prenantes sont réunis pour discuter des exigences, des problèmes, des résultats et des tests. DSDM s’appuie sur un haut niveau d’interaction utilisateur, dès le début du projet. Les tests sont d’une importance capitale pour DSDM, car ils garantissent des résultats de grande qualité.
Les rôles dans DSDM
Tout développement de systèmes agile comprend une liste de rôles à pourvoir. DSDM ne fait pas exception. Selon leur guide, voici les rôles essentiels de tout environnement DSDM.
1. Parrain exécutif (le « Champion du projet ») - L’organisation utilisatrice et/ou le client désignera une personne pour ce rôle. Il s’agit également de la personne habilitée à allouer les fonds et les ressources nécessaires. C’est le « décideur final » en matière de prise de décision.
2. Visionnaire - Doté d’objectifs concrets et d’une compréhension du métier utilisateur, le Visionnaire initie le projet en identifiant très tôt les exigences de plus haute priorité et en guidant l’équipe sur cette base.
3. Utilisateur Ambassadeur - Un « utilisateur test » idéal qui apporte le point de vue de la communauté d’utilisateurs au projet. Il devient une source clé de retours tout au long du processus.
4. Utilisateur Conseiller - Un autre type d’utilisateur appelé à apporter les points de vue essentiels pour le projet. Il peut posséder des connaissances spécifiques ou une expertise particulière qui en fait la personne idéale.
5. Chef de projet - Un chef de projet est toute personne chargée de gérer l’ensemble du projet.
6. Coordinateur technique - Il conçoit l’architecture du système et veille au contrôle de la qualité de tous les aspects techniques.
7. Chef d’équipe - Le responsable de l’équipe, chargé de la coordination et de la facilitation de la collaboration.
8. Développeur de la solution - Il prend en charge toutes les exigences du système, modélise le système, développe les codes livrables et réalise les prototypes.
9. Testeur de la solution - Teste le produit et fournit des commentaires ainsi que de la documentation lors de la détection d’erreurs. Il effectue également une nouvelle série de tests après correction des anomalies.
10. Secrétaire (scribe) - Consigne les exigences, accords, décisions et toutes autres informations utiles à l’avancement du projet.
11. Facilitateur - Il est responsable de la motivation et de la préparation de l’atelier afin de maintenir une progression constante et régulière. Il doit être un excellent communicateur pour veiller à ce que tous restent sur la bonne voie.
12. Rôles spécialisés - Ces rôles sont tenus par des spécialistes de leur domaine ou secteur, fournissant un support supplémentaire selon les besoins du projet. Ils peuvent varier d’un projet à l’autre et d’une équipe à l’autre. Ce type de rôle peut inclure Architecte métier, Responsable qualité, Intégrateur de systèmes, et plus encore.
Conseils de gestion de projet DSDM
Ces conseils peuvent vous aider à tirer le meilleur parti de votre projet DSDM, même si tous les systèmes agiles peuvent également bénéficier de ces pratiques.
1. La direction générale et l’ensemble des employés doivent comprendre et adhérer à la méthodologie choisie pour le projet.
2. L’équipe en charge du projet doit s’engager dans des tests utilisateurs, des retours d’expérience et une implication sur l’ensemble du processus, de la conception au lancement.
3. Il doit exister une équipe projet centrale stable et responsabilisée. Les membres de l’équipe doivent avoir le pouvoir décisionnel nécessaire pour éviter que les processus ne s’enlisent dans des démarches de propositions et d’approbations inutilement complexes. L’équipe doit également disposer de tous les moyens nécessaires pour fonctionner : la bonne technologie, un environnement de développement sain, des outils de gestion de projet, etc.
4. Il doit exister une relation de soutien et proactive entre le client et le fournisseur, que les projets soient développés en interne ou externalisés.
5. L’équipe doit faire preuve de courage lorsqu’il s’agit de hiérarchiser honnêtement les besoins du projet et d’abandonner, si nécessaire, les éléments de faible priorité. C’est ainsi que l’on respecte les délais et le budget.
