Extreme Carpaccio

Dans cet article, j’explique l’histoire et le fonctionnement de l’exercice Extreme Carpaccio. En résumé, Extreme Carpaccio est un exercice de code en mode compétition où les participants doivent découper un problème et implémenter la solution en suivant le découpage. Un serveur centralisé envoie des requêtes aux participants et comptabilise les points de chaque équipe en fonction des réponses, bonnes ou mauvaises.

Si vous cherchez à savoir plus sur le problème à résoudre, allez directement dans la partie Problème à Résoudre. Si vous cherchez à avoir plus d’informations sur comment se déroule une session d’Extreme Carpaccio, allez directement dans Plan de Séance.

Contexte

Fin 2015, j’ai démarré une mission chez une banque d’investissement française très connue, en tant que Software Craftsmanship evangelist. Depuis quelques années, cette même banque a lancé en interne un ambitieux programme pour mettre en place le Continuous Delivery. J’ai donc rejoint l’équipe de coaches agiles et techniques en tant que Coach Craftsmanship (terme utilisé par le client) en charge du programme. Ma mission était d’aider les équipes de développement à améliorer la qualité et la stabilité de leur logiciel, ainsi que leur processus de livraison, tout en introduisant des pratiques telles que le TDD, le clean code, le refactoring constant, le BDD, l’intégration continue, le simple design, entre autres.

Au quotidien, j’ai fait un usage massif d’exercices de coding, autrement appelés code katas, afin d’aider les développeurs à monter en compétences. La plupart des exercices peut facilement être trouvée sur internet. Néanmoins, j’ai quelques fois dû créer des exercices pour mieux adresser des demandes spécifiques des équipes. Dans ce contexte, en cherchant un meilleur moyen d’expliquer le découpage et le développement incrémental, nous avons fusionné (avec Radwane HASSEN – un autre collègue travaillant en tant que coach tech) deux exercices existants, à savoir Extreme Startup et Elephant Carpaccio, pour créer Extreme Carpaccio.

Extreme Startup

Extreme Startup est un exercice de code créé par Robert Chatley et Matt Winne. La première fois que j’ai participé à un Extreme Startup était ici même, chez Xebia pendant un XKE, lors d’une séance organisée par Sébastian Le Merdy, Nicolas Demengel et Jean-Laurent de Morlhon.

Pendant, une séance d’Extreme Startup, le facilitateur utilise son ordinateur pour envoyer des requêtes HTTP avec des questions aux participants. Les participants doivent implémenter des algorithmes pour résoudre les questions et répondre au serveur. Pour chaque réponse correcte, le participant ou son équipe gagne des points ou perdent des points lors qu’une réponse est mauvaise.

Extreme Carpaccio se base sur le même principe : un serveur simule un marché et envoie des requêtes aux participants, qui doivent implémenter la solution. Cette approche est assez ludique, car elle créé une atmosphère de compétition et les participants sont à fond pour essayer de remporter la partie. Néanmoins, contrairement à Extreme Startup, lors d’une séance d’Extreme Carpaccio presque tout le problème est exposé au début aux équipes (et non au fil de l’eau) qui décident comment le découper et l’implémenter.

Elephant Carpaccio

Elephant Carpaccio est un exercice de découpage créé par Alistair Cockburn. Plusieurs collègues coaches utilisent cet exercice pour travailler les aspects du découpage agile avec des équipes.

Lors d’une séance d’Elephant Carpaccio, le facilitateur expose tout le problème et demande aux participants de le découper en user stories, les prioriser et les implémenter de façon itérative. A la fin de chaque itération, les équipes réalisent une démonstration de ce qu’elles ont implémenté. L’objectif est de découper tout le problème en petits morceaux, de telle façon que chaque morceau puisse offrir un retour et de la valeur (soit en terme de connaissances, soit vis-à-vis du client). Dans l’autre sens, sans découpage, il existe un risque de tomber dans une approche cycle en V qui peut demander beaucoup de temps en phase de développement (spécification, test ou autre) et de livrer en production une fois que tout est prêt. Nous savons tous que cette approche amène beaucoup d’inconvénients, notamment l’absence de retour des parties prenantes.

