Estimations agile - Square Game

Contexte de formation/sensibilisation agile

Expliquer les estimations agile à une équipe, un groupe lors d'une formation ou d'un coaching est toujours long et fastidieux.
La réticence à supprimer les estimations en jours/hommes est très forte surtout lorsque nous avons des Managers dans l'assemblée.
Les arguments que nous avançons en tant que formateur/coach sont entendus, mais il faut encre prouver que ça marche vraiment, et la plupart des simulations sont taxées d'être trop simplistes. Après les explications, les exemples et les retours d'expérience les échanges s'éternisent.
Qui n'a jamais vécu ça? En générale, on fini par cloturer le point et passer à un autre thème mais sans avoir convaincu tout le monde.

Le square Game comme solution?

Avec mes collègues Olivier Picaud (@opicaud1 ‏) et Thierry Delestre (@ThierryDelestre), nous utilisons depuis quelques années le jeu des trois carrés (ou avec surfaces patatoïdes) dont il faut estimer la surface en centimètres carrés, puis de refaire cet exercice avec une estimation relative de leur taille, en prenant le premier et le plus petit pour étalon.
Ce jeu fonctionne très bien, mais il est difficile de compiler les résultats en direct et de fournir une analyse chiffrée des résultats en direct surtout lorsque l'auditoire est élargi à une quarantaine de participants 

Facilitez vous la démonstration et essayer le Square Game en ligne, c'est super efficace!

Sans limite de participants, l'animateur peut projeter son écran et lancer une session qu'il doit nommer (ci-dessus "201707"). 

Session en cours lors d'une formation

Une fois la session lancée, les participants peuvent rejoindre la session à l'aide de leur smartphone (ou de leur tablette/PC):

participer à une session avec son smatphone

• Ils se connectent à la session et renseignent un login (au choix)
• Ils doivent estimer la surface des trois carrés A, B et C en cm²
• Puis estimer à nouveau les carrés A, B et C, mais en relatif en utilisant le carré A (qui fait 1 unité au carré - 1u²) comme référence.

Etape 2 : estimations absolues (cm²)

L'animateur voit en temps réel le nombre de personnes qui se connecte, qui répondent aux estimations en absolu (cm²) et ceux qui ont terminé les estimations en relatif.
Il est alors facile d’enchaîner sur le débriefe! On gagne du temps là encore.

L'animateur n'a plus qu'à mesurer à l'écran la taille réelle du carré A, B et C et de renseigner leur surface afin de clôturer la session.

Une fois terminé, l'application s'occupe de tout et vous propose quelques statistiques sur les résultats. Il ne reste plus qu'à s'appuyer sur ceux-ci pour assoir l'argumentaire :

Synthèse de la session

Il est alors facile de parcourir la liste de résultats pour montrer que personne n'a donné toutes les bonnes réponses. Heureusement que certains ont donné des chiffres aberrants car grâce à eux la moyenne des résultats se rapproche de la valeur exacte : Sagesse des foules!

Le calcul des écarts types (à la mesure/à la moyenne) permettent de lancer la discussion suivante :

• Comment peut-on se mettre d'accord sur un nombre de jours quand notre perception est si différente? 
• On sera jamais d'accord sur le temps! On passera donc beaucoup de temps à discuter du nombre d'heure ou de jours plutôt que de discuter du sujet de fond : 
• Quel est le besoin de l'utilisateur? 
• Mais qu'est qu'il y a dans cette User Story? 
• Quelles sont les règles de gestion qui la composent?
• Doit-on mettre en place un nouveau service, impacter un service existant?
• Quels sont les risques auxquels on s'expose et qui nous conduiraient à ne pas la terminer?
• Que peut-on faire pour la terminer efficacement?
• Doit-on expérimenter de nouvelles choses techniques ou fonctionnelles avant de la commencer?
• Peut-elle être prise dans le prochain sprint/le sprint que l'on commence?

 Pour faciliter le discours et la compréhension des principes de base je complète le jeu avec des slides sur l'estimation, ou des posters (je préfère) que j'ai réalisé pour illustrer le propos :

Poster sur les estimations relatives et les indicateurs d'avancement

N'hésitez pas à l'utiliser et à laisser un commentaire sur ce blog. Je suis certain que vos feedbacks permettrons d'améliorer cette première version!

