Tres Amigos, tous pour un, un pour tous !
Auteur : George Dinwiddie
Source : The Three Amigos (www.StickyMinds.com - NOVEMBER/DECEMBER 2011 - BETTER SOFTWARE)
Date : 12/2011
Traducteur : Fabrice Aimetti
Date : 07/08/2025
Traduction :
Notre histoire jusqu'à présent...
Tom le Testeur parcourut la description des stories dans le backlog d'itération :
Le rapport fournisseurs doit répertorier les fournisseurs par ordre de pourcentage de réalisation de leur quota de ventes mensuel.
"Que se passe-t-il si le fournisseur n'a pas encore communiqué ses ventes mensuelles ?" se demanda Tom. "Ou s'il s'agit d'un fournisseur provisoire qui n'a pas de quota défini ?" Nous avons quelques cas de ce genre." Il passa à la description suivante :
Le directeur commercial doit être informé de tous les fournisseurs qui ont atteint moins de 50% de leur quota.
"Informé de quelle manière ? Le rapport fournisseurs n'est-il pas une forme d'information ? Comment puis-je tester cela ?"
Assise à quelques mètres de là, Paula la Développeuse commença à implémenter le rapport sur la rentabilité des articles. La rentabilité de chaque SKU en stock doit être calculée conformément au document Comptabilité SKU sur le serveur de fichiers du service comptable. Elle consulta le répertoire du serveur de fichiers et vit plusieurs fichiers : Comptabilité-SKU-2010, Comptabilité-SKU-2011, Comptabilité-SKU-proposé, Comptabilité-SKU-Jane, Comptabilité-SKU-Harry. Le fichier avec l'horodatage le plus récent était Comptabilité-SKU-Jane, et Jane était la directrice de la comptabilité. Ce devait être le bon fichier . Dès la première page, il était clairement indiqué que :
La rentabilité d'un article correspondait à la somme des prix de vente du SKU, divisée par la somme des coûts de l'article, moins 100%.
Paula ferma le fichier en pensant "C'était facile", sans lire le paragraphe de la page trois : "Calculs spéciaux pour la rentabilité des SKU utilisés comme produits d'appel".
Elle était déjà en train de coder : Pour la "somme du coût des articles, je peux simplement multiplier le "coût actuel" par le nombre d'articles vendus", pensa Paula. "Je devrais avoir terminé cette story cette après-midi."
Alan l'Analyste, se pencha sur ses notes. Sally l'Auditrice de la Sécurité avait insisté pour que les informations relatives aux achats de dispositifs médicaux par les clients soient protégées contre tout accès facile. Ces informations d'achat devaient-elles également être cryptées dans la base de données ? Était-il possible de le faire tout en continuant à fournir l'accès nécessaire au service clientèle lorsque les clients appelaient pour obtenir de l'aide ? "Je ferais mieux de spécifier le cryptage ; mieux vaut prévenir que guérir. Les développeurs me diront s'ils ne peuvent pas le faire", pensa Alan. "Je me demande quand l'équipe de sécurité prendra la décision concernant les catégories d'articles qui doivent être considérées comme 'sensibles' ? Je devrais peut-être simplement me référer à leur document de spécifications. Ils l'auront sûrement bientôt terminé." Alan reporta son attention sur les questions sans réponse concernant les tests marketing.
Le développement de logiciels peut être une activité difficile et solitaire.
Les Tres Amigos à la rescousse
Un pour tous, tous pour un. Nous aurons plus de chances d'obtenir le bon système plus rapidement si nous collaborons. Les Tres Amigos sont les parties prenantes essentielles du système en cours de développement : le métier(ou le product owner dans Scrum), le développeur et le testeur. Ces trois acteurs représentent les points de vue sur ce que le système est censé faire, ce qui peut et ne peut pas être mis en œuvre, et ce qui pourrait mal tourner ou être mal compris. Ces trois points de vue représentent des façons orthogonales d'envisager le système, et je recommande vivement d'impliquer au moins trois personnes. Il est vrai que certaines personnes seraient capables de voir les choses sous plusieurs de ces angles. Il est tentant de théoriser que l'on peut obtenir les mêmes résultats avec moins de personnes. Dans la pratique, cependant, il est difficile de donner à plusieurs points de vue leur juste place en même temps. Le fait d'avoir des personnes différentes pour chaque angle de vue permettra de réduire le nombre de points importants manqués.
Ne vous limitez toutefois pas à seulement trois parties prenantes. En fonction du système développé ou de la partie du système concernée,
vous constaterez peut-être que d'autres parties prenantes sont essentielles pour apporter d'autres angles de vue. Vous disposez peut-être d'experts
en expérience utilisateur qui ont une connaissance approfondie de la manière dont les personnes utilisent votre système et comment éviter les mauvaises utilisations. Il peut également être important de prendre en compte les besoins des personnes chargées de l'exploitation du système
qui le font fonctionner, ou du service clientèle qui traite les appels des clients. Le service financier doit peut-être fournir des informations sur les aspects délicats du contrôle fiscal. Ou l'équipe sécurité doit s'assurer que le système est protégé contre les utilisateurs malveillants. Intégrez ces autres angles de vue si nécessaire. Ce n'est pas parce que cette approche s'appelle les "Tres Amigos" qu'elle se limite à trois personnes. J'ai souvent vu des "Tres Amigos" composés de quatre personnes.
D'un autre côté, ne partez pas du principe que plus il y a de monde, mieux c'est. N'invitez que les personnes qui ont un intérêt direct dans la réussite du système. Souvent, l'équipe compte plusieurs développeurs et testeurs. N'invitez pas tous les développeurs et testeurs à chaque réunion, car cela dilue le sens des responsabilités. Cette dilution peut conduire à négliger des points importants. Parallèlement, le fait que chacun veuille donner son avis rallongera la durée des réunions. Vous pouvez avoir différents développeurs et testeurs à différents moments, mais n'avoir qu'un seul représentant pour chacun. Changer les participants d'une réunion à l'autre permet d'impliquer tout le monde, de donner à chacun un peu de répit et de renouveler l'intérêt. Vous pouvez avoir différents développeurs et testeurs à différents moments, mais n'ayez qu'un seul représentant pour chacun. Changer les participants individuels d'une réunion à l'autre permet d'impliquer tout le monde, de donner à chacun une pause et de garder l'esprit frais. Il est toujours préférable de réunir les bonnes personnes, et uniquement les bonnes personnes, dans la salle pour obtenir les meilleurs résultats.
Comment les Tres Amigos travaillent ensemble
Les Tres Amigos doivent collaborer pour définir ce qui doit être fait, comment ils sauront quand cela sera fait et si cela a été fait correctement. Après la mise en œuvre, les Tres Amigos doivent examiner le travail pour s'assurer qu'il est toujours correct du point de vue de chacun. Entre ces deux points, des Tres Amigos qui fonctionnent bien continueront le dialogue afin que tout malentendu soit découvert et corrigé rapidement, et que toute nouvelle idée puisse être intégrée dans l'intérêt de tous. Voici comment cela pourrait se dérouler dans un cycle de vie agile itératif et incrémental typique :
Affinage du Backlog
Avant le développement d'une user story, généralement au cours du sprint ou de l'itération précédent(e), les Tres Amigos se réunissent pour discuter du travail à venir. Nous ne voulons pas attendre trop longtemps pour ajouter des détails, car cela nous ralentirait. Nous ne voulons pas non plus le faire trop longtemps avant la mise en œuvre, car les détails pourraient devenir obsolètes. Les informations détaillées se détériorent imperceptiblement avec le temps, et le contexte change de telle sorte que ces informations peuvent ne plus être applicables. Au fur et à mesure que nous apprenons de nouvelles choses au cours du processus de travail,
cela modifie notre façon de penser les détails de la fonctionnalité que nous souhaitons. Des événements externes peuvent également modifier ce que
nous attendons du système.
La clarification du travail prévu est souvent appelée "affinage du backlog". Certaines équipes reportent la discussion des détails jusqu'à ce qu'elles commencent à planifier la prochaine étape du travail. Lorsque cela se produit, j'ai généralement constaté que la discussion sur ce que comprend le travail prend le pas sur la planification, ce qui se traduit par une longue session, des critères d'acceptation flous et une planification incertaine. Au cours d'une ou plusieurs réunions en petits groupes, les Tres Amigos examinent les stories prévues une par une. En commençant par l'élément le plus prioritaire, nous examinons chaque story et en discutons afin d'aboutir à une compréhension commune de l'intention. Nous approfondissons cette compréhension en proposant des exemples : "Vous voulez dire que lorsque _____ alors _____ ?" "Oui, mais si _____ se produit alors _____." Nous examinons ensuite ces exemples pour déterminer ce qui est un élément essentiel pour la fonctionnalité souhaitée et ce qui est un détail secondaire exigé par la mise en œuvre retenue.
L'objectif est de trouver des exemples qui couvrent tous les scénarios importants et de les condenser pour en extraire l'essence même de la fonctionnalité.
Au cours de cette réunion, prenez toutes les notes que vous jugez utiles ou qui pourraient vous être utiles plus tard. L'important est d'aboutir à un ensemble complet mai minimal d'exemples pour illustrer la fonctionnalité. Ces exemples n'ont pas besoin d'être complexes ou détaillés, mais ils doivent être suffisamment clairs pour communiquer l'intention de la fonctionnalité.
Réunion de Planification
Lorsque nous nous réunissons pour planifier le prochain incrément à développer, comme on le fait lors de la réunion de planification du sprint dans Scrum, les Tres Amigos utilisent ces exemples pour communiquer l'intention à l'ensemble de l'équipe de développement. Le contenu des exemples donne à l'équipe une idée assez précise de ce qui sera nécessaire pour mettre en œuvre la user story. Le nombre d'exemples donne aux membres de l'équipe une bonne idée de sa taille. Si la story est découpée en plusieurs stories, les exemples indiquent clairement quelle fonctionnalité est attribuée à quelle histoire. D'après mon expérience, cela permet de gagner beaucoup de temps. J'ai vu des discussions d'équipe tourner en rond, certains membres pensant que la story est une petite partie et d'autres pensant qu'elle comprend de nombreux autres scénarios. Si vous estimez la taille des stories, la nature explicite des exemples facilite grandement la tâche.
"Cela ne prend-il pas autant de temps que si toute l'équipe développait les exemples ?" J'entends souvent cette question. Non, les exemples
communiquent mieux que des textes plus abstraits. Si les exemples d'une story ne couvrent pas une situation particulière, soit cet exemple décrit une autre story, soit il s'agit d'une nouvelle fonctionnalité. La plupart du temps, vous voudrez reporter cette nouvelle fonctionnalité afin de pouvoir y réfléchir sérieusement. Notez également l'exemple. Cela vous sera très utile lorsque vous y reviendrez.
Développement et vérification
Au cours du développement, les exemples sont transformés en tests automatisés. La user story n'est pas considérée comme terminée tant que
les exemples ne sont pas validés.
Transformer les exemples en tests automatisés devrait être une tâche assez facile, selon la manière dont vous avez exprimé ces exemples et les outils que vous utilisez. Il est préférable de le faire avant de mettre en œuvre la story, mais cela peut également être fait au débutndu travail sur la story. Il faudra peut-être attendre que la story soit un peu plus avancée pour connecter l'exemple afin de piloter le code en cours de développement. Ce n'est pas grave. Connectez-le dès qu'il y a un endroit approprié pour le faire. Ce travail est souvent le fruit d'une collaboration entre le testeur et le développeur.
Test exploratoire
À mesure que chaque fonctionnalité devient disponible, vous voudrez l'examiner. Répond-elle à l'intention initiale de la fonctionnalité ? Semble-t-elle raisonnable ? La fonctionnalité semble-t-elle toujours souhaitable lorsque vous la voyez en fonctionnement ? Le système suggère-t-il des utilisations non prévues ? Si oui, ces opérations non prévues fonctionnent-elles de manière raisonnable et donnent-elles des réponses correctes ?
Réussir les tests d'acceptation ne signifie pas nécessairement que le logiciel est acceptable. Ce n'est que le premier obstacle à franchir pour obtenir l'acceptation. Les scénarios types envisagés par les Tres Amigos avant le développement devraient couvrir assez bien les fonctionnalités attendues, mais personne n'a une vision parfaite de l'avenir. Il est toujours préférable de faire preuve d'esprit critique après le développement également.
Nous rassembler tous
Paula, Tom et Alan terminaient leur affinage du backlog. Après avoir pris une photo de leur travail sur le tableau blanc, Alan a exprimé sa gratitude envers ses collaborateurs : "Merci de m'avoir aidé à dresser cette liste de questions en suspens concernant la fonctionnalité d'offre promotionnelle. Je vais les transmettre au service marketing pour en discuter. Si possible, j'inviterai un membre du service marketing à notre prochaine réunion. En attendant d'y voir plus clair, nous avons d'autres fonctionnalités importantes à développer. Celle-ci n'est pas encore tout à fait prête."
Alan a réfléchi à la façon dont le processus était devenu beaucoup plus facile depuis qu'il n'avait plus à rédiger tous les détails seul. Paula était bien meilleure en mathématiques et pouvait facilement transformer les descriptions commerciales en algorithmes toute seule. Tom avait imaginé des exemples vraiment intéressants et, à eux trois, ils avaient réussi à se mettre d'accord sur les résultats qui seraient corrects dans certains cas particuliers.
Paula se sentait prête à se lancer dans ce nouveau travail. Elle disposait d'exemples qui indiquaient clairement quand le logiciel fonctionnait correctement, même lorsque les flux de données externes étaient interrompus. Elle était rassurée de savoir que le début de la prochaine itération ne serait pas gaspillé à essayer de comprendre les exigences.
Tom était soulagé de savoir que la plupart des tests fonctionnels de fin d'itération étaient terminés. Mettre ensemble les exemples qu'ils avaient explorés sous une forme pouvant être exécutée de manière automatisée serait un travail rapide et simple. Il ne s'ennuyait plus au début de l'itération et n'était plus soumis à une pression extrême à la fin, lorsque la fonctionnalité finale était terminée. Au contraire, Tom avait désormais le temps de faire ce qu'il considérait comme la partie amusante des tests : rechercher des comportements inhabituels lorsque le système recevait des entrées inattendues : "Alan, quand tu auras un moment, j'aimerais te montrer quelque chose que j'ai découvert aujourd'hui. L'écran du rapport de la rentabilité des catégories de produits me semble confus lorsqu'il manque des données, tant au niveau des résultats des magasins que de l'historique des achats. Nous pourrions peut-être apporter une modification simple pour clarifier cela, ou peut-être nous devrions en parler au service comptable afin de définir les travaux futurs dans ce domaine."
Quelle incroyable différence lorsque nous nous mettons tous à collaborer ! Le développement de logiciels reste difficile, mais pas autant qu'avant. Et c'est beaucoup moins solitaire. {end}
gdinwiddie@idiacomputing.com