«- Viens ma fille, allons déjeuner!

– Tu es prêt, papa?

– Presque prêt.

– Alors, ce n’est pas prêt!

J’ai ri. Comme si c’était le sortilège qui se retournait contre le sorcier, car le personnage principal de ce discours était Pietra, ma fille de 4 ans.

Combien de fois nous retrouvons-nous dans de telles situations ? Nous essayons d’accélérer certains processus, ce qui peut entraîner une attente inutile et des retards conséquents, ce qui nous empêche de nous concentrer sur d’autres choses qui pourraient être plus importantes.

Être prêt n’est plus quelque chose de banal, sans grande importance, et cela commence à jouer un rôle important dans la routine de ceux qui travaillent avec une méthode agile, car cela permet de garantir la qualité des résultats. Dans Scrum, par exemple, on parle de “définition de prêt” et on l’utilise “pour vérifier si le (…) produit est fini” (SCHWABER et SUTHERLAND, 2017, p.20). Pour qu’une chose soit définie comme prête, qu’il s’agisse d’une partie, un ajout utilisable ou un produit final complet, il est fallu que les personnes qui participent à sa construction (équipe, dev team ou équipe de développement) aient un consensus sur ce qu’est “être prêt”, sinon chacun le comprendra d’une manière différente et, à la fin, il pourrait encore émerger l’expression “mais je pensais que c’était bien comme ça ” !

S’il existe une norme interne ou du marché concernant le contenu de la livraison, ou si cette définition de “prêt” “fait partie des conventions, normes ou directives de l’organisation de développement” (ibidem), cela permet à l’équipe de se guider. Sinon, elle doit atteindre un consensus et définir. Un bon paramètre est d’être guidé par les apports du client (dans Scrum, ces informations proviennent du Product Owner) et cette décision d’ensemble assure la transparence du processus. Il est toujours utile de se rappeler que la définition du prêt doit être faite au début de la planification de chaque cycle de développement (sprint planning) et pour chaque point à travailler, mais elle peut être revue et améliorée avant les prochains cycles de développements.

Une livraison prête est-elle alors un produit (ou une amélioration) testé et approuvé ? Une virgule ne peut pas être déplacée ? Cela dépend. Si nous développons un système de lancement de fusée et que nous ne voulons pas tout faire exploser, il vaut mieux garder les virgules en place, car sinon nous risquons d’être surpris par un résultat moins positif. Mais si elle n’affecte pas la livraison et peut être ajustée rapidement au cours du prochain cycle sans le compromettre, peut-être.

Élaborez une liste pour vous guider et pour vérifier que tous les points préétablis ont été respectés. Et la prochaine fois que vous réfléchirez à la manière de faire une livraison, pensez à certains de ces points – surtout lorsque vous appelez votre fille pour le déjeuner! »

Leonardo Magalhães

CHEF DE PROJET

Référence bibliographique:

SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide: O guia definitivo para o Scrum. 2017. Disponível em: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. Acesso em: 14 out. 2020.