Dans le backlog j'ai déjà noté les améliorations suivantes :

• Prendre en compte les saisies avec virgule (on peut actuellement les saisir, mais seules les parties entières sont comptabilisées). Même si cela ne change rien, cela évite des frustrations, incompréhensions, ou questions inutiles ==> enlever le bruit
• Lors de la clôture de la session, ne demander que la mesure du premier carré A en cm². Les carrés B et C seront calculés automatiquement
• Gestion d'erreurs avancée : aujourd'hui j'affiche trop facilement les traces dans la page
• Clôturer vraiment la session (actuellement si on lance une session avec le nom d'une session existante, on peut la continuer)
• Pouvoir reprendre une session commencée
• Une version en Anglais

Cetifications Scrum.org

Ce n'est pas un gage de compétence, mais ça valide les connaissances et ça fait très plaisir ;-)
La PSMI est vraiment difficile et elles n'ont rien d'évident au premier abord et l'obtenir est le fruit d'un vrai travail personnel.
C'est toujours l'occasion de progresser et de s'assurer que l'on a bien compris comment faire.

Je détiens maintenant deux certifications de scrum.org : 

• Professional Scrum Master level 1
• Professional Scrum Product Owner level 1

Sur la base de cet apprentissage entre formateurs agiles de l'Institut Capgemini Sogeti nous avons monté un cursus de formation qui prépare à la certification PSMI. 

Comme ça fonctionne bien, on construit le même type de cursus de formation pour la certification PSPOI. 
Et maintenant nous devons nous préparer pour la Professional Scrum Developper!

Former les autres et partager les connaissances acquises est toujours très enrichissant et permet de renforcer ses acquis, d'avoir une vision plus complète du sujet.
Ce sera également l'occasion de se remettre un peu plus à la technique et de refaire du dev! C'est cool!

Rétrospectives agiles

La rétrospective en agile (ou pas d'ailleurs) est le moteur de l'amélioration continue.
Les méthodes agiles proposent la mise en oeuvre de rétrospectives a chaque temps fort du projet :

• à la fin d'un Sprint, d'une itération
• à la fin d'une version,
• à la fin du projet

La forme la plus classique pour l'animation de cette cérémonie est la suivante :
L'animation est réalisée par le Scrum Master ou le Facilitateur
Chaque membre de l'équipe formalise sur un post-it et pour la période donnée

• ce qui s'est bien passé (+),
• ce qui s'est mal passé (-),
• ce qui est à améliorer (/>)

On rencontre également souvent une forme légèrement différente dans laquelle on ajoute ce qui reste mystérieux.

Chaque post-it est alors placé sur un tableau dans une case correspondante. Le facilitateur prends alors chaque élément, le lit à haute voix et reformule afin d'être certain d'avoir bien compris le sens de cette contribution. Il rassemble également les post-its par paquets afin de regrouper les éléments qui ont un sens équivalent.
A ce premier niveau l'important est de créer un partage et éventuellement des débats sur des points de vue différents.
Une fois ce premier débrief réalisé l'équipe choisi UNE amélioration qu'elle devra mettre en oeuvre durant la prochaine période.

Sur le papier, c'est très bien, mais dans la durée il arrive parfois que ce format devienne une routine et l'équipe fini par s’essouffler et la rétrospective peut vite devenir une routine.

Il y a quinze jours, un collègue Scrum Master (Olivier Picaud) m'en faisait justement part et cherchait une autre approche de la rétrospective afin de "restimuler" son équipe, qu'elle fasse preuve à nouveau de créativité et d'imagination afin de relever les nouveaux défis à relever et problèmes à surmonter.

Je lui ai donc proposé le format en "étoile de mer"
Quelques références en ligne sur ce modèle :

http://www.areyouagile.com/2013/05/lart-de-la-retrospective/

http://ayeba.wikispaces.com/La+r%C3%A9trospective+en+%C3%A9toile+de+mer

C'est donc le format qu'il a utilisé pour sa dernière rétrospective, et le résultat fut très satisfaisant. L'équipe s'est véritablement lâchée, dans le bon sens du terme et les matériaux récoltés on été très riches. Cela se voit :

Ce qu'Olivier me faisait remarquer également, c'est qu'en lisant cette étoile de mer dans le sens horaire, elle raconte une histoire : c'est l'histoire du Sprint, et ça a du sens! 

Ce qu'il faut retenir, ce qu'il ne faut jamais laisser s'installer une routine au sein de l'équipe, surtout pas lors des rétrospective! Ce moment est trop important pour cela.
Variez les formes, renouvelez-vous. Vous pouvez animer un "Speed Boat" (Innovation Game)  à certains moments, et n'hésitez pas à chercher sur internet de nouveaux formats dès que vous sentez que le format que vous utilisez s'essouffle. Changer de format, c'est changer de regard, c'est se poser les questions sous un autre angle, et donc exercer son regard critique!

Scrumban

Certains clients grand compte disposent d'équipes de support transverses. 


C'est le cas de mon client, chez qui, plusieurs de ces équipes ont essayé de mettre en place Scrum ou Kanban en attendant une révolution complète et utopique pour passer à une organisation "Full Agile". Dans cet effort ils ont été confrontés à plusieurs problèmes. 
Voici deux des écueils les plus répandus :
Ces équipes souhaitent trouver une méthode agile leur permettant de suivre leurs activités et de gérer au mieux leurs priorités - souvent changeantes - et de favoriser l'auto-organisation chère aux agilistes que nous sommes.

• une équipe Scrum qui souhaite travailler en flux, 

• supprimer les longues réunions de planification de sprint, 

• augmenter la taille d’un équipe Scrum (ex : +12 personnes) 

• gérer des activités qui ne répondent pas à un seul processus défini au sein d'équipes transverse,

•  …

Comment ça marche :

• une réunion de lancement pour un Sprint dans lequel chaque item compte pour 1

• une injection d’éléments à la demande dans la colonne « A faire ». Le backlog sur le tableau devient donc une entée permettant de prioriser dans la colonne « Prêt » les éléments à prendre en priorité (cf pt 1)

• ¼ d’heure tous debout devant le tableau.

• Le Scrum Master/ Manager donne les changements de priorité du jour et les nouveaux éléments sont ajoutés au tableau

• Chacun explique les problèmes rencontrés, fait le point sur son avancement au regard des items, et expose ce qu’il fera dans la journée.

"Scrum c'est super bien, mais entre la réunion de planification du Sprint et les changement incessants de priorités dû à des demandes urgentes de support de la part des projets, on ne peut pas garantir plus de 20% du respect de l'engagement initial...."

ou

"Je voudrais bien que l'on se mette à Kanban pour favoriser l'interaction des équipiers, et gérer nos priorités au jour le jour/à la demande, mais entre les différents domaines d'expertise sur lesquels nous sommes sollicités, il est impossible de définir un processus commun à toute l'équipe, quelque soit la demande."

ScrumBan est un compromis entre Scrum et Kanban. Voici entre autres quelques raisons qui peuvent motiver la mise en œuvre de Scrumban plutot que Scrum, Kanban ou encore XP : 

Je vous propose ci-dessous une vulgarisation des principes de Scrumban pour une mise en oeuvre dans ce type de contexte.

1/ Tableau des tâches :

On se base sur un tableau des tâches Scrum avec les colonnes A faire ->  En cours -> Terminé.

En fait on ajoute une colonne supplémentaire « Prêt » qui permet de prioriser les demandes entre la backlog (A faire) et le travail en cours.

On obtient le tableau suivant : A faire -> Prêt -> En cours -> Terminé

2/  Travailler en flux avec des limites :

Si on ne met pas de limite, on n’obtient pas un système Kanban, et on risque de commencer plein d’activités sans en terminer aucune. On ne travaillera donc pas en flux.

Une bonne limite de départ pour le travail en cours est : nb personnes dans l’équipe * 2.

Cette limite permet de gérer les blocages : je suis bloqué, donc je passe à la tâche suivante en attendant de débloquer la précédente.

3/ Cadence d’injection des éléments

            Dans un système Scrum, on alimente une Backlog avec une liste de choses à faire. Cette Backlog est discutée avec le Product Owner puis estimée en complexité (la « taille » de la Story). La vélocité de l’équipe est un indicateur qui permet de limiter pour un Sprint (« TimeBoxing ») la quantité de travail à réaliser.

            Dans un Système Kanban, la taille n’importe pas. Ce qui compte c’est le nombre d’éléments en cours que l'on limite de manière explicite par un nombre d'éléments (tâches/story) sur chaque colonne du système.

            Avec un Système ScrumBan, une équipe peut choisir le meilleur des deux par rapport à sa problématique :
une réunion de lancement pour un Sprint dans lequel chaque item compte pour 1

ou
une injection d’éléments à la demande dans la colonne « A faire ». Le backlog sur le tableau devient donc une entée permettant de prioriser dans la colonne « Prêt » les éléments à prendre en priorité (cf pt 1)

4/ Cadence de livraison

            Si l’équipe produit une application, le rythme de livraison devra être déterminé en fonction des besoins et des capacités des équipes de déploiement etc…. Si l’on veut, on peut se caler sur la notion de Sprint (itération de durée fixe) pour obliger l’équipe à préparer une version « propre ».
Dans le contexte des équipes de support transverse, il n'y a pas besoin de livrer un produit fini à rythme déterminé, puisque l'on a plutôt une livraison au fil de l'eau à d'autres équipes.

5/ Rétrospectives

            Un point absolument nécessaire et primordial si l’on veut tirer un réel bénéfice de toutes ces méthodes, c’est de faire une rétrospective au minimum une fois par mois avec l’ensemble des équipiers. 
Il est important de rythmer avec une période fixe ces points d’amélioration continue. A l’image du cœur qui rythme nos vies, c’est ce rendez-vous qui permet de s’adapter au contexte de l’organisation et lever les obstacles qui encombrent la route.

• Chacun s’exprime sur ce qui a bien fonctionné, quels problèmes on a rencontré, comment on les a résolus et quels sont les problèmes que nous avons encore.
• Choisir collectivement quelle évolution du système sera mise en oeuvre pour la période suivante
• Choisir les problèmes que le Manager/Scrum Master et l’équipe se chargeront de résoudre pendant la période suivante.

Lors de ces réunions on peut prévoir d’ajouter de nouvelles colonnes au tableau afin coller un peu plus aux spécialités des collaborateurs et au processus de travail.

6/ Animation du tableau

•             Injection des éléments : vu au point 3
•             Mêlées quotidiennes façon Scrum 

Soit :

                       

• ¼ d’heure tous debout devant le tableau.
• Le Scrum Master/ Manager donne les changements de priorité du jour et les nouveaux éléments sont ajoutés au tableau
• Chacun explique les problèmes rencontrés, fait le point sur son avancement au regard des items, et expose ce qu’il fera dans la journée.
• 
  

Bien évidement, à appliquer avec les 4 valeurs, 12 principes du manifeste agile et avec toutes les bonnes pratiques eprouvouées...

Ci-dessous un lien vers un très bon article de Corey Ladas écrit en 2008 qui décrit ScrumBan, traduit par  Fabrice Aimetti : http://www.fabrice-aimetti.fr/dotclear/index.php?post/2011/07/01/Scrumban

Scrum Café 12 : Lego4Scrum

Il y a quelques jours, nous avons joué le fameux atelier de simulation Lego4Scrum décrite sur le site http://www.lego4scrum.com/ et que j'avais joué à un rendez-vous du SUG ( le Scrum Wine Bordelais).


Ce fut une très bonne session, aussi stressante que prévue pour tous les participants.

Auto-organisation

Le Product Owner vient de présenter la liste des choses qui doivent constituer sa ville et 3 équipes de 5 personnes s’auto-organisent afin fabriquer cette ville pour le client.

L’auto-organisation se met en place avec 3 Scrum Masters.

Estimation 

Finalement les fonctionnalités de la ville sont estimées selon une technique d’estimation relative en complexité : Faible, Moyen, Complexe

Valeur métier

Les équipes ont demandé au Product Owner de classer les fonctionnalités par importance en plaçant un « 1 bleu » sur celles que je voulais avoir en premier, puis un 2 sur les autres, et enfin un trois sur celles que je ne voulais pas trop rapidement.

La complexité des fonctionnalités a été reportée à partir de la suite suivante : 

• Faible= 2, 
• Moyen = 5, 
• Complexe =8

Des prototypes ont ensuite été présentés aux équipiers afin de mieux visualiser ce qu’il fallait faire.

Certains ont pensé à demander au Product Owner ce qu’il en pensait : il a tout refusé, mais l’information n’a ni été partagée avec le reste de l’équipe, ni suffisamment comprise par les équipiers.

Les itérations

La première des trois itérations a commencé et les assemblages de briques s’enchainent :
Conception du plan de la ville, premiers bâtiments produits

Rétrospective Sprint 1

« Ou est ma ville ! » crie le Product Owner dans la salle à la recherche de sa ville.
Au bout d’un moment, une timide construction vient se poser sur le terrain nu, quelques fondations décorent le bord de la table.

Un plan de la ville a pu être proposé au Product Owner qui a accepté le plan sous réserve que certaines modifications soient prises en compte

Itération 2

Le terrain est préparé et les premières fonctionnalités voient le jour :

• Le jardin public, 
• Les routes et intersections, 

La fin de l’itération approche : 

Les équipiers préparent le bilan du Sprint : 

• Les fonctionnalités produites sont placées sur le terrain 
• On déplace les post-its initialement prévus dans le Sprint de la colonne « En cours » à la colonne « Fait » 

Rétrospective Sprint 2

Cette fois, le Product Owner n’a pas besoin de demander ou se trouve sa ville :

Les fonctionnalités sont parcourues unes à une et la plus-part sont acceptées par le Product Owner qui réclame tout de même que l’herbe pousse plus vite dans le jardin public….

Sprint 3 : le dernier

La validation des fonctionnalités du Produit est faite au fur et à mesure que les fonctionnalités sont produites (ci –dessus, image en bas à droite avec Benoist et Guillaume qui présentent leur avancement de l’hôpital) : 

• « Plus grand l’hopital » 
• « Plus grand le lieu de culte interconfessionnel » 
• « Plus haut les étages du bâtiment de bureaux »

Les produits sont corrigés et améliorés au fur et à mesure de leur fabrication

Rétrospective finale

Toutes les fonctionnalités sont produites en fin de jeu. La ville et belle et un peu de pelouse a poussé dans le jardin public

Débriefing

Les équipes ont désigné des Scrum Masters pour qu’ils gèrent la relation avec le client, mais ça n’a pas empêché tout le monde de lui poser des questions. Un beau bazar !

La période d’auto-organisation de l’équipe avec l’estimation de la complexité et de la valeur métier a été difficile. Tout le monde posait des questions au PO qui ne savait plus à qui répondre. Stressant !

Les sujets ont été planifiés en 3 Sprints mais sans calculer le ROI. Seule la valeur métier a été utilisée : c’est dommage, l’équipe aurait peut-être pu livrer un peu de valeur au premier Sprint avec l’abri de bus par exemple (très simple à réaliser pour une valeur métier moyenne).

Les informations données par le Product Owner ne sont pas partagées avec le reste des équipes (ex : malgré le refus des maquettes proposées, elles ont été utilisé comme modèle pour le premier Sprint.)

Les équipes ont bien géré leur temps : un chrono a été lancé pour surveiller le temps de production. A la deuxième itération, tout le monde s’est occupé d’organiser la ville sur le terrain avant la fin du temps imparti.

Le jeu a été stressant, comme prévu, pour les joueurs mais aussi pour l’animateur qui devait endosser les rôles distincts d’Animateur, Product Owner et parfois « Super » Scrum Master.


C’était prévu, mais le timing était assez serré. L’organisation des équipes nécessite plus de temps que celui accordé.

Le débriefing final a été un peu écourté également.

Scrum Wine du 25 Septembre 2012

La session a été animée par Fabrice Aimetti et Alexis Monville au Cesi de Blanquefort.

La présentation de Scrum en 5minutes par Alexis était excellente :

• un flot bien maîtrisé,
• aller à l'essentiel 
• laisser le temps pour des questions

J'ai ensuite joué au Légo4Scrum. Nous étions deux équipes de 7 "agilistes" pour réaliser la ville idéale d'Alexis ( maître du jeu et Product Owner).  une très bonne simulation de la mise en oeuvre de Scrum sur un projet qui illustre différentes problématiques : 

• estimation
• priorisation
• compréhension du besoin
• critères d'acceptation
• Scrum de Scrum avec deux équipes
• les itérations (on en a fait 3)
• la rétrospective

et j'en oublie certainement....

Merci aux organisateurs et au Cesi pour l'accueil.

J'ai pris deux photos postées sur Meetup.

Présentation de Scrum en 20 minutes

Les dérives de la mêlée

Les dérives de la mêlée from Olivier Patou

Scrum Café #8 - Penny Game

Pour la 8ème session du Scrum Café nous avions organisé un jeu de simulation :
Le Penny Game, ou comment optimiser la valeur produite.

Le jeu a eu un succès incroyable.

Merci à Philippe Launay, initiateur du Scrum Wine Bordelais pour ce jeu.
https://sites.google.com/site/sugbordeaux/project-updates/scrumwinebordeauxle15mai

Ci dessous l'évolution de l'indice de satisfaction :

Le but est d’effectuer plusieurs fois l’exercice et les mêmes mesures, mais en faisant varier un seul paramètre à chaque fois (taille du lot traité, mise en oeuvre)
Au top départ, les deux client ont lancé la "production" en donnant un lot de 20 pièces au premier ouvrier.
Chaque pièce a été retournée par le premier ouvrier qui a ensuite passé tout le lot au 2eme ouvrier.
Ainsi de suite jusqu'à ce que le dernier ouvrier livre tout le lot au client.
Le client a réceptionné chaque pièce à son tour en la touchant.
Les Experts ont mesuré les temps de travail de chaque ouvrier et le temps de cycle complet : de la commande à la réception client.
A noter : Les ouvriers avaient un handicap imposé : la main droite doit rester dans le dos.

Nous avions deux équipes en parallèle. Voici leurs temps  :

Temps de passage	Itération 1 1 lot de 20 pièces	Itération 2 2 lots de 10 pièces	Itération 3 4 lots de 5 pièces	Itération 4 4 lots de 5 pièces avec les 2 mains	Itération 5 2 lots de 5 pièces avec les 2 mains
Valeur produite	1,85€	1,85€	1,85€	1,85€	1,50€
Ouvrier 1	32s 21,5s	19s 22s	19s 22s	16s 24s	6s 10s
Ouvrier 2	22s 17,6s	22s 17,6s	20s 16,2s	19s 18,5s	8s 7,2s
Ouvrier 3	32s 19,11s	22s 17s	22s 16s	18s 17,3s	9s 9s
Temps travail total	86s 57s	63s 57s	61s 54,2s	53s 59,5s	23s 26,2s
Temps client	95s 71s	49s 46,5s	34s 36s	34s 36s	17s 21,7s
Valeur produite/min	1,17 €/min 1,56 €/min	2,26 €/min 2,38 €/min	3,26 €/min 3,08 €/min	3,26 €/min 3,08 €/min	5,29 €/min 4,14 €/min

Itération 1

• ->Elle sert d'étalon au reste du jeu.
• La concurrence entre les deux équipes s'est installée.
• Notez que la somme des temps individuels différe du temps total mesuré par le patron du client.
• Le client a trouvé le temps long et certains ouvriers ne se sont pas sentis impliqués tout au long de la production.

Itération 2

• ->2 lots de 10 pièces
• Comparez à nouveau les temps client et ouvrier. Ils sont inversés.

Itération 3

• ->4 lot de 5 pièces
• Amélioration des performances individuelles
• Le temps total a été divisé par 2 ou 3 en fonction des équipes

Itération 4

• ->même taille de lot, supprimer les obstacles
• Personne n'a pensé à travailler avec les 2 mains et à supprimer son handicap. L'animateur a dû leur poser la question.
• L'équipe verte a tout changé à la fois (positionnement des ouvriers, technique de travail, positionnement du client, utilisation des 2 mains au lieu de la main gauche seule) : ils ont fait un moins bon temps qu'à l'itération précédente.

Itération 5

• ->Choisir les 10 pièces ayant le plus de valeur; 2 lots de 5 pièces
• Faire moins mais la bonne chose
• Calculer la valeur produite / minute
• Comparer avec les autres itérations

Conclusions?

• Avantages de l’itératif incrémental sur le temps de travail et le temps de livraison
• Rythme de travail perçu par les ouvriers
• L'avantage apporté par l'élimination des obstacles
• La compétition constructive entre équipiers et entre équipes
• L'échange de technique entre équipiers et entre equipes
• S’améliorer soi-même et améliorer l’équipe
• Prendre du recul pour mieux analyser ce qui nous contraint (le bras dans le dos p. ex.)
• La nécessité de livrer plus tôt que prévu
• N’améliorer qu’une chose à la fois pour en mesurer les effets
• Le pilotage du projet par la valeur 

A recommander, et à recommencer

La suite de Fibonacci dans l'estimation des Story

Ken Schwaber (co-fondateur de la méthode Scrum) nous préconise d'utiliser le poker planning basé sur la vraie suite de Fibonacci (http://kenschwaber.wordpress.com/2011/03/11/planning-poker). En lisant cet article publié sur son blog, vous verrez comment la communauté scientifique, en la personne du Dr Stephen Hawking l'a interpellé au sujet de l'anormale simplification qui a été opérée sur les cartes dédiées à l'exercice...

 

Je vous propose ci-dessous la traduction de l'article :

J'ai utilisé la technique d'estimation du Planning Poker de l'extreme Programming depuis que James Grenning me l'a montré en 2003. Beaucoup a été écrit à ce sujet, comment l'utiliser, et comment il conduit rapidement à des estimations d'aussi bonne qualité que toute autre technique plus détaillée et plus longue. J'aime bien quand quelque chose que j'utilise marche. Je l'aime encore plus quand je peux pointer dans la nature ou dans la science les principes fondamentaux sous-jacents expliquant leur fonctionnement. La séquence de chiffres sur lesquel le poker planning est basé provient de l'ensemble de Fibonacci: «Par définition, les deux premiers nombres de Fibonacci sont 0 et 1, et chaque numéro ultérieur est la somme des deux précédents. Certaines sources suppriment le 0 initial, au lieu de commencer la séquence avec deux 1s. En termes mathématiques, la séquence des nombres de Fibonacci Fn est définie par la relation de récurrence Fn = Fn-1 + Fn-2 avec des valeurs semences F0 et F1 = 0 = 1 Wikipedia : Cela nous ramène à des lois naturelles, tels que la taille relative entre les verticilles dans une coquille de nautile, et le nombre d'or provenant de la sommation de l'inverse de l'ensemble: {This ties back to nature, such as the relative size between the whorls in a nautilus shell, and the golden ratio derived from the summation of the inverse of the set:} où {where } Source: http://en.wikipedia.org/wiki/Fibonacci_number Alors, fidèle à la nature, je me sers de ponts entre le poker planning et les numéros 1, 2, 3, 5, 8, 13, 21, 34, 55 ..., en fonction de la taille du backlog de produit. Imaginez ma surprise quand j'ai été appelé en grande détresse par le Dr Stephen Hawking, le physicien théorique. Il était curieux de savoir qui «fricotait » avec la séquence de Fibonacci. Lui et ses compagnons avaient remarqué une recrudescence de phénomènes affligeant ces derniers temps, tels que:    1. La vitesse de la lumière commence à varier de manière imprévisible.    2. La chute d'objets à partir d'arbres à différents vitesses qui étaient indépendants de tous attributs connus.    3. Les Coquilles de Nautilus éclataient spontanément.    4. D'autres perturbations inquiétantes de l'ordre naturel. Ils avaient étudié le problème, et suivis depuis ses origines jusqu'à ce jour, la communauté des développeurs de logiciels agiles. Ils ont constaté que plusieurs d'entre nous avaient perverti la suite de Fibonacci. Ils ont trouvé un certain nombre de jeux de cartes et des affiches qui montrent la séquence suivante: Dr Hawking indiqué un haut degré de probabilité qu'il y ait une corrélation entre la variation anormale de phénomènes naturels et cette perversion de la séquence de Fibonacci. Dr Hawking plaide, et je soutiens, que nous cessions et que nous abstenions de notre utilisation abusive de la séquence de Fibonacci, et que nous revenions à la séquence réelle. Ce sera réaffirmera notre relation avec la nature et notre monde. Best, Ken Schwaber