Contrairement à Elephant Carpaccio, Extreme Carpaccio ne guide pas les participants pendant le découpage ou les itérations. En revanche, l’exercice a été conçu pour favoriser ceux qui découpent le problème dans le but de trouver de la valeur au plus vite. Plus on « slice », plus tôt les équipes sont capables de livrer en production et plus vite elles gagnent des points. Ceux qui essaient de tout développer avant de déployer en production vont se voir en queue de classement car ceux qui ont itéré commenceront a gagner des points plus tôt.

Problème à Résoudre

Basé sur Elephant Carpaccio, le problème simule une entreprise qui envoie à l’ordinateur de chaque équipe (ici appelés vendeurs) un ordre d’achat. L’ordre contient des prix et quantités de chaque produit vendu, le pays de l’acheteur ainsi que la réduction à appliquer. Forts de ces éléments, les équipes doivent calculer le prix total et répondre au serveur avec une facture contenant le prix. Si la réponse est correcte, l’équipe gagne la somme de points équivalente au montant de la facture. Sinon, les équipes perdent des points correspondant à la moitié du prix correct de la facture. En cas de mauvaise réponse, le serveur envoie un feedback au client avec le montant attendu pour la dernière facture. Les équipes peuvent se baser là-dessus pour corriger leurs règles de calcul.

Voici un exemple de requête envoyé par le serveur aux participants :

Exemple d’ordre d’achat

{
    "prices": [65.6,27.26,32.68],
    "quantities": [6,8,10],
    "country": "FR",
    "reduction":"STANDARD"
}

Le nombre d’ordres d’achat envoyés par chaque pays varie selon le pays. Ce nombre suit la densité démographique du pays qui envoie l’ordre. L’Allemagne, le Royaume Uni ou la France, par exemple, envoient plus d’ordres d’achat que le Luxembourg, Chypre ou Malte. Cette information n’est pas mentionnée explicitement dans le but d’encourager les participants à échanger avec le facilitateur. Au début, le facilitateur doit encourager les participants à échanger avec lui et même dire qu’il peut y avoir des informations manquantes dans la description du problème. Cela vise à éviter que les équipes partent dans une effet tunnel sans échanger avec les autres ou voir ce qui se passe à côté.

Plan de Séance

Extreme Carpaccio a été conçu pour être joué avec des développeurs et des responsables de produit (product owners). Par contre, il est tout-à-fait possible de jouer l’exercice seulement avec des développeurs.

Pendant une séance d’Extreme Carpaccio :

  1. les participants s’organisent en équipes de 2 ou 3 personnes idéalement, avec 1 responsable de produit et au moins 1 développeur – environ 5 minutes
  2. le facilitateur expose le problème et explique les étapes à venir – entre 5 et 10 minutes
  3. le facilitateur demande aux équipes de découper le problème et de prioriser les users stories – entre 10 et 20 minutes
  4. le facilitateur démarre le serveur, demande aux équipes de s’enregistrer via le tableau de bord du serveur – entre 5 et 15 minutes selon le nombre de participants, des éventuels problèmes réseau, etc.
  5. une fois tout le monde enregistré, le facilitateur autorise les équipesà démarrer le développement – entre une demi-heure et une heure
  6. rétrospective – environ 15 minutes.

L’exercice se déroule entre une heure et demie à deux heures généralement. Pendant la séance, le facilitateur doit tourner parmi les équipes afin de s’assurer que toutes sont dans la course et que personne n’est bloqué. La plupart du problème à résoudre est exposé en début de séance, mais pas entièrement (voir section Faire Varier la Réduction). Les équipes doivent essayer de découper le problème en suivant la stratégie qu’ils ont choisie et l’information qu’ils ont jusqu’à présent.

