Afin de vous permettre de vous exercer à découper les users stories de vos backlogs en tranches très fines, nous publions ici avec l’autorisation des auteurs la traduction du guide de facilitation. Lors d’un Meetup Software CraftmanShip Toulousain, nous avons hébergé dans nos locaux une session et l’exercice s’est révélé très enrichissant pour les participants. Nous vous invitons vous aussi à faire cet exercice et à nous faire vos retours sur les leçons apprises à l’issue de la séance. Bon Carpaccio !

Exercice Elephant Carpaccio

Guide de facilitation

par Henrik Kniberg et Alistair Cockburn, 11 juillet 2013

Traduit en français par Frank Taillandier

Qu’est-ce que c’est ?

L’exercice de l’Eléphant Carpaccio est un très bon moyen de pratiquer et d’apprendre comment découper des stories en tranches verticales très fines. Cela amène également à avoir des discussions intéressantes sur la qualité et les pratiques techniques.

Cet exercice a été inventé par Alistair Cockburn. Nous l’avons co-facilité ensemble à de nombreuses reprises et encourageons les gens à l’organiser partout dans le monde.

Ceci est une version détaillée (Niveau Shu) du guide de facilitation basée sur la manière dont Alistair a l’habitude de faire, avec en plus quelques adaptations mineures d’Henrik.

Cet exercice prend de 1h30 à 2h et peut se déroule aussi bien en petit qu’en grand comité.

Durée

Deux heures idéalement, peut se faire également en 1h30 mais de manière un peu bâclée.

• 15 à 20 minutes de discussion sur les user stories
• 20 à 30 minutes de découpage de backlog
• 40 minutes de code
• 15 à 20 minutes de debrief

Il est possible de ne pas coder et de se focaliser uniquement sur la partie de création du backlog, mais c’est moins fun et vous êtes également susceptibles de passer en fin de session à côté de discussions intéressantes sur la qualité de code.

Préparation

• Imprimez cet énoncé pour tous les participants ou recopiez la seconde partie sur un tableau blanc.
• Assurez-vous qu’au moins la moitié des participants possèdent un ordinateur avec un environnement de développement fonctionnel. C’est pas grave s’il y en a moins, mais il faut qu’à minima un tiers des participants en ait un.
• Assurez-vous qu’il y a des prises électriques dans la pièce
• Il n’y a pas vraiment besoin d’Internet pour cet atelier, mais c’est utile de pouvoir faire des recherches lorsqu’on programme.

Déroulé de l’atelier

Introduction

• Le but de cet atelier est d’apprendre à découper des stories en tout petits morceaux.

Pourquoi découper les stories (optionnel)

Cette partie n’est utile que si vous n’avez pas déjà discuté de l’intérêt de découper les stories.

