Definition of Done (DOD)… ou quand la mise en production devient une formalité…

Un exemple de "Définition of Done" ou DOD.

Bob: « Voilà j’ai terminé de développer ce module, c’est déployé ! »

Gérard: « Ben je vois rien…? »

Bob: « Ha en tout cas chez moi ça marche… »

Allez, avouez…vous avez déjà tous vécu ce drame non ? :-)

Une des choses que j’aime dans Scrum, et c’est selon moi une de ses plus grandes forces ! C’est que quand une tâche, ou disons une User Story, est terminée…et bien elle est vraiment terminée.  Dans le cas d’un projet IT, j’entends par là que c’est développé, testé, documenté, déployé sur le serveur de test etc… C’est ce que l’on appelle en Agile le Definition of Done (DOD). Le principe est simple pour mettre une User Story dans la colonne « Done » du tableau, il « suffit » que tous les critères du DOD soient remplis.

On utilise parfois le terme de « Production Ready », c’est à dire qu’une fois votre User Story terminée et validée par le client, elle peut être potentiellement mise en production. Plus aucune action n’est nécessaire.

Documentation

Concernant la gestion de la documentation nous essayons d’appliquer certains principes « Lean » à savoir ne produire que des documents à haute valeur ajoutée. Bien souvent nous arrivons à transformer la question « avez-vous de la documentation ? » en « mais que recherchez-vous comme information ? ». Ensuite nous fournissons l’information. L’idée est de ne pas passer des dizaines de jours à produire des documents rapidement dépassés. Attention ! Je ne fais pas le procès de la documentation elle est utile mais selon moi avec parcimonie. En écrivant ce paragraphe je me rends compte que cette seule problématique pourrait faire l’objet de plusieurs articles.

Tout ça pour vous dire que mon nouveau cheval de bataille pour la Doc c’est… l’utilisation de la vidéo. Personnellement j’utilise iShowU sur Mac qui permet de faire très simplement des vidéo de captures d’écran. J’y crois fermement: c’est rapide, plus amusant pour la personne qui doit prendre connaissance de la doc, plus facile à mettre à jour.

La mise en production

La plus grosse claque que je me suis pris en utilisant Scrum c’est à quel point la mise en production a été …. cool ! Oui vous lisez bien. En fait, vu que nous respections le DOD, vu que chaque mois nous faisions une Démo au client, la mise en production n’a été…qu’un sprint de plus. Vu que les procédures de déploiement étaient utilisées à chaque sprint, la mise en production a été un simple déploiement sur un autre serveur.

Bon maintenant je ne vais pas vous mentir… le jour de la mise en production mon pouls bat toujours plus vite et je m’attends à ce qu’il y ait des problèmes. Notre mise en production a quand même pris quelques heures et nécessité un ou deux légers ajustements manuels. Mais en toute sincérité, en plus de 10 ans de carrière, je n’avais jamais eu de mise en production aussi calme…et je dois dire que ce n’était pas pour me déplaire.

Capitaliser sur les tests

Plusieurs points du DOD portent sur le testing, l’avantage d’écrire les tests au fur et à mesure est qu’au moment de la mise en production vous avez un énorme « set » de tests qui peuvent vous donner un bon indicateur de la qualité de la release. De plus pour les releases suivantes, nous disposons d’autant de tests de régression. A ce sujet je voudrais remercier l’équipe avec qui j’ai travaillé car pour la première fois je n’ai pas dû « négocier » le fait qu’il fallait faire des tests. Un membre de l’équipe avait même mis au point un système obligeant que tous les tests soient « vert » à chaque commit…oui nous sommes de vrais psychopathes :-)

Le "DOD" en contexte
N'hésitez pas, lors des "sprint review", à faire évoluer ce document

