Dans le développement logiciel, l’estimation des temps de réalisation est une science inexacte et est une des sources de dépassement des dates de livraison des jalons d’un projet. Découvrer comment avec une méthode conviviale, le planning poker, vous pouvez associer clients et développeurs pour estimer au plus juste.

1. Planning Poker
Youen Chéné
Rouen - 13 octobre 2011
13 octobre 2011

2. Partenaires Gold
Partenaires logistique
13 octobre 2011

3. Votre Intervenant
Architecte SI chez Masternaut
Mise en place tactique de pratiques agiles depuis 2010
Fondateur de Driveo.Fr, le logiciel en ligne de gestion
d'auto école
Normandy Jug Leader : 1 session liée à Java le 3ème mardi
de chaque mois au CESI. http://www.normandyjug.org
http://www.youenchene.fr
http://twitter.com/youen_chene
youen.chene@gadz.org
13 octobre 2011

4. Les origines du planning poker
Inventée en 2002 par James Grenning
( http://renaissancesoftware.net/papers/44-planing-poker.html )
Objectif
Obtenir une estimation fiable par une
approche mélangeant divertissement et
participation de toutes l'équipe de
développement et les avis des experts.
13 octobre 2011

5. L'estimation d'un projet classique
Développeur qui passait par là
Estim. Développeur pas frais x Pi
=
Charge Etape Projet
Feuille Excel
Chef de projet qui doit rendre son chiffrage dans 1h
13 octobre 2011

6. L'estimation d'un projet classique
Mais aussi :
Les abaques
(mais pas adapté au contexte courant)
La fiche excel magique
(avec plein d'équations dedans)
L'avis de l'expert
(que personne de remet en cause)
L'estimation commerciale
(qu'il faut tenir à tout prix)
13 octobre 2011

7. Estimer dans un projet agile
Dans un projet agile, c'est d'autant plus diffcile
sachant qu'il faut estimer souvent et sur un
périmètre qui évolue
Nous avons besoin d'une manière rapide,
simple et fiable d'estimer les stories affectés à
chaque sprint.
13 octobre 2011

8. La solution : jouons au cartes !
13 octobre 2011

9. Les bases : vélocité
Les projets agiles sont basés sur une vélocité
propre à l'équipe de développement.
13 octobre 2011

10. Les bases : estimation avec des scores
On ne chiffre pas avec des heures ou des jours
hommes.
13 octobre 2011

11. Les bases : estimation avec des scores
On étalonne le chiffrage sur une tâche que
l'équipe sait faire de manière reproductible.
Exemple : faire un écran d'édition simple des données d'une
personne.
Cette tâche correspond à un score de 5 points
13 octobre 2011

12. Les bases : estimation avec des scores
Toutes les estimations seront faites relativement
à cette tâche référente.
13 octobre 2011

13. Les bases : rapport avec la vélocité
La vélocité d'un équipe étant le nombre points
réalisé en un sprint.
La vélocité évolue de sprint en sprint.
Il sera possible alors d'estimer le nombre de
user story affectable à un sprint.
13 octobre 2011

14. Les règles du jeu
Le product owner / la MOA participent mais
n'estiment pas!
Chaque participant/estimateur a le jeu de
carte suivant : 0, ½, 1, 2, 3, 5, 8, 13, 20,
40, and 100
Une carte « coffee »/ « Joker » est aussi
disponible
13 octobre 2011

15. Les règles du jeu
Le PMO/Scrum Master est l'animateur.
Pour chaque user story, l'animateur lit la
description.
Le product owner répond au question des
estimateurs.
Chaque estimateur choisit une carte sans la
montrer aux autres.
13 octobre 2011

16. Les règles du jeu
Les participants montrent leur carte au même
moment.
Des estimations très différentes : bonne
nouvelle!
Les auteurs des estimations hautes et faibles
s'expliquent.
Refaire autant de tours que nécessaire
jusqu'au consensus.
13 octobre 2011

17. Les règles du jeu
Vous avez estimés votre user story!
Vous pouvez maintenant affecter les user story
aux sprints en fonction de votre vélocité.
13 octobre 2011

18. Les règles du jeu : Résumé
1. Le modérateur lit la Story
2. L'équipe pose les questions au product
owner
5. Débats
3. Choix d'une carte
Pas de consensus
Consensus
4. Révélation des cartes
13 octobre 2011

19. Jouons ensemble !
Le projet : application iphone de planning poker
User Story 1 : Se connecter à une user story
User Story 2 : Choisir une estimation
User Story 3 : Révéler les estimations de chacun
User Story 4 : Refaire un tour
Les rôles :
1 Animateur, 1 Product Owner
13 octobre 2011

20. Pourquoi ca marche
Cela mélange les sources d'estimation
“La sagesse des foules”
Prends en compte les avis des timides, des juniors, des séniors.
Lisse les avis des experts et des fortes personnalités.
Chaque membre de l'équipe s'est engagé
C'est dynamique et amusant
Alors que d'habitude les développeurs rechignent à participer au
chiffrage d'un projet
13 octobre 2011

21. Quelques conseils
Préparez votre Planning Poker
Bien préparé = 1 à 2h, mal préparé = 1 jour
Ne jamais revenir à la notion de temps
Pas de jour homme.... Non vraiment pas.
(Oui, c'est difficile pour les fans de GANTT et les SSII)
Toujours bien avoir en mémoire la tâche de
référence
13 octobre 2011

22. Retours d'expérience
Une bonne prise de la température de l'équipe
Il met en avant les différences et les tensions entre les membres de
l'équipe.
L'objectif du planning poker n'est pas de bien
estimer, mais de permettre à l'équipe de
s'engager sur un périmètre atteignable.
13 octobre 2011

23. Planning Poker
Estimer votre projet agile
Merci !