Scrum & Agile

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

[English Version Below: « Definition of Done (DOD)… or when the « Go Live » sounds like fingers in the nose »]

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.

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

Definition of Done (DOD)… or when the « Go Live » sounds like fingers in the nose

légende
An example of « Definition of Done » or DOD.

Bob: « Okay, this is it, i have finished developing this module. Deployment is done ! »

Gerard: « Well, I can’t see nothing …? »

Bob: « On my workstation it works ! »

Come on, admit it … you’ve already lived such a drama isn’t it ? 🙂

One of the things I like in Scrum, and it my opinion it is one of its greatest strengths! I like that, when you said that a task or a User Story is done … well it is really done. In the case of an IT project, done means that stuff is developed, tested, documented, deployed on the test server etc. This is What Agile call the Definition of Done (DoD). The principle is simple: to switch a User Story in the column « Done » of the board, all the DOD criteria are met.

We sometimes use the term « Production Ready », meaning that once your User Story completed and validated by the client, it can potentially be put into production. No further action is required.

Documentation

Regarding the management of the documentation we try to apply some principles of « Lean ». I mean produce only documents with high added value. Often we can transform the question « do you have documentation? » in « what is you question ? What information are you looking for ? ». Then we provide the information. The idea is not to spend tens of days to produce documents quickly outdated. Warning! I’m not on trial with « doing documentation ». Documentation is useful but I think it is a means and not a goal to achieve. While i’m writing this paragraph I realize that this problem could be the subject of several articles.

Anyway the point is that i have a new crush about how we can do documentation… the use of video. Personally I use iShowU on the Mac that allows you to do video screenshots in a very simple way. I strongly believe in this: it is faster, more fun for the person who must « read » the document, easier to update.

The Go Live

The biggest slap that I receive using Scrum is how the production launch (i mean the go live) was …. cool! Yes you read it well. In fact, as we respect the DOD, as each month we did a demo to the client, the go live has been … just another sprint and no more. Since the deployment procedures were used for each sprint, the start of production was a simple roll on to another server.

Well now I will not lie to you … when the date of the go live comes close,  my pulse start to beats faster and faster and I expect problems and bad surprises. Our production launch has nevertheless taken a few hours and needed one or two minor manual adjustments. But honestly, in more than ten years of my career, I had never a go live o easy … and I must say that this was not to displease me.

Capitalizing on tests

Several points of the DOD concern testing, the advantage of writing tests is simple… When you are ready to deploy, you have a huge « set » of tests that can give you a good indicator of the quality of the release. In addition, for the next versions of your software, you can still use the « old » tests for the regression testing. By the way, i would like to thank the team with whom I worked. For the first time I did not have to « negotiate » the fact that we must write tests. They were all a lot « quality minded ». A member of the team had even developed a system requiring that all tests must be « green » to each commit … yes we are true psychopaths 🙂

Le "DOD" en contexte
DOD in context, don’t hesitate to update it on each « sprint review ».

Finally, DOD is a living document and his lifetime is the time line of the project, in the example of DOD that you find at the bottom of this post, you will see that we added some things during the project (allocation of user rights and negative error handling). We consider that DOD is so much important that we placed it in the middle of Paul (So we call our « Scrum » Board). See picture.
I would like to thanks Bob and Gerard 😉

Bruno.

More info: Example of Definition Of Done (ppt): Feel free to use it, just give me some credits.

