La Definition of Ready : avantages et dangers

Moins utilisée que la Definition of Done, la Definition of Ready est employée par certaines équipes pour déterminer quels éléments du Product Backlog peuvent être intégrés dans une itération.

Tu peux imaginer la Definition of Ready comme un videur imposant posté devant la porte de la prochaine itération. Tout comme un videur qui ne laisse entrer que certaines personnes dans le club – les jeunes, branchés et bien habillés – la Definition of Ready ne laisse passer que certaines User Stories dans l'itération.

Et tout comme un club peut décider lui-même qui les videurs peuvent laisser entrer ou non, chaque équipe ou organisation peut définir sa propre Definition of Ready. Il n'existe pas de Definition of Ready universelle valable pour toutes les équipes.

Un modèle pour la Definition of Ready

Quel type de stories notre videur pourrait-il donc laisser entrer dans l'itération ? Il pourrait par exemple laisser passer des stories qui remplissent ces critères ou des critères similaires :

• Les Conditions of Satisfaction pour la story concernée ont été entièrement définies.

• La story a été estimée et a une taille maximale définie. Si l'équipe travaille par exemple avec des Story Points, les membres de l'équipe définissent un certain nombre de Story Points et n'autorisent que les stories correspondant à ce nombre ou plus petites à être intégrées dans l'itération. Cette taille maximale correspond souvent à environ la moitié de la Velocity de l'équipe.

• Le designer d'interface utilisateur a déjà créé une maquette ou le design complet des écrans liés à la story.

• Les dépendances externes ont été éliminées, qu'il s'agisse de dépendances internes ou externes à l'équipe.

Une Definition of Ready définit les conditions préalables

Une Definition of Ready permet à l'équipe de définir des critères qui doivent être remplis avant qu'une story puisse être intégrée dans une itération. L'objectif est d'éviter les problèmes avant même qu'ils n'aient la chance de survenir.

Dire que seules les stories jusqu'à une taille maximale définie peuvent être intégrées dans une itération empêche par exemple qu'une story soit commencée alors qu'elle est trop grande pour être terminée en une seule itération.

De même, ne pas accepter dans l'itération une story qui présente des dépendances externes peut protéger contre le fait que ces dépendances mettent en péril la story ou l'itération entière si l'autre équipe ne parvient pas à tenir son engagement.

Imagine par exemple que ton équipe dépende parfois du fait qu'une autre équipe termine d'abord une partie du travail. Tes user stories ne peuvent donc être terminées que si l'autre équipe a fait son travail – et ce à temps pour que ton équipe ait encore la chance d'intégrer ces éléments.

Si cette équipe a déjà régulièrement laissé tomber ton équipe parce qu'elle n'a pas terminé quelque chose au moment où elle l'avait promis, il serait logique que ton équipe décide de ne plus intégrer de stories dans une itération pour lesquelles il existe encore une dépendance non résolue avec l'autre équipe.

Une Definition of Ready stipulant que toutes les dépendances externes doivent être éliminées avant qu'une story puisse être intégrée dans l'itération pourrait être judicieuse pour une telle équipe.

Une Definition of Ready n'est pas toujours une bonne idée

Certaines règles de notre videur sont donc manifestement une bonne idée. Par exemple, je n'ai aucun problème si une équipe décide qu'aucune story dépassant une certaine taille ne peut être intégrée dans une itération.

Cependant, certaines règles que je vois fréquemment dans la Definition of Ready peuvent causer des problèmes – de gros problèmes. Laisse-moi t'expliquer.

La Definition of Ready est comme la porte d'entrée de l'itération. Des règles sont établies et notre videur veille à ne laisser entrer que les stories qui correspondent à ces règles.

Si ces règles stipulent entre autres que quelque chose doit être terminé à 100 % avant qu'une story puisse être intégrée dans l'itération, la Definition of Ready devient un pas assez important vers une approche séquentielle de type Stage-Gate. Cela empêche l'équipe d'être agile.

Une Definition of Ready peut mener à des étapes et des points de contrôle

Permettez-moi de vous expliquer brièvement. Une approche Stage-Gate se caractérise par une série de phases (stages) pour le développement. De plus, l'approche Stage-Gate définit ce qu'on appelle des portes (gates) ou points de contrôle. Les travaux ne peuvent passer d'une phase à la suivante qu'en franchissant une porte.

