Imaginez une situation - le testeur trouve un bogue, commence à en discuter avec le développeur - et il insiste sur le fait que ce n'est pas un bogue, car la spécification n'a pas parlé de cette fonctionnalité. Est-ce familier?
Ou parce que les exigences étaient ambiguës, et il les a mal comprises. Ou vice versa, il y avait tellement d'informations en eux que la concentration a été perdue et certaines informations ont été perdues de vue pendant le développement.
Et dans cette situation, le développeur n'est pas un parasite qui a délibérément fait une erreur. En pratique, si vous lui fournissez des exigences simples, compréhensibles et, surtout, courtes, le nombre d'erreurs que les testeurs trouveront ira à zéro.
Vous connaissez probablement aussi les litiges au sujet d'un "bug ou d'une fonctionnalité". Les clients ont découvert des défauts et le propriétaire du produit vient à l'équipe avec des commentaires. Et le testeur et le développeur se défendent, ce qui s'explique par le fait que dans le cadre d'origine, il n'était pas question de la mise en œuvre de cette fonctionnalité. Et de tels moments commencent alors dans l'arriéré.
Je crois que toutes ces tâches instituées après la sortie, et qui sont le résultat d'une spécification mal développée, sont également des bugs. Bugs qui caractérisent la qualité de votre produit.
Il s'avère que les analystes commerciaux déterminent les fonctionnalités à créer. Les développeurs les créent. Les testeurs trouvent des défauts dans le travail des deux. C'est ainsi que fonctionne l'approche de développement traditionnelle. Mais vous pouvez apprendre à ces trois à travailler ensemble pour faire leur travail mieux et immédiatement, sans modifications supplémentaires. Et ce moyen de communication s'appelle 3 Amigo. Aussi appelé Story Kick Off Huddles ou Triad.
3 Amigo c'est ...
3 Amigo est une pratique qui permet une compréhension universelle de ce qui sera livré au client. Il aide à transmettre la voix de l'équipe, pas l'imbrication d'opinions dispersées.
Cette méthode de communication au sein de l'équipe permet:
- parvenir à un accord commun sur les attentes avant le développement
- former un accord sur la façon de faire la bonne chose tout de suite
Cela aide également à comprendre:
- quel problème résout-on
- quelles sont les solutions
- que devons-nous faire pour que la tâche soit prête
La rencontre des trois amigo est une façon de penser ensemble qui comble le fossé dans la compréhension des spécifications métiers. Elle aide au développement d'histoires d'utilisateurs sympas.
Le but est de faire le travail à temps, mais en même temps de ne pas planifier à l'avance afin que les détails aient le temps de devenir obsolètes.
Pourquoi 3? Qui fait la demande?
Le nom de la pratique ne nous limite pas à trois contextes, mais crée seulement un cadre minimal. Pour s'assurer que dans le développement des exigences, nous avons pris en compte toutes les nuances techniques, les cas évidents et implicites, que la spécification reflète le besoin réel du client - il faut 3 pensées / contextes différents: entreprise, développeur, testeur. De plus, la réunion ne se limite pas uniquement à ces personnes. Elle implique toutes les personnes impliquées dans la mise en œuvre de l'exigence. Par exemple, si votre tâche comprend non seulement le Web, mais aussi le mobile, vous avez besoin d'un contexte supplémentaire. Autrement dit, la personne qui effectuera la mise en œuvre dans l'application mobile. Dans nos équipes, le plus souvent 4 développeurs (1 ios, 1 android, 1 back, 1 front), un testeur et un analyste métier participent à la réunion.
Analyste d'affaires ou PO
Un représentant commercial sait (presque toujours) ce qu'il souhaite obtenir en fin de compte et quelle valeur le client et l'entreprise en retireront. Il est important de parler de cette équipe.
Participant à la réunion Amigo 3, l'analyste commercial partage des informations avec les participants afin que tout le monde dans l'équipe ait la même compréhension et les mêmes attentes de la user story. De plus, lui seul peut limiter la portée des critères d'acceptation par lesquels l'acceptation aura alors lieu.
Développeurs
Le développeur sait comment mettre en œuvre l'exigence de l'entreprise, quelles sont les opportunités pour cela. En règle générale, il réfléchit aux détails qu'il doit connaître pour commencer la mise en œuvre. En posant des questions basées sur son expérience et sa connaissance du système, le développeur aide à révéler diverses nuances même au stade de la discussion des exigences.
Testeur
Le testeur, comme les autres membres de l'équipe, contribue à enrichir les exigences avec divers cas de test. Fort de son expérience, il remet de plus en plus souvent en doute les propos tenus par l'équipe. Par conséquent, il vaut mieux trouver des cas extrêmes, des scénarios implicites, se demande ce qui pourrait mal tourner, ce qui devrait se méfier.
Quand la pratique est-elle appliquée?
J'ai rarement vu un processus de développement où les exigences étaient explicitement présentées. Dans la plupart des cas, les exigences ont commencé à être étudiées au stade du développement ou des tests, et ce n'est qu'alors que certaines incohérences ont été révélées.
Une spécification non testée est susceptible d'avoir des exigences ambiguës, contradictoires, incomplètes, dupliquées et parfois même dépassées, car tout le monde comprend ce qu'il a lu et entendu à sa manière. D'où des différences d'interprétation.
Et si la documentation est volumineuse et détaillée, sa lecture peut prendre plus de temps que le processus de test ou de développement lui-même.
Dans notre secteur d'activité, nous avons décidé d'appliquer cette pratique lorsque les tâches ont commencé à s'attarder dans les tests. Nous avons identifié 3 problèmes principaux:
- Au stade des tests, de nombreux retours ont eu lieu en raison de la clarification des exigences. Il s'agissait de pauses tangibles dans les tests et le développement, lorsqu'un analyste métier a déterminé comment cela devait fonctionner.
- Le test de la tâche a été retardé en raison d'une spécification trop détaillée. Les cas étaient fréquents, lorsque le testeur ne pouvait passer que 3 à 6 heures à étudier les exigences et à développer des cas de test, et le test lui-même prenait environ 30 minutes. et détaillé.
- Eh bien, le problème le plus courant était que lors des tests d'acceptation, il y avait beaucoup de bugs. Ces bugs qui auraient pu être évités s'ils avaient été réfléchis avant le développement.
Il s'avère donc que malgré un développement agile, il reste encore une étape de travail avec la spécification technique. Et si vous n'avez pas pris en compte certains cas, parce que le client n'a pas dit à leur sujet, ou n'a pas fait ce qu'il voulait vraiment dire, après être allé au prod, il y a beaucoup de tâches dans le backlog pour révision ou même modification.
Et enfin, il convient de signaler le problème de l'évaluation.
Il est difficile d'évaluer une tâche lorsque vous ne comprenez vraiment pas toute la quantité de travail qui reste à faire. Combien de tests à écrire, combien de retours seront dus à des bugs ou des altérations dues à des inexactitudes dans la spécification? Même si le développeur donne une évaluation précise du temps de développement lui-même, vous ne devinerez presque jamais le temps que prendra l'étape de test imprévisible.
Étapes pour pratiquer l'AC
1. Nous formulons les exigences en tant que User Story
Je recommande de postuler pour développer des exigences basées sur des user stories. Et comme base pour prendre une histoire et lors d'une réunion de 3 amigo pour l'étudier uniquement.
Ici, un point très important est que l'exigence de l'entreprise est vraiment formulée comme une histoire d'utilisateur. Autrement dit, il contenait en lui-même 3 parties, à savoir:
Je comme <rôle>, je veux <action>, pour que <motivation>
Il s'agit en fait du modèle de narration personnalisé le plus populaire appelé Connextra. Il existe également d'autres modèles, mais je recommande d'utiliser celui-ci. Et pourquoi, maintenant je vais vous expliquer.
Traditionnellement, il existe 2 problèmes lors de la création d'une user story:
- Lors de l'enregistrement, soit n'indiquez pas le rôle, laissant l'action et la motivation
- Ou ils indiquent le rôle et l'action, et ils rejettent la motivation.
Cela pose en fait des problèmes, et je vais essayer d'expliquer quels exemples avec des exemples simples.
- Connaissant le «rôle», vous, en tant que membres de l'équipe, comprendrez mieux les limites des critères d'acceptation que vous devez formuler. Si vous n'êtes pas pleinement au courant de la personne impliquée dans cette user story, vous pouvez soit le faire au-delà de ce dont vous avez besoin, soit vice versa, faire certaines fonctionnalités.
- Exemple : l'équipe a mal compris le rôle dans la user story, et lors de l'exécution de la tâche, elle a décidé qu'elle ferait 3 méthodes pour l'api: ajouter, éditer et supprimer. Et à l'avant, ils ajouteront des boutons qui appelleront ces méthodes. Lorsqu'ils ont présenté leur décision à l'entreprise, ils ont reçu une rétroaction indiquant que leur client était en fait un analyste commercial spécifique qui avait besoin d'une méthode d'ajout. Et il ne supprimera ni ne modifiera. Oui, et il peut appeler cette méthode par le biais du facteur.
- L'équipe ne comprend pas la motivation du «rôle» pour lequel ils font une user story. En raison d'un malentendu, les limites de la user story elle-même sont mal définies. Et en plus de cela, les critères d'acceptation peuvent ne pas résoudre le problème du client final, bien qu'ils correspondent à l'action exprimée dans la user story.
- Exemple : une équipe a embauché une user story où un analyste d'entreprise ne pouvait pas clairement exprimer sa motivation. D'une part, elle devait laisser le client fidèle et lui apporter une amélioration. D'autre part, la réduction des coûts pour la banque. Dans ce cas, les méthodes de mise en œuvre et les critères d'acceptation étaient radicalement différents. Parce que dans le premier cas, l'équipe s'est concentrée sur les critères d'acceptation des utilisateurs. Dans le second - l'équipe a prêté attention à la façon de rendre la mise en œuvre la plus simple et la plus rapide possible.
Mais la formulation dans le format ci-dessus n'est pas une condition préalable. Je connais des équipes qui tiennent des réunions au format Amigo 3 et sans user story. Et comme base, utilisez les savoirs traditionnels. Dans ce cas, il y a des pièges, mais c'était un choix conscient de l'équipe.
Réunion 3 Amigo commence par la préparation. En préparation, les exigences sont formulées de manière à être compréhensibles par toute l'équipe. Ces exigences sont validées pour la préparation au travail.
La validation comprend l'évaluation de l'historique par rapport aux critères INVEST. Ainsi que la qualité de la rédaction de l'histoire elle-même. Ici, toute ambiguïté, verbosité est exclue, et lorsqu'elle est évaluée par INVEST, une attention particulière est portée à la taille de l'histoire. Si l'équipe comprend que l'exigence est épique, la décomposition se produit.
Une fois que l'exigence a franchi le stade de la transformation en user story et validation par l'équipe (3 amigo), nous pouvons procéder à l'élaboration des critères d'acceptation.
2. Nous complétons les critères d'acceptation de la User Story lors de la réunion du 3 Amigo
Vous devez d'abord décider quels sont les critères d'acceptation.
Ainsi, les critères d'acceptation sont des exigences du client; spécification par laquelle le système / user story peut être vérifié.
Ils ont un nom alternatif, des conditions de satisfaction - des conditions de satisfaction des attentes (auteur Mike Cohn).
Lors d'une réunion de 3 équipes d'Amigo déjà préparées. Ils ont déjà une histoire d'utilisateur validée, qui a peut-être déjà un ensemble de critères d'acceptation que le représentant commercial a formulé de manière indépendante.
Pendant la réunion, les tâches des participants sont de compléter / enrichir l'historique avec un nombre suffisant de critères d'acceptation pour sa mise en œuvre ultérieure.
Les critères d'acceptation ne doivent pas inclure les détails de mise en œuvre. En fait, les critères d'acceptation sont des règles métier qui régissent une user story en cours de développement. Les détails de mise en œuvre sont enregistrés dans les tests d'acceptation, mais une fois tous les critères d'acceptation formulés.
Il ne vaut pas la peine de confondre les détails de la mise en œuvre avec les critères d'acceptation, ne serait-ce que parce qu'avec des délais limités, vous, en tant qu'équipe, pouvez toujours «jeter» un éventail de critères qui n'est pas si important pour les entreprises dans un avenir proche. S'il y a des détails avec l'implémentation technique dans les critères, vous risquez de perdre des informations importantes et du temps qui a déjà été consacré à discuter des détails de l'implémentation. Vos détails d'implémentation dépendent directement de la portée des critères que vous devez faire.
Évitez également une description séquentielle du scénario avec un ensemble d'étapes (système de gestion de cas de test classique). Chacune de vos déclarations doit être atomique. Il est préférable d'utiliser un style descriptif du comportement attendu de la fonction créée.
Par exemple:
* , .*>
3. Nous respectons le calendrier
Un US bien décomposé ne contient généralement pas plus de 10 critères d'acceptation. Si dans le processus de discussion un grand nombre de critères d'acceptation sont trouvés et qu'ils sont tous soumis à la mise en œuvre, alors cette histoire doit être décomposée en plusieurs histoires avec un pool différent de critères d'acceptation.
Si cela n'est pas fait, la réunion des 3 Amigo sera considérablement retardée.
Le moment optimal pour organiser une réunion de 3 Amigo est de 30 minutes à 1 heure.
Augmentation acceptable au tout début du parcours - lorsque l'équipe apprend simplement à communiquer et à appliquer cette pratique.
Si une équipe prend une grande histoire au travail, il est peu probable qu’en une seule session, elle puisse déterminer tous les critères et les tests d’acceptation. Parce que la concentration et l'attention sont perdues. Dans ce cas, vous devez diviser la session en plusieurs réunions. Mais dans ce cas, il y a un risque de perdre le contexte, et une immersion supplémentaire peut être nécessaire lors d'une deuxième réunion.
4. Pour compléter l'étude des critères, nous utilisons l'heuristique USR
Lorsque j'enseigne cette pratique aux équipes, je recommande d'utiliser l'heuristique au tout début de leur parcours pour atténuer le manque d'expérience. Avec l'expérience, l'équipe a ses propres heuristiques et listes de contrôle sur ce qu'il faut rechercher lors de l'élaboration des critères.
L'heuristique USR vous permet de considérer les critères à tous les niveaux nécessaires pour obtenir le plus d'informations sur ce que veut le client.
Alors
- UTILISATEUR - Que veut faire l'utilisateur avec le système?
- SYSTÈME - Que doit faire le système?
- RISQUES - Quels problèmes peuvent survenir?
Il est important de commencer par définir tous les critères du groupe USER, puis de passer uniquement au niveau système. Ici, les développeurs frontaux et principaux sont inclus, et au niveau de leurs systèmes, ils peuvent formuler des critères d'acceptation pour ce qui devrait se produire afin de mettre en œuvre les critères du groupe USER.
Et enfin, le groupe RISK. Le plus souvent, on oublie l'élaboration des exigences, bien qu'elle ne soit pas moins importante. Il couvre divers cas complexes que vous ne pourrez peut-être pas implémenter. Mais pour s'exprimer et accepter les risques en équipe, il faut.
Façons d'appliquer la pratique pour développer des cas de test avant le développement
La manière recommandée pour formaliser les exigences est les cas d'utilisation, en informatique russe, nous appelons cela des cas de test.
Il existe un outil pratique pour élaborer des cas de test lors d'une réunion de 3 Amigo, appelé exemple de mappage. Dans cet article, je l'ai brièvement abordé. Dans le prochain article, nous publierons des informations détaillées sur cet outil et son utilisation dans le cadre de la réunion triade.
Les cas de test peuvent être mis en œuvre en tant que tests d'acceptation automatisés pour l'historique. De plus, lorsque vous travaillez sur des cas de test, assurez-vous de les regrouper. La division des cas de test en groupes est un moyen de diviser l'histoire en plusieurs plus petits.
Dans les cas de test, la décomposition d'une règle métier se produit exactement au niveau du système auquel elle sera mise en œuvre, et non par l'utilisateur.
Tous les détails d'implémentation doivent être dans vos cas de test, afin qu'ils se concentrent sur les développeurs dans le processus d'implémentation.
A quoi cela peut-il ressembler dans le processus général (lorsque vous devez tenir cette réunion)
Il est recommandé de définir les exigences pour une seule user story lors d'une seule réunion. Plus est autorisé, à condition que ce soient de très petites histoires ou qu'elles soient interconnectées dans leur sens.
Étant donné que dans le sprint, vous prenez des histoires prêtes à l'emploi, une réunion de 3 histoires d'Amigo devrait avoir lieu avant la planification. Sinon, vous risquez de faire une grosse erreur avec l'estimation préliminaire. En pratique, le bilan de l'histoire après la rencontre de 3 Amigo est très différent de l'original.
En outre, il est logique d'ajouter un nouvel élément au DOD comme indicateur de préparation, que l'histoire est prête à y travailler dans le sprint.
Par exemple, certaines équipes ont commencé à appliquer cette pratique, ont convenu qu'elles ne prendront pas le sprint lors de la planification s'il n'y a pas de critères d'acceptation et de tests d'acceptation pour la tâche.
Et dans la revue de sprint, l'acceptation de l'histoire est présentée selon les critères d'acceptation.
Mais en même temps, la réunion 3 d'Amigo s'inscrit également dans le processus, si l'équipe travaille et non la mêlée, mais utilise par exemple le kanban. Dans ce cas, la tâche n'entre en développement qu'après avoir traversé une réunion de 3 Amigo.
Quel est le résultat de la rencontre 3 d'Amigo?
- scripts / exemples (réponses évidentes)
- règles / critères d'acceptation spécifiés
- histoires nouvelles / décomposées
- compréhension commune du problème
- empathie (empathie, participation)
Le résultat principal des trois amigo sont des tests d'acceptation écrits dans le format « Donné / Quand / Alors» . En fait, leur rédaction peut prendre plus de temps que nous le souhaiterions, il n'est donc pas recommandé de formaliser toutes les exigences lors d'une réunion lorsque tout le monde est ensemble. En règle générale, un développeur ou un testeur y travaillera immédiatement. Et dès qu'ils ont tous les critères et les cas de test enregistrés, 3 Amigos regardent brièvement ce qui s'est passé pour s'assurer que tout le monde est d'accord avec ce qui a été enregistré.
Bénéfice d'utiliser la pratique de 3 Amigo
La stratégie Amigos 3 peut avoir un impact énorme sur l'efficacité de toute l'équipe, ainsi que sur la qualité et la durabilité de vos projets, augmentant la maniabilité et la flexibilité de changement.
Voici quelques bonus supplémentaires:
- Lors de la planification, nous ne passons pas beaucoup de temps à nous plonger dans le sens de l'histoire.
- Détecte la confusion et les malentendus à un stade précoce, ce qui permet une livraison plus rapide
- S'assure que l'équipe discutera de la quantité de travail nécessaire
- Aide à trouver tous les critères d'acceptation et autres attributs de qualité.
- Le développement de cas de test est beaucoup plus facile.
- Nous incitons les développeurs à couvrir le code avec des tests
- Nous arrivons rapidement à la conclusion que cette fonctionnalité n'est pas nécessaire
Nos équipes, grâce à la pratique, ont pu réduire les retours de tâches en raison de spécifications inexactes. Les tâches backend que les gars ont appris à développer «la première fois». Autrement dit, sans bugs et immédiatement sur la prod.
Pièges
- Ne vous limitez pas à seulement trois personnes. Si vous avez besoin de plus - appelez.
- Ne rencontrez pas toute l'équipe. Lors de cette réunion, il doit y avoir un nombre minimum de personnes pour implémenter la fonctionnalité.
- Ne le considérez pas comme une réunion régulière - un rituel. Sinon, l'équipe aura un inconvénient à augmenter le nombre de réunions.
Master class à la conférence QualityConf
Les 27 et 28 mai, dans le cadre du festival RIT ++, lors de la conférence QualityConf, je dirigerai une master class sur le développement des exigences en utilisant la pratique de 3 Amigo.
Si l'approche vous intéresse et que vous avez des questions, vous pouvez également me contacter au télégramme @Travieso_nastya.
Historique d'approche
L'auteur de l'approche: George Dinwiddy, 2009.
Il a décrit cette approche dans son entretien et a mentionné dans un certain nombre d'articles, les liens auxquels j'ai attaché. En outre, en tant que matériel supplémentaire, j'ai joint toutes les références aux ressources en anglais, selon lesquelles j'ai étudié et appris à appliquer cette pratique.
https://www.agilealliance.org/glossary/three-amigos/
https://www.infoq.com/interviews/george-dinwiddie-three-amigos
https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories
https://www.stickyminds.com/better-software-magazine/three-amigos