A la fin, prenez quelques minutes pour faire une rétrospective et demander aux participants ce qu’ils ont appris ou s’ils ont quelque chose à partager. Je demande généralement aux personnes qui sont arrivées en tête de classement d’expliquer la stratégie de découpage qu’ils ont choisi. Les rétrospectives sont souvent très riches et je suis fréquemment étonné de découvrir des nouvelles façon de résoudre le problème.

extreme-carpaccio-xke.jpgSéance d’Extreme Carpaccio déroulée en XKE

Faire Varier la Réduction

Pendant la séance, les choses commencent à se stabiliser et quelques équipes vont se retrouver en tête du classement et les autres au milieu ou à la fin. A ce moment-là, afin de mettre au défi les équipes de tête et essayer de secouer le score, le facilitateur peut changer brutalement la stratégie de réduction côté serveur. Ces nouvelles stratégies de réduction ne sont décrites nulle part et les équipes doivent arrêter ce qu’elles sont en train de faire et essayer de comprendre comment calculer les nouvelles réductions (en fait c’est facile, il suffit de regarder l’ordre et le feedback du serveur et faire le calcul à l’envers). En faisant cela, nous permettons aux équipes en milieu de classement de challenger les équipes en tête. Cela vient contrer le côté « prédictible » de l’exercice, qui peut arriver lors qu’une équipe part en tête depuis le début et prend trop d’avance sur les autres.

Faits Intéressants

Un fait intéressant que j’ai remarqué pendant les séances d’Extreme Carpaccio que j’ai animées, est la façon dont les équipes abordent le découpage lors qu’un product owner est à bord. Généralement, dans une audience ne comptant que des développeurs, les participants ont tendance à mettre en production beaucoup plus tard que lorsqu’un product owner est dans l’équipe. Les product owners prennent naturellement le lead sur la stratégie de découpage alors que les développeurs ont tendance à partir directement sur l’implémentation sans avoir la vue d’ensemble ou avoir une stratégie de découpage établie.

Un autre fait intéressant qui arrive de temps en temps est le fait que les développeurs essaient de se hacker ou hacker le serveur. Personnellement, je trouve cela très intéressant car cela amène les participants à penser « en dehors de la boîte » avec des possibilités et contraintes qui n’ont pas été mentionnées. Cela arrive généralement lors de séances constituées majoritairement de développeurs ou lorsque l’on se met d’accord dès le début sur les règles du type « tout est possible ». Les hacks le plus souvent employée sont le Déni de Service sur le serveur ou l’usurpation d’identité du serveur pour envoyer de fausses requêtes aux autres participants, leur faisant perdre du temps. Je n’ai jamais eu des problèmes avec cela car les développeurs naturellement essaient de taquiner les gens qu’ils connaissent sans quelconque incident diplomatique.

Les sources d’Extreme Carpaccio et plus d’instructions sont disponibles sur Github. Vous pouvez aussi suivre des séances Extreme Carpaccio sur Twitter.

Cet article est une traduction libre, faite avec l’autorisation de l’auteur, de « Extreme Carpaccio » publié par Diego Lemos le 07/01/2016 sur http://diegolemos.net/2016/01/07/extreme-carpaccio/.

Publié par

Publié par Diego Lemos

Diego s’est forgé une solide expérience dans l'écosystème Java. Depuis, longtemps convaincu par l’agilité, Diego a participé à des nombreux projets agiles, d’abord en tant que développeur, puis en tant que scrum master et ensuite coach technique. Diego dispose d’un vaste panel de compétences sur l’ensemble de l’écosystème JVM, et notamment les solutions du monde open-source.
Passionné par l’informatique, il a eu l’occasion de d’intervenir sur des missions techniques très variées, notamment en tant que en tant que développeur frontend et sysadmin. Cela fait de Diego un expert technique full stack.
Il a joué un rôle important dans des projets de grande envergure, en tant que coach technique, notamment autour de la mise en place de pratiques tels que le Continuous Delivery à l’échelle. Aujourd’hui, Diego intervient principalement en tant que formateur, consultant et coach technique sur des sujets tels que le testing, le design du code, le software craftsmanship et le continuous delivery.
Blog personnel : http://diegolemos.net
Twitter : @dlresende.

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.