Les “3 amigos” : kézako ?

Il s’agit d’une méthode permettant de :

• concevoir une nouvelle feature de la meilleure manière possible.
• s’assurer de la compréhension partagée de la feature.

J’ai découvert cette méthode il y a quelques années, et j’ai très vite été conquis. Mais avant d’expliquer plus précisément en quoi ce “3 amigos” consiste, le mieux serait peut-être d’analyser le fonctionnement par défaut, que j’appellerais “en cascade”.

Process classique, “en cascade”

Le fonctionnement en cascade est une version simplifiée du “cycle en V”. C’est un fonctionnement séquentiel qui peut être décomposé en 3 phases :

• la conception de la feature : le Product Owner (PO) récolte les besoins auprès de ses clients, puis imagine une feature permettant de répondre à ces besoins. Cette feature est ensuite présentée sous forme de spécification (plus ou moins) longue et détaillée, avec potentiellement des exemples graphiques (Marvel, Figma, etc…).
• l’implémentation de la feature : l’équipe de développement prend connaissance de la feature grâce aux specifications. Parfois, cela peut s’officialiser via une réunion “kick-off” entre l’équipe produit et les développeurs. Les développeurs implémentent alors la feature. Une fois qu’elle est terminée, elle est envoyée à la QA
• le test de la feature : la QA prend connaissance de la spécification, puis teste la feature implémentée par les développeurs. Si tout est correct, la feature peut être mise en production. Si elle trouve des bugs, elle renvoie le ticket aux développeurs, qui fixeront (ou pas) les retours de la QA. Une fois fait, les devs renvoient la feature à la QA, et on recommence jusqu’à mise en production.

Avec ce processus, on distingue assez facilement quelques éléments aberrants, qui peuvent créer des blocages ou lenteurs :

• la QA n’est pas toujours inclue dans les discussions lors de la conception de la feature : elle ne peut donc pas échanger en avance sur les tests qu’elle va réaliser, ni prévenir sur des scenarii qui auraient été oubliés par l’équipe produit.
• Suivant le point précédent, la QA peut aussi mal interpréter la spécification et prévoir des cas de tests non pertinents.
• Le développeur n’a pas son mot à dire sur le choix de la solution implémentée : il se retrouve limité à un rôle de “simple executant”.
• Pendant ses tests, la QA pourrait juger qu’un comportement n’est pas celui attendu. Elle échangera alors avec les développeurs et/ou le PO. Dans le cas où la QA a raison, le développeur devra retravailler ce comportement a posteriori (rework ==> perte de temps). Dans l’autre cas, cela aura entrainé une perte de temps en discussions (et éventuellement changement d’attention.)

Pour pallier à ces manquements, les “3 amigos” sont là pour vous !

Les 3 amigos

Cette méthode se base sur 2 piliers selon moi :

1. mettre ensemble, le plus tôt possible, nos 3 amis : le PO, le dev, le QA (d’où la méthode tire son nom)
2. pour le PO, avoir une idée précise, mais potentiellement non définitive, de la feature à implémenter

Cette cérémonie doit être initiée pendant la spécification, et avant le lancement de l’implémentation. Elle permet de lever la majorité des problèmes rencontrés dans le process en cascade. Par ailleurs, il n’est pas rare que la solution proposée initialement par le PO ne soit pas exactement celle conservée à la fin de la réunion : en mettant tout le monde ensemble, chaque entité va apporter son expertise, proposer des évolutions simplifiant la vie de chacun, et permettre ainsi de créer la meilleure feature au moindre coût.

• le PO apporte la valeur ajoutée du produit : il sait quels sont les vrais besoins auxquels il veut répondre, et pourra donc trancher dans le cas de choix à faire
• le dev apporte la composante technique : il sait ce qui sera simple (ou non) à implémenter, et pourra proposer au PO des solutions équivalentes mais moins coûteuses à implémenter. Il peut aussi estimer la charge de travail et ainsi alerter si le ratio (valeur ajoutée/coût) devient trop faible
• le QA apporte la composante test : il cherche toutes les situations “non triviales” du système, et peut déjà indiquer quels tests il va faire, afin que le développeur puisse déjà les prendre en compte, voire les tester lui même pendant le développement. Il peut aussi aider à prévoir la testabilité de la feature.

Le point essentiel de cette cérémonie est de permettre une meilleure communication entre des personnes malheureusement trop souvent séparées. Elle permet une compréhension partagée de la feature, tout en minimisant les risques de rework, dus à une mauvaise spécification. A noter qu’il s’agit d’une réelle application d’un des préceptes du manifeste agile “privilégier les individus et leurs interactions, plutôt que les processus et les outils” : https://agilemanifesto.org/iso/fr/manifesto.html