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.