• Une story = verticale, testable, apporte de la valeur pour l’utilisateur, traverse plusieurs couches architecturales
• Découpage de stories = obtenir des stories plus fines (mais toujours verticales)
• Quelle taille font vos stories ? Vos tâches ? Vos commits ? (l’indiquer sur l’échelle de taille)
• Objectif : Story: Quelques jours Tâche : Quelques heures Commit : plusieurs fois par heure
• Pourquoi découper les stories ? En discuter deux par deux (demander à chaque paire de faire un compte-rendu, demander ce qu’il manque, ajouter
  • Apprendre plus vite. Livre plus souvent. Des parties prenantes plus heureuses. Meilleure synchronisation des personnes et des équipes. Une meilleure privatisation. Un meilleur produit livré plus tôt. Plus d’options pour le business. Moins de risque (moins de temps « sous l’eau »). Plus de sens de la vélocité. Planning facilité.
• Dessiner les courbes de valeur pour la cascade, les grosses stories et les petites stories. Discutez. Pourquoi la courbe des « petites stories » se termine avec une valeur cumulée plus élevée ?
• Pour décider de la taille, il ne faut pas s’arrêter à « Nous ne pouvons pas découper cette story ». Dans cet atelier, nous allons pratiquer en exagérant volontairement. Nous allons créer des stories si minuscules que tout ce que vous ferez vous paraîtra grand en comparaison.

Ce que nous allons faire

• construire une application simple en 40 minutes, divisé en 5 itérations de 8 minutes
• Beaucoup développeraient cette application en découpant en 2-3 tranches, nous la découperons en 15-20 tranches.
• Elephant Carpaccio = tranches très fines, chacune a quand même la forme de l’éléphant, ensemble elles constituent l’éléphant entier.
  

Le produit

• Fermez vos ordinateurs portables ! (ou les gens vont passer leur temps dans leur environnement au lieu d’écouter)
• Demandez aux participants de lire l’énoncé
• Nous allons développer un calcul de ventes. c’est une application avec une interface utilisateur, trois entrées et une sortie.
  • utilisez n’importe quel language. L’interface peut être la console, la ligne de commande, le web, une interface graphique, peu importe.
• Trois entrées :
  • Combien d’articles
  • Prix de chaque article
  • Code de l’État US de deux lettres
• Sortie: Prix total de la commande. Appliquer une réduction basée sur le montant total, puis ajouter la taxe fédérale correspondant au code de l’état et au prix réduit.

Les priorités

• Je vais représenter les priorités sur cette courbe de valeur
• L’objectif est 5 remises, 5 états.
• 
• Vous allez découper ça en 15-20 tranches.
• Une tranche n’est valide que si elle comprend UI, entrée sortie et est visuellement distincte de la dernière tranche
• Je veux cinq états avant de m’attaquer aux remises. Pourquoi ? (Pour pouvoir déployer ! La taxe fédérale est une obligation légale, les remises non.)
  
• La validation et une belle interface viendront après les cinq états et les remises. Ne passez pas de temps là dessus avant.
  
• N’embellissez pas ! Exercez-vous à apporter ce qui a le plus de valeur ajoutée en premier, tout le temps. Par exemple, avant d’avoir vos 5 états, ne perdez pas la moindre touche de frappe avec du code relatif aux remises !
• On se moque de jusqu’où vous allez sur cette courbe. L’important est de découper en tout petits morceaux. Si vous arrivez à la fin de l’exercice avec seulement 3 tranches, vous avez perdu votre temps et vous avez perdu de vue l’objectif de cet exercice.

Création du backlog

• Répartissez en groupes de 2 ou 3 (2 c’est mieux). Chaque groupe doit être composé d’au moins un développeur avec un environnement de développement fonctionnel.
• 10 minutes : Ecrivez votre backlog sur papier. (les ordinateurs sont toujours fermés)
  • Ecrivez entre 10 et 20 user stories démontrables (tranches) qui vous amènent de rien à 5 états et 5 remises.
  • Chacun d’entre elle doit être implémentable (interface comprise) en 2 à 6 minutes
  • Toutes les démos comportent de vraies entrées-sorties et sont notablement différentes de la dernière tranche. Aucune tranche n’est composée que d’une maquette ou d’une interface, d’un jeu de données ou d’un test.
• Quelle est votre première tranche ?
  • Tout ce qui est plus gros qu’un hello-word ou qu’un écho avec entrée/sortie est trop gros.
  • Discutez de la valeur de la réduction du risque à implémenter et à livrer un hello-world comme première tranche. Valeur = valeur client + valeur de la connaissance acquise
  • Discutez de la valeur de construire rapidement un squelette de l’application (tous les composants clé de l’architecture sont en place et connectés, mais il n’y a pas de « viande », nous avons donc un squelette qui marche).
• En cours de route vous devriez atteindre l’étape importante du « montant de la commande », où vous avez deux entrées (le nombre d’articles et le prix par article) que vous devez multiplier. Aucune remise ni taxe fédérale.
• Quelle est votre prochaine tranche après le montant de commande ? (elle sera probablement trop grosse, demandez aux participants de la découper plus finement!). Exemple de backlog:
• * Montant de commande, 2 entrées, 1 sortie. Aucune taxe fédérale, aucune remise.
  • Taxe fédérale codée en dur. Toujours 2 entrées et 1 sortie. Le taxe de l’Utah est ajoutée automatiquement. (Nous pouvons mettre en prod dans l’Utah !)
  • 3 entrées (prix par article, nombre d’articles, taxe fédérale) mais seulement deux états supportés. N’importe quel autre renvoie un message d’erreur.
  • Ajout des 3 autres états (discutez de pourquoi ajouter un état à la fois à ce stade n’apporte que peu de valeur – il n’y a pas de risque de réduction de valeur et cela prend littéralement seulement quelques secondes d’ajouter les 3 derniers états d’un coup).
• Point essentiel : Minimum de caractères saisis par tranche ! Nous voulons un maximum de valeur avec un effort minimum ( = Lean !)
• 5 minutes: Faites vos tranches plus fines. Essayer d’avoir au moins 15 tranches.

Comment allons-nous travailler ? (optionnel)

Cet atelier est avant tout sur le découpage de story, mais y ajouter des aspects sur des parties techniques lui donne plus de piquant.

• Comment allez-vous écrire et tester votre code ? Prenez une décision et tenez-vous y. Tenez-vous responsable ! Je me réserve le droit de harasser n’importe quel groupe qui ne le ferait pas.
  • Option 1. TDD. Du TDD à la lettre. Rouge Vert Refactorisation. Commencez chaque tranche en écrivant un test qui se lance mais qui échoue. Puis faites passer le test au vert. Puis refactorisez le code pour le rendre propre.
  • Option 2. Rouge-Vert. Même chose que l’option 1 mais la refactorisation est optionnelle.
  • Option 3. Quelques tests. Vous écrivez quelques tests mais pas pour toutes les tranches, et pas nécessairement en commençant par les tests.
  • Option 4. PPT. (Pas de Putain de Tests).
• Allez-vous programmer en pair (= changer fréquemment), ou associer quelqu’un du business et un programmeur (la personne du business teste, fait des retours et améliore le backlog) ? . Les deux sont bien.

Développement

• 40 minutes, 5 itérations, 8 minutes par itération.
• À la fin de chaque itération, je crierai « Démo ! ». Cela signifie qu’on arrête de coder et qu’on fait une démo de son application à un autre groupe. Puis on retourne coder.
  • On n’arrête pas le chrono entre les itérations ! Donc ne passer pas trop de temps sur la démo.
• Criez « Slice ! » quand vous finissez une tranche.
• C’est parti !
  • Lancer un compte à rebours de 8 minutes. Rappelez vous de le relancer immédiatement après chaque itération. Faite en sorte de garder une trace du numéro de l’itération en cours, c’est vite arrivé de ne plus savoir où on est est.

Revue

• Jusqu’où êtes vous allé ? (indiquez la position approximative de chaque équipe sur la courbe de valeur).
  •  En général : certaines équipes arrivent après 5 états et 5 remises. La plupart des équipes arrivent au moins à encoder la taxe fédérale en dur.
• Combien de tranches aviez-vous ?
• Test d’acceptance :
  • Lancer votre application et entrez ces valeurs: Je suis dans l’Utah, J’achète 978 articles, chaque article coûte 270.99$ (ou choisissez les valeurs que vous souhaitez).
  • Donnez moi le résultat ! (écrivez le résultat de chaque équipe sur le tableau blanc).
  • Pas de tergiversations, vous ne faites que lancer l’application, entrer les données et lisez le résultat obtenu.
  • Comparez les résultats. Souvent les résultats diffèrent, ce qui est marrant. Discutez des raisons pour lesquelles c’est différent. Certaines équipes n’ont pas le support des chiffres décimaux pour les prix d’articles, discutez des fausses assomptions et de comment les détecter.

Débriefing

• Pour les non-développeurs : comment ça s’est passé ?
• Pour les développeurs : comment ça a été ?
  • Quelle est la qualité de votre code ? êtes vous fier de de votre code ? (chaque développeur lève entre 1 et 5 doigts)
    • Ceux qui ont fait du TDD devraient être à 4 ou 5, sinon c’est que vous avez omis ou mal compris la partie refactoring dans le TDD.
    • La plupart des développeurs seront à 1 ou 2. Discutez du piège potentiel des itérations courtes et des petites stories. Discutez de l’importance d’un rythme soutenable et de la qualité et de comment ces aspects sont de la responsabilité des développeurs. (Un principe de base agile : les équipes choisissent la quantité de travail qu’elles peuvent effectuer). Discutez de la pression « perçue » et de la vraie pression.
• D’autres questions ou réflexions ?
• Tour de table : Qu’avez-vous appris ? Qu’allez-vous faire ? Nommez une idée avec laquelle vous repartez aujourd’hui, et une chose que vous ferez différemment à l’avenir.

NdT : Merci à Géry Derbier pour la traduction de l’énoncé de l’exercice.