Définition du Prêt
Auteur : George Dinwiddie
Source : Definition of Ready
Date : 27/03/2014
Traducteur : Fabrice Aimetti
Date : 06/08/2025
Traduction :
Souvent, au milieu du développement d'une user story, le développeur se pose une question sur la manière dont elle est censée fonctionner. Ou bien le testeur, lorsqu'il examine la fonctionnalité qui a été développée, se demande si elle est vraiment censée fonctionner de cette manière. J'ai travaillé un jour avec une équipe qui constatait trop souvent que, lorsque le développeur prenait la carte, il y avait des questions qui n'avaient pas été réfléchies. L'équipe a créé une nouvelle colonne sur le tableau du sprint, « Analyse des besoins », à gauche de « Prêt pour le développement », pour ces cartes qui avaient été planifiées sans être bien comprises.
C'est pour résoudre ce problème que la réunion des Tres Amigos a été créée. Plutôt que d'attendre qu'une story soit dans le sprint pour la comprendre pleinement, les stories qui étaient sur le pont pour le prochain sprint seraient discutées par les représentants de l'entreprise, les développeurs et les testeurs pour s'assurer que toutes les questions ont été répondues avant de considérer la story comme prête pour le développement. Bien sûr, il arrivait encore que des questions soient soulevées au cours du développement, mais l'épidémie avait été endiguée.
Depuis, j'ai trouvé de meilleurs moyens de déterminer si une story est prête à être développée. Je recherche la liste des exemples essentiels, ou des scénarios d'acceptation, que la story achevée satisfera. Ces exemples apportent une précision à la compréhension de la story qu'il est difficile d'obtenir d'une autre manière.
Il y a des bénéfices marginaux à aller jusqu'à ce niveau de détail. Les discussions de planification de la story ne passent pas beaucoup de temps à comprendre ce que la story signifie. Ces discussions ne tournent pas en rond pour trouver les contours de la story. Si le scénario ne figure pas dans la liste, c'est qu'il fait partie d'une autre story (ou qu'il a été ignoré). En fait, la répartition des scénarios en groupes est un moyen simple de diviser une story en plusieurs parties.
Un autre avantage est que les scénarios peuvent être automatisés en tant que tests d'acceptation avant le développement de la fonctionnalité. Le fait d'avoir une vision claire du résultat avant de commencer permet de maintenir le développement sur la bonne voie, en minimisant les spéculations prématurées sur les besoins futurs et en maximisant l'attention portée aux cas de figure actuels qui pourraient autrement être oubliés.
Dans un processus de développement basé sur des sprints ou des boîtes de temps, vous disposez de tout le sprint pour affiner les stories du sprint suivant avant de les planifier. Si vous pratiquez un processus tiré à une seule pièce, vous disposez de la durée pendant laquelle une story passe dans la file d'attente de développement pour le faire. Quoi qu'il en soit, l'affinage du backlog est une activité nécessaire qui doit être réalisée petit à petit, en permanence.
L'objectif est de réaliser le travail juste à temps pour la planification et le développement. Il doit être suffisamment complet pour éviter les interruptions permettant d'approfondir les connaissances, mais pas trop longtemps à l'avance pour éviter que les détails ne soient obsolètes. Nous voulons que nos scénarios tirent parti du maximum de connaissances que nous pouvons apporter. S'ils sont élaborés trop tôt, il se peut que nous devions revoir les scénarios pour voir si nous devons les modifier en fonction de ce que nous avons appris depuis que nous les avons créés.
Le plus souvent, je constate que les équipes ne créent pas trop de scénarios d'acceptation trop tôt, mais qu'elles consacrent cet effort trop tard. Cela semble beaucoup de travail d'entrer dans ces détails alors que nous savons que nous avons une montagne de travail à accomplir.
Développer correctement un logiciel est une activité orientée vers le détail. Nous devrons tôt ou tard nous pencher sur ces détails. Le fait d'attendre que le développeur ait une question à poser entraîne des interruptions dans le développement, des retards, une perte d'efforts et, parfois, des hypothèses injustifiées qui nous donnent des résultats que nous ne voulons pas. Ne contemplez pas la montagne de travail. Regardez le petit bout de travail que nous avons décidé de faire ensuite. Faites du bon travail sur ce point et les choses se dérouleront plus en douceur.