« Expérimenter avec l'Example Mapping » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 12 : | Ligne 12 : | ||
[[Fichier:ExampleMapJoellen-1.png|border|800px]]<br/> | [[Fichier:ExampleMapJoellen-1.png|border|800px]]<br/> | ||
<br/> | <br/> | ||
Vous pouvez utiliser l'Example Mapping dans vos 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/> | 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== | ==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 18 : | Ligne 18 : | ||
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 "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/> | |||
