6.3. Jouer avec les fiches

Nous voyons souvent des équipes Agile utilisant un ordinateur et un vidéo-projecteur lors de leurs réunions de planification pour capturer les user stories. Ce procédé tue les conversations parce l'équipe regarde l'écran projeté en attendant qu'une personne mette à jour chacune des stories. Présentez les fiches (ou des posts-its) comme un autre moyen pour enregistrer les conversations sur les user stories. Il est beaucoup plus facile de regrouper les stories sous forme de fiches dans des itérations en les faisant tourner autour de la table que de les déplacer d'une ligne à l'autre dans une feuille de tableur.

Lancez l'équipe en vous impliquant afin de lui démontrer comment utiliser les fiches pour les stories. Inscrivez chaque story que vous entendez sur une nouvelle fiche et disposez-les sur la table où tout le monde peut les lire au cours de la conversation. A partir de là, n'importe qui dans la conversation peut contribuer à en écrire une nouvelle.

Vérifiez que ce que vous avez inscrit sur une fiche retrace bien ce qui a été dit. Si ce n'est pas le cas, suggérez au client de corriger ou réécrire la fiche. Étant donné que la story, objet de la discussion, va changer, ajouter des notes à la fiche ou déchirez-la et écrivez-en une nouvelle.

Rachel dit…

Déchirez-les

---

Rappelez-vous que les fiches reflètent votre compréhension courante des user stories. Si suite à une discussion, la story change, n'ayez pas peur de déchirer les fiches sur lesquelles vous avez travaillé et d'en créer de nouvelles.

Je m'attends à avoir quelques cartes déchirées à chaque réunion de planification. Lorsque ce n'est pas le cas, je me préoccope du fait que l'équipe ne s'engage pas avec son client et ne le questionne pas sur le fait que les user stories pourraient être découpées différemment.

Montrez comment utiliser des fiches puis arrêtez.

La réunion continuant, arrêtez d'écrire vous-mêmes les fiches. Lorsque quelqu'un suggère une nouvelle idée, invitez-le à rédiger sa propre fiche. Vous pouvez dire quelque chose comme “Nous ne voulons pas oublier ce point, pouvez-vous l'écrire sur une fiche ?” ou plus simplement attendez jusqu'à ce que quelqu'un prenne un stylo et le fasse sans qu'on lui ait demandé. Ceci arrive tout à fait naturellement parce que lorsque plusieurs personnes discutent ensemble, une seule personne prenant des notes n'arrive pas à suivre et vous verrez alors bientôt toute l'équipe s'y mettre.

Disposez un paquet de fiches et de stylos au milieu de la table de telle façon que n'importe qui peut rédiger une fiche. Nous avons observé que travailler avec des fiches sur une table ne fonctionnait seulement qu'avec des petits groupes autour de petites tables. Pour des groupes de plus de cinq personnes, proposez de passer d'une disposition horizontale à verticale : vous pouvez utiliser des posts-its sur un mur (ou sur un tableau portatif) ou poser des fiches sur un tableau en papier pré-traité avec de la colle adhésive. Désormais, l'équipe peut voir toutes les fiches sans avoir à se tordre le cou ou à lire à l'envers.

Faites en sorte que ce soit facile pour l'équipe d'utiliser les cartes à tout moment, pas seulement lors des réunions de planification. Mettez à disposition de l'équipe un grand nombre de fournitures (plutôt que de les verrouiller dans une armoire) et des outils de rangement : boîtes à CD, pochettes en plastique et des reliures.

Utilisez une mise en page cohérente des stories sur les fiches.

Rappelez à l'équipe que ces fiches finiront sur le tableau de tâches de l'équipe et que l'équipe s'y référera pendant ses daily standup ; cela aide donc d'utiliser une mise en page cohérente pour les user stories. Commencez avec un titre court tout en haut. Référencez-les avec des numéros, certaines équipes le font, discutez sur les stories que vous avez du mal à suivre. Écrivez le titre lisiblement avec un marqueur, assez gros pour que cela puisse être lu par l'équipe sans qu'elle ait à aller jusqu'au tableau pour le déchiffrer. Cela aide aussi si l'équipe prend l'habitude d'écrire ses estimations (voir le chapitre 7.3. Dimensionner le travail) au même endroit sur la fiche, par exemple dans le coin en bas à droite.

Modèles de story

Lorsqu'une équipe s'essaye pour la première fois aux user stories, vous pouvez lui recommander d'utiliser un modèle de story tel que :

”En tant que… utilisateur, Je veux… capacité pour… bénéfice.”

Par exemple :

”En tant que acheteur potentiel d'un livre, Je veux voir les commentaires des autres lecteurs de ce livre pour pouvoir me décider à l'acheter ou non.

Ce modèle aide l'équipe à se rappeler de clarifier qui est l'utilisateur et quel bénéfice on attend du développement de cette story.

L'équipe a besoin de bien comprendre qui sont les différents types d'utilisateur afin de pouvoir remplir la partie En tant que. Vous pouvez suggérer à l'équipe de créer une cartographie des parties prenantes ou d'élaborer des profils d'utilisateurs typiques (personas). C'est encore mieux si l'équipe sort rencontrer des utilisateurs réels dans le contexte d'utilisation du logiciel.

Nous avons rencontré des équipes qui utilisaient religieusement le modèle de story sans réellement se poser la question de l'utilisateur final de la story. Ils essayaient de faire tout rentrer dans le modèle de story, en écrivant des stories de la forme “En tant que développeur…” ou “En tant que moteur de flux XML…”. Expliquez leur que s'il n'y a pas d'interaction avec un utilisateur alors l'utilisation de ce modèle ne permettra pas à l'équipe de mieux comprendre le besoin et donc qu'il n'est pas nécessaire de l'utiliser.

Rappelez à l'équipe que l'objectif d'un modèle de story est d'aider l'équipe à apprendre à poser des questions qui améliorent leur compréhension plutôt qu'un formulaire à remplir. Une fois que l'équipe a l'habitude de travailler avec des user stories, l'équipe peut abandonner le modèle de story. Un titre court est suffisant et toutes autres notes sur les fiches constituent des moyens simples pour se rappeler de la conversation, ni plus ni moins. Que l'équipe utilise ou non un modèle, écrivez toujours la user story dans un langage qui soit compréhensible par toute l'équipe y compris le client.

Après que les stories aient été implémentées dans un logiciel opérationnel, l'équipe s'appuie sur les tests, pas les fiches, pour avoir des détails sur les stories. L'équipe peut jeter les fiches même si quelquefois relire la fiche originale permet de se remémorer de la conversation dont elle est issue ; ce qui peut être utile si l'équipe a besoin d'ajouter des stories en rapport dans les itérations suivantes. La plupart des équipes avec qui nous avons travaillé, gardent des paquets de fiches des itérations précédentes dans ce but, mais finalement elles s'y référent rarement.