Un exemple de Définition du Fini
Auteur : Peter Stevens
Source : Sample Definition of Done
Date : 19/11/2012
Traducteur : Fabrice Aimetti
Date : 24/11/2012
Traduction :
Pourquoi Scrum dispose t'il d'une Définition du Fini ? C'est simple, toutes les personnes impliquées dans le projet ont besoin de savoir et de comprendre ce que Fini veut dire. En outre, le Fini doit être vraiment fini, par exemple : "rien ne nous empêche de bénéficier de la valeur de cette fonctionnalité, sauf peut-être le feu vert du Product Owner". Une autre situation serait :
Chef de projet : Est-ce que cette fonctionnalité est finie ?
Développeur : Oui
Chef de projet : Donc, nous pouvons la déployer ?
Développeur : Eh bien, non. Elle doit être testée, et j'ai besoin de rédiger de la documentation, mais le code fonctionne vraiment. Je l'ai testé ... (pause) ... sur ma machine.
Qu'est-ce qui ne va pas dans cet échange ? Pour le développeur et le chef de projet, "fini" signifie quelque chose d'assez différent. Pour le développeur, dans ce cas, fini signifie : "Je n'ai plus à travailler sur ce code (sauf si le testeur me dit que quelque chose est faux)." Le chef de projet est à la recherche d'un code qui soit prêt à être déployé.
À son niveau le plus élémentaire, une Définition du Fini crée une compréhension commune de ce que signifie être fini, de telle façon que tout le monde dans le projet donne le même sens aux choses quand ils disent "c'est fini". Plus subtilement, la Définition du Fini est une expression des standards de qualité de l'équipe. Une définition plus rigoureuse du Fini sera associée à un logiciel de meilleure qualité. En règle générale, l'équipe va devenir plus productive ("avoir une plus grande vélocité") au fur et à mesure que sa Définition du Fini devient plus stricte, car elle passera moins de temps à résoudre les anciens problèmes. Le risque de refaire les choses disparaît presque.
Ainsi, la Définition du Fini devrait évoluer à mesure que le projet avance. Voici la première Définition du Fini qu'a utilisée mon équipe lorsque nous avons commencé à développer l'application HappinessApp :
- Tests unitaires écrits et passés au vert
- Code source commité sur le serveur
- Build Jenkins de la version est ok et tous les tests passés au vert
- Revue de code terminée (ou code pair-programmé)
- Démo préparée et vérifiée avant présentation au Product Owner
- Ok du Product Owner
Pour chaque élément du Backlog Produit ("story"), mon équipe et moi avons convenu d'un workflow pour montrer que la story a été mise en œuvre correctement. Nous appelons cela "comment-faire-la-démo". Plus subtilement, la combinaison du titre de la story et du comment-faire-la-démo limite le périmètre de le story et empêche son extension lors du sprint !
Cette définition nous a bien servi jusqu'à ce que nous commencions à livrer notre bêta-test aux clients, à commencer par moi. Je suis le premier client. Nous avons donc amélioré la définition du fini comme suit :
- Build potentiellement livrable et disponible au téléchargement
- Liste des changements mise à jour pour tenir compte des fonctionnalités récemment implémentées
- Fonctionnalités inactives/non implémentées cachées ou grisées (non exécutable)
- Tests unitaires écrits et passés au vert
- Code source commité sur le serveur
- Build Jenkins de la version est ok et tous les tests passés au vert
- Revue de code terminé (ou code pair-programmé)
- Démo préparée et vérifiée avant présentation au Product Owner
- Ok du Product Owner
Très rapidement, nous avons découvert qu'une mise à jour sur un iPhone écrasait les données des utilisateurs. Ce qui est très mauvais (notamment pour une application agenda !), donc nous avons ajouté un autre point :
- Mise à jour vérifiée tout en gardant les données utilisateur intactes.
- Build potentiellement livrable et disponible au téléchargement
- Liste des changements mise à jour pour tenir compte des fonctionnalités récemment implémentées
- Fonctionnalités inactives/non implémentées cachées ou grisées (non exécutable)
- Tests unitaires écrits et passés au vert
- Code source commité sur le serveur
- Build Jenkins de la version est ok et tous les tests passés au vert
- Revue de code terminé (ou code pair-programmé)
- Démo préparée et vérifiée avant présentation au Product Owner
- Ok du Product Owner
Cette version a assez bien marché sur les 8 sprints suivants jusqu'à ce que nous terminions le développement de la version bêta. Nous avons expérimenté deux autres points inspirés par Release It, le guide pour concevoir et déployer des logiciels prêts à être déployés en production :
- Revue de conception -> liste des cas d'échec comment-cette-fonctionnalité-pourrait-échouer (au minimum 3)
- Identification des cas d'échec couverts par les décisions de conception ou les tests unitaires
Nos développeurs ont eu des difficultés avec ces deux points, nous avons donc décidé de les mettre de côté (jusqu'à ce que quelque chose d'important casse et que, j'ai, en tant que Product Owner, la base pour une discussion avec l'équipe ;-)
Rétrospectivement, la Définition du Fini et les pratiques d'ingénierie qu'elle implique nous a bien servi. Le produit a été remarquablement exempte de problèmes techniques, l'équipe a ainsi atteint la proverbiale "réussite technique". La prochaine étape pour nous est de sortir le produit et de faire que cela devienne un véritable succès.
La Définition du Fini est importante en Scrum, mais il y a de nombreuses facettes à prendre en compte dans le fini, et la Définition du Fini n'en couvre que quelques-unes. "Que voulez-vous dire par fini ? Seules deux petites fonctionnalités ont été implémentées ! Avant que nous puissions l'appeler fini, les 150 fonctionnalités devront être implémentées !" J'ai prévu de revisiter ce sujet dans un prochain article, provisoirement intitulé "Les Trois Facettes du Fini." Dans le même temps, mes étudiants CSM (pour lesquels cet article a été écrit) pourront vous l'expliquer !
