« 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 19 : | Ligne 19 : | ||
==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/> | 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/> | <br/> | ||
