BT

Guide de documentation pour les équipes utilisant le Domain-Driven Design

par Jan Stenberg , traduit par Jérémie Grodziski le 12 juin 2013 |

La première chose que devrait faire une équipe au démarrage d'un projet de développement logiciel, est de dessiner une context map qui l'aidera à comprendre son contexte et son core domain, ainsi que les autres contextes avec lesquels elle va interagir. La chose la plus importante est d'obtenir une compréhension partagée du domaine entre toutes les personnes impliquées dans le développement du logiciel. Le consultant et coach Paul Rayner explique en réponse à une question, quel type de documentation devrait produire les équipes utilisant du Domain-Driven Design, DDD.

Paul démarre par la fin en essayant de comprendre pourquoi nous faisons de la documentation; Quel rôle remplit chaque document ? Prenez en compte votre public et adaptez votre documentation à celui-ci. Est-ce que les lecteurs sont du côté technique ou métier ? Est ce une documentation technique ou métier ? comme l'écrit Paul : "Respectez votre public". Une autre question importante est relative au temps : est ce que ce document sert l'équipe au moment où elle développe le logiciel ? ou est il utile à un développement futur ?

Pour aider l'équipe durant le développement Paul suggère de favoriser la documentation (comme une activité, faite couramment et "juste à temps") qui favorisera des documents corrects et fiables plutôt que la création (une fois pour toute) d'un document. Pour les développements futurs, Paul considère la connaissance qui ne se trouve pas dans le code, les tests ou tout autre artefact particulièrement pertinent en tant que documentation. Sans ce type de connaissance documentée, personne ne connaît réellement comment le système en est arrivé là où il est; la connaissance est perdue.

Paul a remarqué que les équipes agiles préfèrent souvent une approche "légère" pour décrire ce que le système a besoin de faire au lieu de spécifications des besoins détaillées. Un des problèmes avec les spécifications détaillées est que les décisions de conception sont souvent prises trop tôt, avec une connaissance technique et du domaine insuffisante, séparant la conception de l'implémentation. Paul cite Mary Poppendieck:

Bien trop souvent, des listes de besoins détaillés et des backlogs de stories représentent en fait une mauvaise conception d'un système fait par des amateurs.

BDD

Paul est un grand fan de l'utilisation des outils BDD pour créer une documentation vivante du système. Il a un penchant vers Cucumber en tant qu'outil parce qu'il encourage la séparation de l'ubiquitous language et de l'implémentation technique.

Paul Rayner est un coach de conception expérimenté et un mentor en leadership, travaillant avec le DDD, BDD et les processus lean/agile. Paul a tenu une présentation durant le DDD Exchange 2012: Domain Scenarios to Drive Modelling Whirlpool.

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Contenu Éducatif

Rien ne serait possible sans le soutien et la confiance de nos Sponsors Fondateurs:

AppDynamics   CloudBees   Microsoft   Zenika
Feedback Général
Bugs
Publicité
Éditorial
InfoQ.com et tous les contenus sont copyright © 2006-2014 C4Media Inc. InfoQ.com est hébergé chez Contegix, le meilleur ISP avec lequel nous ayons travaillé.
Politique de confidentialité
BT