Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

Scrum : une histoire de lave-linge

    Home Java Scrum : une histoire de lave-linge

    Scrum : une histoire de lave-linge

    Par Nicolas Martignole | Java | 3 commentaires | 2 novembre, 2008 | 0 | 1 859 affichages
         

    J’ai trouvé la métaphore ultime pour expliquer à un client le fonctionnement des Sprints de Scrum.

    Comme vous le savez le Client, le Scrum Master et l’Equipe se réunissent au début de chaque Sprint au cours d’une réunion de 2 heures afin de fixer la liste des développements pour le prochain Sprint. Autour de la liste des fonctionnalités à développer (le product backlog) l’objectif en 2 heures est que le Client finalise avec l’Equipe la liste des développements à venir pour le prochain Sprint. Ensuite un des principes de Scrum est que lorsque l’équipe développe, elle ne doit pas être interrompue. Ce principe permet à l’équipe de travailler efficacement sans être perturbée en permanence par ce que j’appelle des « fausses urgences ». Le Client est en quelque sorte tenu de respecter cette règle. Et croyez-moi, au final cela fonctionne mieux que d’interrompre en permanence une équipe de développement.

    Revenons au titre de ce billet. Comment expliquer à un Client que l’équipe ne peut produire qu’une quantité limitée d’éléments dans les 2 semaines à venir ? Comment lui expliquer qu’il doit alors faire un choix et donner une priorité pour chaque élément ? Comment lui expliquer qu’il ne pourra pas changer le contenu du sprint ?

    Prenez une machine à laver le linge.

    Vous avez un tas de linge sale : voici votre Product Backlog. Votre famille « alimente » en permanence ce Product Backlog chaque jour. De la même façon en Scrum les clients peuvent mettre à jour le product backlog en permanence.

    Ensuite prenons notre lave-linge : il ne peut laver qu’une certaine quantité de linge à chaque programme. Par exemple 5 Kg. Et bien de la même façon, une équipe ne peut produire qu’une certaine quantité de fonctions par itération. Un Sprint de Scrum est donc égal à un lavage en machine. Pour expliquer à un client pourquoi l’équipe refuse de prendre plus d’éléments, je me sers de cette image. Je peux aussi lui dire que sa voiture n’a que 40 litres d’essence dans le réservoir. Il doit s’en contenter. Il faut donc que le client comprenne que « la capacité de production est limitée » et que c’est l’équipe qui annonce cette capacité.

    Ensuite regardons ensemble ce que fait quelqu’un qui prépare une nouvelle machine : il prend le tas de linge sale et ensuite il va le trier en prenant soin de laver en premier les vêtements qu’il lui faut pour le lendemain, et il écartera les vêtements qui peuvent attendre la prochaine machine. C’est de la gestion de priorité. Tout comme Scrum. Je pousserai bien le vice jusqu’à expliquer qu’un Sprint de callibrage où l’on recherche une solution, un Sprint de release où l’on prépare une version, me font penser à un programme « Coton » et un programme « Blanc Programme Long »…

    Enfin vient le temps du lavage, ce qui nous permet d’expliquer 2 notions : la non-modification d’un sprint et la durée fixée.

    Tout d’abord il n’est pas possible d’arrêter un programme en cours de lavage pour y ajouter une chemise oubliée. Tant pis pour vous, elle sera lavée avec la prochaine machine. Même pire, je pense que si vous pouviez mettre en pause un programme, cela serait un risque pour l’ensemble du linge déjà en cours de lavage : risque de surcharge de la machine, risque que la chemise ne soit pas bien lavée finalement…
    Durant un Sprint de Scrum il n’est pas possible de changer le contenu du Sprint. Vous devez laisser l’équipe terminer son travail. La gestion des patches et des bugs urgents doit être prévue en dehors du temps alloué à Scrum. Si votre activité de correction de bug représente 4 jours sur 10 en moyenne, alors votre équipe ne doit « faire du scrum » que sur une base de 6 jours, même si le sprint dure bien 10 jours.

    La durée fixée en Scrum est aussi très importante car elle permet par observation de suivre l’activité de l’équipe et de créer des statistiques afin de pouvoir ensuite fonctionner de mieux en mieux.

    Enfin je ne pousse pas plus loin la métaphore, pensez à Scrum lorsque vous lancerez votre prochain programme en « Coton délicat 40 degrés avec essorage »

    Articles similaires:

    Default ThumbnailPremiers jours avec Scrum : une histoire de Sprint Backlog qui disparait Default ThumbnailLe mythe de l’application Lave-Linge de ta grand-mère Default Thumbnail3 exemples de tableaux Scrum Default ThumbnailProchaine soirée Paris JUG sur Scrum et les méthodes Agiles
    scrum
    • Avatar
      jérémy Sevellec 3 novembre 2008 at 10 h 34 min

      J’adore la métaphore… C’est énorme!…

      Le plus drôle c’est la partie de la métaphore concernant le linge sale!!

      Il fallait la trouver! Bien joué.

    • Avatar
      SoftGUI 3 novembre 2008 at 10 h 51 min

      Cette métaphore je l’appliquerai plutôt au traitement des bugs (le vrai linge sale d’une équipe de dev).
      Pour la production nouvelle on pourrait aussi bien utiliser la liste de course avec un budget fixe, faut faire son choix et être capable de faire un vrai repas avec ce qu’on a acheté.
      Qu’en penses-tu ?

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    •  @steeve  Agree. Those conversations remind me the old Paris Java User Group beer talks we had after each event cc  @mfiguiere   @DidierGirard 

      1 day ago
    • RT  @_yom_ : Allez Twitter sois sympa et passe le mot autour de toi : on cherche toujours la perle rare qui voudra bien donner de l'amour aux…

      1 day ago
    •  @dorianmariefr  Ben ce sont les chiffres officiels (je fais ma DA cette semaine) 😉

      2 days ago
    • Doctolib c’est 1580 personnes dont 350 personnes « Produits/Tech » (chiffre officiel jan 2021)

      2 days ago
    •  @rophilogene  Par exemple Doctolib Médecin c’est un outil SaaS très simple qui remplace les vieux logiciels installé… https://t.co/selHtXAi8s

      2 days ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express