Voir la source de Expérimenter avec l'Example Mapping

[[Catégorie: Portail Product Owner]]
[[Category: Portail Equipe de développement]]
[[Catégorie: Example Mapping]]
[[Catégorie: BDD]]
[[Catégorie: Tests]]
[[Category: Lisa Crispin]]
[[Category: Brian Marick]]
Auteure : Lisa Crispin<br/>
Source : [https://lisacrispin.com/2016/06/02/experiment-example-mapping/ Experiment with Example Mapping]<br/>
Date : 02/06/2016<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 25/03/2019<br/>
----
Traduction :<br/>
<br/>
Lors de l'Agile 2015, [[Présentation_de_la_cartographie_des_exemples|Matt Wynne m'a parlé de l'Example Mapping (fr)]]. La session de Linda Rising a renforcé mon enthousiasme pour continuer à mener de petites et modestes expériences. Je suis revenue au travail la semaine suivante avec l'impression qu'il serait assez facile d'essayer de mener une expérience avec un Example Mapping.<br/>
<br/>
[[Fichier:ExampleMapJoellen-1.png|border|800px|link=]]<br/>
<br/>
Vous pouvez utiliser l'Example Mapping dans vos [https://gojko.net/2008/11/12/specification-workshops-an-agile-way-to-get-better-requirements/ ateliers de spécification], vos réunions des Trois Amigos (plus d'informations ci-dessous), ou tout autre format que votre équipe utilise pour discuter des stories à venir avec votre product owner et/ou vos parties prenantes du Métier. Écrivez la story sur un postit jaune. Rédiger les règles métier ou des critères d'acceptation sur des postits bleus. Pour chaque règle métier, écrivez des exemples de comportements souhaités et non souhaités sur des postits verts. Des questions vont surgir auxquelles personne dans la salle ne peut répondre en ce moment : écrivez-les sur des postits rouges. C'est tout ce qu'il y a à faire !<br/>
==Le problème==
Mon équipe connaissait un taux élevé de stories rejetées parce qu'il manquait des choses, et notre temps de cycle était plus long que ce que nous aurions souhaité. J'ai demandé à notre product owner (PO) si nous pouvions expérimenter une nouvelle approche pour nos réunions de planification de pré-itération (IPM).<br/>
<br/>
Jusqu'à présent, nos réunions "pré-IPM" (Réunion de Planification de pré-Iteration) étaient un peu bâclées et précipitées. Le PO, le responsable du développement et moi-même nous sommes rencontrés peu de temps avant que l'IPM ne passe rapidement en revue les stories qui allaient être discutées. Il ne restait pas beaucoup de temps pour envisager les questions à poser.<br/>
==L'expérience==
Pour notre nouvelle expérience, nous avons décidé d'essayer une approche [https://www.stickyminds.com/sites/default/files/magazine/file/2013/3971888.pdf "Trois Amigos" (inventée par George Dinwiddie)] ou ce que [https://janetgregory.ca/ Janet Gregory] et moi appelons l'approche "Pouvoir des Trois". Cela ressemble également aux [https://gojko.net/2008/11/12/specification-workshops-an-agile-way-to-get-better-requirements/ ateliers de spécification de Gojko Adzic]. Dans notre cas, c'était les Quatre Amigos. Nous avons décidé de limiter à une heure la durée de notre réunion pré-IPM et de la tenir deux jours ouvrables avant l'IPM. Le PO, le concepteur, le testeur et le responsable du développement se sont réunis pour aborder les stories qui seraient discutées et estimées lors de l'IPM. Notre objectif était d'établir une base de compréhension commune sur laquelle nous pourrions nous appuyer lors de l'IPM, de sorte que, lorsque le test et le codage commenceraient sur une story, tout le monde saurait quelles fonctionnalités sont nécessaires.<br/>
<br/>
Nous avons essayé l'Exemple Mapping comme moyen d'en apprendre davantage sur chaque story avant l'IPM. Je pratique le développement piloté par l'exemple depuis que [http://exampler.com/ Brian Marick] m'en a parlé en 2003. J'ai donc été surprise de constater à quel point il est efficace d'ajouter des règles en plus des exemples. La vérité est que vous ne pouvez pas écrire des tests et du code adéquats uniquement à partir de quelques exemples, vous avez aussi besoin des règles métier.<br/>
<br/>
Puisque nous avons des membres de l'équipe à distance, utiliser les postits de Matt Wynne avec un code couleur ne fonctionnerait pas pour nous. Nous avons essayé d'utiliser [https://cardboardit.com/ CardboardIt] avec ses postits virtuels, mais cela s'est avéré un peu lent et gênant pour notre usage. Puisque notre produit est Pivotal Tracker, un outil de suivi de projet SaaS, nous avons décidé d'essayer de l'utiliser pour les exemples, les règles et les questions. Pour nos réunions de planification, nous partageons l'écran projet sous Tracker dans la vidéoconférence Zoom avec les participants à distance, de sorte qu'il nous semble assez naturel de mettre nos Example Maps en texte dans nos stories sous Tracker.<br/>
<br/>
Nous itérons sur nos techniques de réunions des Amigos depuis plusieurs mois maintenant. Nous n'avons pas fait un Example Mapping sur toutes les stories. Par exemple, les stories de conception sont généralement suffisamment bien couvertes par le document de conception Invision. Ce qui est important, c'est que nous nous attaquons au problème. Le feedback de mes coéquipiers est qu'ils ont une bien meilleure compréhension de chaque story avant même que nous commencions à en parler durant l'IPM. Il y a peut-être encore des questions et des conversations au sujet de la story, mais cela va plus loin dans les fonctionnalités de la story parce que les éléments de base sont déjà là. Et notre taux de rejet de stories a diminué, tout comme notre temps de cycle !<br/>
<br/>
==Un modèle pour structurer une conversation==
Lors de la réunion pré-IPM des "Amigos", chaque story est enrichie d'un but/objectif, de règles, d'exemples, voire même d'un scénario ou deux. Nous avons constaté que le but ou l'objectif est crucial : quelle valeur cette story apportera-t-elle ? La combinaison des règles et d'exemples qui l'illustre fournit les bonnes informations pour rédiger des tests métier qui guident le développement. Voici un exemple des résultats issus de l'Example Mapping d'une story sous Tracker :<br/>
<br/>
[[Fichier:ExampleMap-1.png|border|800px|link=]]<br/>
<br/>
Les développeurs utilisent les informations pour les aider à écrire des tests pour guider le développement. Idéalement (du moins à mon avis), il s'agirait de tests BDD sur Cucumber. L'Example Map fournit des personas et des scénarios ainsi que les règles. Cependant, il est parfois plus logique d'utiliser les tests rspec fonctionnels existants ou les tests unitaires Jasmine pour le JS.<br/>
<br/>
Lorsqu'un couple de développeurs commence à travailler sur une story, ils ont une conversation avec un ou plusieurs testeurs, de sorte que nous sommes tous sur la même longueur d'onde. Lorsque des questions surgissent, nous convoquons de nouveau les Amigos pour en discuter.<br/>
<br/>
Les user stories font office d'espace de conversation. Des techniques comme l'Example Mapping aident à structurer ces conversations et à s'assurer que tous les membres de l'équipe de livraison partagent la compréhension qu'a le client des fonctionnalités que cette story devrait fournir. Comme nous sommes une équipe distribuée, nous voulons un endroit où conserver les résultats détaillés de ces conversations. Mettre des Example Maps dans des stories fonctionne très bien pour cela.<br/>
<br/>
L'Example Mapping est simple et facile à essayer. Demandez à votre équipe de l'essayer avec vos Amigos un jour ou deux avant votre prochaine réunion de planification d'itération. Si cela ne fonctionne pas bien pour vous, il y a beaucoup d'autres techniques que vous pouvez essayer ! J'espère couvrir certains de ces sujets ici au cours des prochaines semaines.