En conclusion, Le DOD est un document à faire vivre tout au long du projet, dans l’exemple de DOD que vous trouverez au bas de cet article vous verrez que l’on a rajouté certaines choses en cours de projet (attribution des droits utilisateurs et gestion des erreurs d’indisponibilité). Nous le considérons à ce point important que nous l’avons placé en plein milieu de Paul (C’est ainsi que nous appelons notre Tableau « Scrum »). Voir ci-contre.

Merci principalement à Bob et Gérard ;-)

Bruno.

Plus d’infos:

Article sur le Definition Of Done (en)

Un exemple de Definition Of Done (ppt): Un exemple de Definition of Done (ppt), n’hésitez pas à l’utiliser merci simplement de citer les crédits.



This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.

Claude Aubry

Bonne publicité pour cette pratique essentielle pour la qualité. En tant que défenseur de la francophonie, je regrette l’utilisation du terme anglais, alors que la traduction n’est pas trop difficile. Je l’appelle Signification de fini (SDF! ).

brunosbille

Bonjour Claude et merci pour ton commentaire !

Je comprends ton commentaire et en toute sincérité je respecte les gens qui combattent pour que le français reste une langue « forte ». Même si dans ce cas le terme SDF peut être mal perçu :-)

Sinon ici en Belgique…un pays dont la complexité est inversément proportionnelle à sa taille ;-) Comme nous avons 3 langues nationales, il est parfois de bon ton d’utiliser l’anglais afin de ménager les susceptibilités.

Je me permets de faire la pub pour ton blog: à mes lecteurs n’hésitez pas à visiter http://www.aubryconseil.com/ !

Bruno

Tom

Bonjour Bruno,

super! cet article est inspirant et du coup avec l’equipe on a reflechit à notre DOD (en se limitant au DODD, definition of development done ;) )
voici les retours:
1) tout les requirements liés sont couverts
– recomparer par rapport aux analyses (et oui on a des analyses…)
– revoir avec l’analyste functionel
2) le code est unit testé
– le unit testing fait partie de la responsabilité du dvp, à lui de décider si ils ont une valeurs ajoutés pour chaque methode…..
3) basic testing ok (objectif pas de defect blocking une fois en environnement de tests)
– revoir les tests basiques avec l’analyste avant de deployer
4) suivre la procedure clearcase pour le commit du code
– et oui on utilise ce fabuleux outil qu’est clearcase., la procedure est un bien grand mot pour decrire les etapes pour delivrer son code sans impacter les autres et c’est un autre sujet…
5) Doc technique, mise à jour….

voilà rapidement un autre retour d’experience en esperant qu’il est utlie… ;)

Bruno

Merci pour ton retour Tom !

J’aime bien l’idée du DODD un bon compromis si tu ne peux pas aller plus loin.

J’aime bien aussi l’idée de responsabiliser le développeur sur les Unit Tests

J’ai déjà utilisé clearcase et je me demandais si ton « fabuleux » était ironique ou pas :-)

Merci pour le retour ! Et OUI ça aide !

Bruno

Sebastien Arbogast

Personnellement j’ai aussi tendance à rajouter de l’analyse statique à ma DOD: des trucs comme Findbugs en Java, ou les outils d’analyse de certains IDE permettent de détecter certains bugs potentiels que les tests auront laissé passer (et oui les tests unitaires c’est comme les préservatifs: il suffit d’une fuite), tout en améliorant la qualité du code: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Un autre élément important ce sont aussi les code reviews et le refactoring (ouh la débauche d’anglicismes). J’ai vu des équipes agiles ou aucun code n’était committé avant d’avoir été revu par au moins une personne. Et souvent le code review mène à un refactoring. De manière générale, un développeur n’écrit jamais du bon code du premier coup, surtout quand il y a des tests unitaires, parce que son objectif est d’abord et avant tout de faire passer le test. Or le test ne contrôle pas la lisibilité, la maintenabilité ou la performance du code. C’est là que faire revoir son code par un autre membre de l’équipe aide beaucoup.

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *