« Expérimenter avec l'Example Mapping » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (6 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
[[Catégorie: Portail Product Owner]] | [[Catégorie: Portail Product Owner]] | ||
[[Category: Portail Equipe de développement]] | |||
[[Catégorie: Example Mapping]] | [[Catégorie: Example Mapping]] | ||
[[Catégorie: BDD]] | [[Catégorie: BDD]] | ||
[[Catégorie: Tests]] | [[Catégorie: Tests]] | ||
[[Category: Tres Amigos]] | |||
[[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/> | Source : [https://lisacrispin.com/2016/06/02/experiment-example-mapping/ Experiment with Example Mapping]<br/> | ||
Date : 02/06/2016<br/> | Date : 02/06/2016<br/> | ||
| Ligne 14 : | Ligne 18 : | ||
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/> | 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/> | <br/> | ||
[[Fichier:ExampleMapJoellen-1.png|border|800px]]<br/> | [[Fichier:ExampleMapJoellen-1.png|border|800px|link=]]<br/> | ||
<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 | 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 Tres 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== | ==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/> | 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/> | ||
| Ligne 22 : | Ligne 26 : | ||
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/> | 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== | ==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 " | 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 "Tres 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/> | <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/> | 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/> | ||
| Ligne 33 : | Ligne 37 : | ||
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/> | 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/> | <br/> | ||
[[Fichier:ExampleMap-1.png|border|800px]]<br/> | [[Fichier:ExampleMap-1.png|border|800px|link=]]<br/> | ||
<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/> | 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/> | ||
| Ligne 41 : | Ligne 45 : | ||
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/> | 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/> | <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. | |||
