Le « Definition of ready » (DoR) ou en français, « Définition du Prêt » est une étape clé dans le processus « Quality by Design » que nous avons présenté dans un précédent article.
Les objectifs du « Definition of Ready »
Le « Definition of Ready » a pour objectif de définir les critères pour considérer un élément éligible pour être embarqué dans un sprint. Un élément peut être une Story, un Bug, une tâche ou tout autre type de « ticket » associé au travail de l’équipe projet. Il s’agit donc d’éviter de commencer à travailler alors que le développeur ne dispose pas de tous les éléments car cela risquerait d’entraîner de coûteux allers-retours entre le développeur, le testeur et le Product Owner ou PO.
L’équipe projet explicite et rend visible les critères (généralement une déclinaison de la grille INVEST) faute desquels une fonctionnalité ne saurait faire l’objet d’un travail au cours de l’itération qui commence.
*INVEST: INDÉPENDANTE, NÉGOCIABLE, VALEUR AJOUTÉE, ESTIMABLE, SUFFISAMMENT PETITE, TESTABLE
Les bénéfices de l’utilisation du « Definition of Ready »
En commençant le traitement d’une story qui a respecté les critères du DoR, le testeur et le développeur peuvent avancer sereinement dans leurs travaux respectifs. Le développement de la fonctionnalité est bien cadré, l’estimation bien faite, le livrable devrait correspondre à ce qui a été estimé.
« Définition of Ready » d’un projet de développement logiciel
Dans cette section, nous allons présenter un exemple de conditions et règles à respecter pour pouvoir appliquer le DoR sur un projet de développement logiciel.
Le projet en question est composé d’un backend avec un objectif le développement des API REST et un frontend en React JS. Nous supposons que l’équipe projet utilise un outil de gestion de tickets tel que Jira.
Cinq critères d’éligibilité sont à appliquer sur ce projet :
1- Créer les critères d’acceptance : Les critères d’acceptation devraient être rédigés dans la story. Les critères d’acceptance couvrent le périmètre de la fonctionnalité souhaitée. Le Product Owner est le responsable de cette étape car il a la vision produit et peut faire la collecte d’informations auprès des autres équipes : marketing, sales, support etc.
Nous recommandons d’appliquer le Behaviour Driven Development (BDD) pour créer les critères d’acceptance.
2- Valider des critères d’acceptance: La revue de chaque critère d’acceptation par deux membres de l’équipe projet :
– un testeur
– un développeur
Cela permet de partager les questions et de clarifier les zones d’ombre. L’objectif étant d’aligner les 3 amigos (Développeur, testeur et Product Owner) sur le besoin décrit dans la story.
Une fois la revue terminée et les critères d’acceptance mis à jour, la personne qui a fait la revue ajoute un commentaire « Acceptance criteria – approved »
3- Étudier l’impact sur la Base de données et la partie API : Après étude, le développeur backend ajoute l’impact identifié et le périmètre du changement à faire dans un commentaire. Un second développeur doit faire la revue et approuver dans un commentaire « Backend – scope approved ».
4- Valider le wireframe : Si le développement requiert un changement frontend, le développeur frontend prend en charge la validation du wireframe. Suite à l’échange avec le Product Owner, il est possible de mettre à jour le wireframe. Par la suite, approuver le wireframe en ajoutant dans un commentaire de la story « Wireframe – approved ».
5- Etudier l’impact sur l’application côté Frontend : Le développeur frontend ajoute un commentaire avec le résumé des changements. Un second développeur doit vérifier et approuver l’impact et le changement proposé « Frontend – scope approved »
Dans cet article nous avons présenté le Definition of Ready. Le respect des critères listés ci-dessus par le testeur, le développeur et le PO peut être considéré comme fastidieux et chronophage. Mais l’application des bonnes pratiques rendra la tâche plus facile et apportera plus de réussite dans un projet Agile.