Quand j'étais petit, ma mère utilisait une approche Stage-Gate pour le dîner. Je n'avais droit au dessert que si j'avais fini mon assiette. Je n'avais pas le droit de manger le dîner et le dessert en même temps.

Pour illustrer avec un exemple de développement produit, imaginez un processus avec des phases distinctes de conception et de codage. Pour passer de la phase de conception à la phase de codage, les travaux doivent franchir une porte de revue de conception. Cette porte est censée garantir l'exhaustivité et la rigueur du travail effectué dans la phase précédente.

Donc, si une Definition of Ready contient une règle stipulant que quelque chose doit être terminé avant qu'autre chose puisse être commencé, cela rapproche dangereusement l'équipe d'un processus Stage-Gate. Et cela va nuire à la capacité de l'équipe à être agile. Car une approche Stage-Gate n'est qu'un autre terme pour désigner un processus en cascade.

Les équipes Agile devraient pratiquer le développement simultané

Dès qu'une tâche ne peut pas être commencée avant qu'une autre ne soit terminée, le travail de l'équipe ne peut plus se faire simultanément. Or, l'exécution simultanée des travaux est l'un des indicateurs les plus évidents qu'une équipe est agile. Une équipe agile devrait toujours effectuer un peu d'analyse, de conception, de tests et de codage en même temps. En intégrant des portes dans le processus de développement, on empêche précisément cela.

Les équipes agiles devraient pratiquer le développement simultané où les différentes activités nécessaires à la livraison de logiciels fonctionnels se chevauchent. Des activités comme l'analyse, la conception, l'écriture de code et les tests ne se dérouleront jamais complètement en même temps – et ce n'est d'ailleurs pas l'objectif. L'objectif est simplement que ces activités se chevauchent autant que possible.

En exigeant que certaines activités soient terminées à 100 % dans une approche Stage-Gate, on empêche le démarrage d'autres activités. Et une Definition of Ready peut mener directement à une telle approche Stage-Gate si de telles règles y sont intégrées.

C'est pourquoi je recommande à la plupart des équipes de ne pas travailler avec une Definition of Ready. C'est souvent un effort inutile. Et ce qui est encore pire, cela peut représenter un grand pas en arrière dangereux vers un processus en cascade.

Dans certains cas cependant, une Definition of Ready peut effectivement résoudre des problèmes et mériter d'être utilisée.

Bien utiliser la Definition of Ready

Pour utiliser efficacement la Definition of Ready, tu devrais éviter les règles qui exigent que quelque chose soit terminé à 100% avant qu'une story puisse être intégrée à l'itération – peut-être à l'exception des dépendances envers certaines équipes ou fournisseurs. De plus, tu devrais privilégier des lignes directrices plutôt que des règles strictes dans ta Definition of Ready.

Voici un exemple de règle que l'équipe devrait reformuler : « Chaque story doit disposer de maquettes détaillées pour tous les nouveaux écrans. »

Une telle règle représente une barrière. Elle empêche que les travaux puissent se dérouler en parallèle. Une équipe avec cette règle ne peut pas pratiquer le développement simultané. Tant que chaque story n'a pas fait l'objet d'un design détaillé, il n'y a pas de travail possible de l'autre côté de la barrière.

La meilleure variante serait : « Si une story inclut des écrans nouveaux importants, des maquettes de ces nouveaux écrans devraient avoir été créées en amont dans une mesure suffisante pour que l'équipe puisse clarifier les questions et problèmes restants au cours de l'itération. »

Petit changement, grand impact sur la Definition of Ready :

1. La règle devient une ligne directrice.
2. En disant que les maquettes doivent simplement être suffisantes plutôt qu'terminées, nous permettons des travaux simultanés.

Ces deux changements apportent un peu plus de subjectivité dans l'utilisation d'une Definition of Ready. Nous disons toujours au videur que nous voulons des gens jeunes, branchés et bien habillés dans notre club. Cependant, nous lui donnons plus de liberté pour décider lui-même ce que « bien habillé » signifie réellement.  

Ce texte provient du blog de Mike Cohn et a été traduit en français par nos soins.