5 commentaires

  • Autocollec

    J’ai un peu de mal à traduire la frontière entre DoD et recette fonctionnelle, notamment quand on évolue dans un écosystème applicatif et non plus sur une application propriétaire. J’ai également l’impression que les critères d’acceptance se cantonne généralement au cas nominal et occultent opportunément les cas non-passants …

    Exemple tout simple : le formulaire mail de contact …

    Criteres d’acceptance métier :
    – récupérer le nom fourni par l’émetteur
    – récupérer le titre de message fourni par l’émetteur
    – récupérer le corps de texte fourni par l’émetteur
    – récupérer la date d’envoi du mail
    – le mail est envoyé sur mon adresse toto@toto.com

    MAIS …. au final
    – quid de la longueur mini/maxi des champs ?
    – quid de la nature des champs (alpha, alphanumérique, numérique …) ?
    – quid de la validité de l’adresse mail fournie ?
    – Gestion des erreurs ?
    – Message de succès ou d’échec ?

    Pour un truc aussi basique qu’un formulaire mail, on voit qu’entre les critères d’acceptation émis par le métier, le job n’est OK que si plusieurs autres exigences sont à gérer. On imagine le dilemne quand on est sur une complexité plus élevée ….

    Alors tu vas me dire que mon US est Done si les critères métier sont OK. Et si à l’usage je découvre d’autres besoins pour mon formulaire mail , je reviens sur (x) nouvelle(s) itération(s) ….

    J’ai du mal à voir la valeur ajoutée dans ce cas …

    • brunosbille

      Bonjour à vous,

      Votre message contient beaucoup de questions et de sous questions, il pourrait y en avoir pour des heures de discussions (chose que j’adore !) Je vais essayer néanmoins de vous donner quelques pistes.

      Dans votre message il y je pense un peu de confusion au niveau du DOD, des critères d’acceptance et de la responsabilité d’une Dev Team dans Scrum.

      Le DOD s’applique à toutes les User Stories

      Par exemple:
      – les écrans doivent correspondre à la charte graphique
      – 85% du code au moins est couvert par des tests
      – c’est prêt pour la démo

      Le critère d’acceptance est lui spécifique à la US
      En IT 90% des tests sont faits par la dev team, les tests d’acceptances c’est le client qui teste légèrement pour voir si ce que vous lui donnez lui convient

      Imaginons que vous achetiez un smartphone. En ouvrant la boite inconsciemment vous faites des tests d’acceptance pour voir si vous êtes satisfait de votre achat
      – Vous regardez s’il n’y a pas de griffe sur l’écran
      – est-ce que la couleur annoncée est la bonne
      – est-ce que je peux passer un appel
      – est-ce que la synchro s’effectue
      Si la réponse est oui à tout je suis satisfait de mon achat.

      Les critères d’acceptance par exemple pour une US « réserver une chambre d’hôtel » ou « réserver une salle de réunion dans l’hôtel » vont être différents

      Par rapport à la responsabilité de la dev team dans un contexte Scrum. La dev team s’engage à faire les choses de manière qualitative. A condition bien entendu qu’on lui permette de le faire.

      Par exemple ceci: – récupérer le nom fourni par l’émetteur
      – récupérer le titre de message fourni par l’émetteur
      – récupérer le corps de texte fourni par l’émetteur
      – récupérer la date d’envoi du mail

      Ce ne sont pas des critères d’acceptance, c’est ce qu’on doit faire

      Reprenons mon exemple de réserver une chambre d’hôtel.

      Dans une optique Scrum le métier n’a pas à préciser: la date de début doit être avant la date de fin.
      C’est évident et l’équipe doit s’assurer que ce sera le cas. C’est l’engagement sur la qualité.
      De même il ne peut pas y avoir de 30 février dans l’agenda, c’est à l’équipe de le vérifier.

      Le risque de travailler comme vous le suggérer c’est que l’équipe ne pas tester que les critères d’acceptance.

      Enfin pour votre question:

      MAIS …. au final
      – quid de la longueur mini/maxi des champs ?
      – quid de la nature des champs (alpha, alphanumérique, numérique …) ?
      – quid de la validité de l’adresse mail fournie ?
      – Gestion des erreurs ?
      – Message de succès ou d’échec ?

      Ceci devrait être défini en amont, at ajouté au DOD.

      par exemple: pour la longueur des champs, on se référence à notre base de donnée XXXXX qui est la référence des RH pour la longeur des champs

      Si le client dit: »je veux l’email de l’utilisateur » c’est évident que le client veut un email correct. Il n’a pas à la préciser.

      C’est un peu comme si vous achetiez une voiture, vous n’allez pas préciser « je veux que les freins fonctionnent » c’est évident pour vous.

      Voilà j’espère que ma réponse vous aide ou au moins vous donne matière à réflexion.

      Merci de m’avoir soumis ces questions j’ai trouve ça intéressant.

      Je vais la poster sur ma page Facebook, peut-être d’autres personnes voudront commenter.

      Ma page FB: https://www.facebook.com/ScrumBelgium/

      Si vous voulez en apprendre plus sur Scrum je vous suggère ce livre (gratuit): https://www.infoq.com/fr/minibooks/scrum-xp-from-the-trenches/

      Bye,

      Bruno.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.