Elephant Carpaccio

Elephant Carpaccio est un exercice d’Alistair Cockburn pour apprendre à découper très finement un besoin en tranches verticales. Les participants travaillent sur un petit calculateur de prix de vente : il prend une quantité, un prix unitaire et un État, puis applique une taxe selon l’État et une remise selon le montant. En binômes ou trinômes, ils découpent d’abord l’application en 15 à 20 tranches livrables et visibles par l’utilisateur. Ils développent ensuite pendant 40 minutes, en 5 itérations de 8 minutes, avec une démonstration à la fin de chacune. L’exercice fait vivre la valeur livrée tôt, le feedback rapide et la différence entre découpage technique et découpage vertical.

Déroulé

1. 1

   Installer le cadre et l’objectif

   10 min

   L’animateur présente l’exercice : « Votre défi n’est pas de finir une application parfaite, mais de livrer très tôt des morceaux visibles et utilisables. » Il annonce le sujet : un calculateur qui prend une quantité, un prix unitaire et un État, puis applique une taxe selon l’État et une remise selon le montant. Il précise la durée totale, 90 à 120 minutes, et le cœur de l’exercice : 40 minutes de développement en 5 itérations de 8 minutes. Les participants se mettent en équipes de 2 à 3 personnes, idéalement avec un poste de travail par équipe.

   Astuce — Insistez dès le départ sur le mot « visible » : une tranche qui ne change rien pour l’utilisateur final sera questionnée pendant le débrief.

2. 2

   Clarifier le produit attendu

   10 min

   L’animateur décrit le comportement cible sans entrer dans une solution technique : « L’utilisateur saisit une quantité, un prix unitaire et un État ; le système calcule un prix de vente en tenant compte d’une taxe liée à l’État et d’une remise liée au montant. » Il vérifie que tout le monde comprend les entrées, les sorties et la notion de règle métier. Si un support de règles de taxe et de remise est utilisé, il le distribue maintenant et demande aux équipes de s’y référer. Les participants peuvent poser uniquement des questions de compréhension du besoin, pas de conception.

   Astuce — Ne répondez pas aux questions par de l’architecture ; ramenez toujours à l’usage : « Que verrait l’utilisateur ? Quel résultat pourrait-il vérifier ? »

3. 3

   Découper en 15 à 20 tranches verticales

   20 min

   Chaque équipe découpe l’application en 15 à 20 tranches, chacune livrable et visible par l’utilisateur. L’animateur donne la consigne : « Une tranche doit produire un comportement démontrable, même minuscule ; évitez les tranches du type base de données, écran, moteur de calcul ou tests seuls. » Les équipes écrivent leurs tranches dans un ordre possible de livraison, de la plus simple à la plus riche. L’animateur circule et challenge les découpages trop gros ou trop techniques en demandant : « Que pouvez-vous montrer en moins de 8 minutes ? »

   Astuce — Quand une équipe propose une tranche trop large, demandez-lui de la couper jusqu’à obtenir une version presque embarrassante de simplicité, mais démontrable.

4. 4

   Sélectionner les premières tranches

   10 min

   Les équipes relisent leur liste et choisissent la première tranche à développer. L’animateur rappelle la contrainte : « Dans 8 minutes, vous devrez faire une démonstration, même si c’est incomplet. Choisissez une tranche qui peut réellement être montrée. » Les participants peuvent réordonner leurs 15 à 20 tranches pour maximiser l’apprentissage rapide. L’objectif est de commencer par une livraison visible, puis d’ajouter progressivement taxes, remises, cas particuliers ou confort utilisateur selon le découpage choisi.

   Astuce — Faites reformuler à voix haute la première tranche par chaque équipe ; si elle contient « préparer », « installer » ou « concevoir », elle n’est probablement pas encore verticale.

5. 5

   Développer en 5 itérations de 8 minutes

   40 min

   L’animateur lance le chronomètre pour 5 itérations de 8 minutes. À chaque itération, l’équipe choisit une ou plusieurs tranches très petites, développe, puis s’arrête net à la fin du temps imparti. La règle est stricte : à la fin de chaque période de 8 minutes, il y a une démonstration de ce qui fonctionne, même si c’est minimal. L’animateur annonce régulièrement le temps restant et encourage les équipes à réduire leur ambition plutôt qu’à repousser la démonstration.

   Astuce — Annoncez clairement « mi-temps », puis « 2 minutes », puis « 30 secondes » ; cela force les décisions de coupe et évite les tunnels de développement.

6. 6

   Faire les démonstrations à chaque fin d’itération

   15 à 25 min inclus dans le rythme des itérations

   À la fin de chaque itération de 8 minutes, chaque équipe montre brièvement ce qui est utilisable. L’animateur demande : « Quelle tranche avez-vous livrée ? Que peut faire l’utilisateur maintenant qu’il ne pouvait pas faire avant ? » La démonstration doit porter sur le comportement du calculateur, pas sur le code ou l’architecture. Les autres participants observent la finesse des tranches, l’ordre de livraison et les moments où une équipe a obtenu du feedback utile.

   Astuce — Limitez fermement les explications techniques : si l’équipe ne peut pas montrer un comportement, notez-le comme matière de débrief plutôt que de laisser justifier longuement.

7. 7

   Débriefer les apprentissages

   20 à 25 min

   L’animateur rassemble les équipes et fait comparer les trajectoires : premières tranches livrées, moments de blocage, feedback obtenu, valeur visible. Il recentre sur les trois thèmes clés : qu’est-ce qu’une bonne tranche, comment livrer de la valeur tôt, et comment le feedback rapide influence les choix. Les participants identifient les tranches trop grosses, trop techniques ou trop tardives. L’animateur conclut en demandant comment transposer ce découpage à leurs vrais produits ou projets.

   Astuce — Demandez des exemples précis de tranches écrites par les équipes ; le débrief devient beaucoup plus puissant quand on retravaille leurs formulations réelles.

Variantes

• Variante accélérée : conserver le même principe mais réduire le temps de cadrage et de découpage pour des participants déjà familiers de l’agilité. Garder impérativement les 5 itérations de 8 minutes et la démonstration à chaque fin d’itération.
• Variante sans développement réel : les équipes ne codent pas, mais produisent des maquettes, exemples de résultats ou scénarios exécutables à la main. La contrainte reste identique : 15 à 20 tranches, chacune livrable et visible par l’utilisateur.
• Variante à distance : créer des sous-salles de 2 à 3 personnes, un tableau partagé pour les 15 à 20 tranches et un chronomètre visible. À chaque fin d’itération de 8 minutes, toutes les équipes reviennent en salle principale pour une démonstration courte en partage d’écran.
• Variante centrée produit : demander aux équipes de nommer explicitement la valeur utilisateur de chaque tranche avant de développer. Cette variante renforce le lien entre découpage vertical et décision de priorité.