Présentation sur la planification Agile

1. ESTIMATION ET
PLANIFICATION AGILE
Yannick Quenec’hdu

2. IMAGINER...
• Vousen avez marre de faire du
développement de logiciel
• Vousdécidez de lancer une
entreprise d’aménagement de
paysage
• Votre
premier projet est de bouger
un amas de rocher de devant une
maison vers l’arrière

3. COMMENT ESTIMER CE TRAVAIL ?
• Une solution :
• Regarder l’amas de gravier et estimer les charges en
nombre de brouettes que cela représente
• Après une heure, regarder le nombre de brouettes que
vous avez déplacé et ensuite extrapoler la durée totale
• Je pense que cela fait 80 chargements
• Après une heure, j’ai déplacé 20 chargements
• Donc, cela fera 4 heures au total

4. MA PETITE ENTREPRISE

5. • Une itération est une période courte
• Habituellement de 1 à 4 semaines
la vélocité est la
somme des travaux
prévus ou terminés
dans une itération
Une Release comprend généralement plus d’une
itération

6. LE PLANNING OIGNON
• L’équipe Agile utilise les
trois niveaux les plus
profonds
• D’autres équipes de
l’entreprise planifient avec
des niveaux supérieurs

7. LES DIFFÉRENTS NIVEAUX DE PLANIFICATION
Backlog de sprint
Backlog de produit
Coder l’IHM 8
Comme les voyageurs fréquents, Écrire test unitaire 5
3
je voudrais...
Coder la fonction A 3
Comme les voyageurs fréquents, Écrire test unitaire 5
5
je voudrais...
Automatiser les tests 6
Comme les voyageurs fréquents,
5
je voudrais...
Comme les voyageurs fréquents,
2
je voudrais... Hier : j’ai commencé le dév. de
l’IHM. Je pense que j’aurais fini en
Comme les voyageurs fréquents,
2 fin de journée
je voudrais...

8. PLANNING DE PRODUIT, RELEASE, ITÉRATION
Release 1 Release 2 Release 3
Plan de release
Itération 1 Itération 2 Itération 3 Itération 4 - 7
Tache A 8 heures
Tache B 16 heures
Tache C 10 heures

9. AGENDA
Estimer
Planning de release

10. MESURER LA TAILLE
• Lesméthodes traditionnelles et Agile diffèrent dans
la manière de mesurer la taille
Méthodes Méthodes
traditionnelles Agile
Ligne de code Story Points
Point de fonctions Ideal Days

11. ESTIMER EN STORY

12. STORY POINTS
• Probablement le plus utilisé pour estimer l’activité entre les
équipes Agiles
• Le nom est dérivé de l’expression couramment utilisée par les
équipes Agile : user story
• Basé sur ce qui influe sur les efforts pour développer une
fonctionnalité
• Estimation sans unité, mais numériquement pertinente

13. CONSIDÉRER DEUX PILES DE TRAVAIL
Quelles sont les valeurs en story
point que l’on pourrait
positionner pour ce travail ?

14. LES TROIS AVANTAGES
1. oblige à estimer de manière relative
• Des études ont montré une meilleure estimation
2. Se concentrer sur l’estimation de la taille et non de la durée
• Nous dérivons la durée empiriquement par complétion de
l’itération
3. L’estimation est réalisée avec des unités que l’on peut
additionner
• Les estimations en fonction du temps ne sont pas additives

15. COMPARONS DES POMMES AVEC DES
POMMES
Backlog de sprint
Backlog de produit
Coder l’IHM 8
Comme les voyageurs fréquents, Écrire test unitaire 5
3
je voudrais...
Coder la fonction A 3
Comme les voyageurs fréquents, Écrire test unitaire 5
5
je voudrais...
Automatiser les tests 6
Comme les voyageurs fréquents,
5
je voudrais...
Comme les voyageurs fréquents,
2
je voudrais... Hier : j’ai commencé le dév. de
l’IHM. Je pense que j’aurais fini en
Comme les voyageurs fréquents,
2 fin de journée
je voudrais...

16. ESTIMER LA TAILLE - DÉDUIRE LA DURÉE
Taille Calcul Durée
vélocité 300/20=15
300 kg itérations
=20

17. ESTIMER EN IDEAL DAYS

18. IDEAL TIME
• Combien de temps prendra quelque chose pour être réalisé :
• Si vous travaillez dessus
• Si vous n’êtes pas interrompu
• et si tout ce dont vous avez besoin est disponible
• Le temps idéal pour le football est 90 mn
• deux mi-temps de 45 mn

19. COEFFICIENT IDEAL TIME
• L’Ideal Time nécessite un coefficient complémentaire pour le
remettre dans le contexte réel et prendre en compte les tâches
externes au projet
• L’équipe selon sa fonction reçoit un coefficient K
• La valeur du coefficient est adaptée tout au long du projet
• Par exemple :
• Pour une équipe de développeur K=0,25
• Le résultat est donc Ideal day x K

20. COMPARER LES DEUX
APPROCHES
• Les story point sont multifonctionnels
• Les story points sont une pure mesure de taille
• Estimer en story point est plus rapide
• Mon ID ne peut être additionné à ton ID
• ID est plus facile à expliquer à l’extérieur de l’équipe
• ID est plus facile pour les estimations la première fois

21. PLANNING POKER
• Une approche itérative pour estimer
• Étapes :
• Chaque personne reçoit un jeu de cartes, chaque carte contient une
estimation
• Le client ou le PO décrit l’histoire et discute brièvement à son sujet
• Chaque personne sélectionne une carte pour donner son estimation
• Chaque personne affiche sa carte en même temps
• On discute des différences (spécifiquement les deux extrêmes)
• On re-estime si nécessaire

22. PLANNING POKER
Round Round
Participants
1 2
Laura 3 5
Marouene 8 5
Johann 2 5
Thomas 5 5
Marc 8 8

23. WWW.PLANNINGPOKER.COM
It’s free !

24. POURQUOI LE PLANNING POKER
FONCTIONNE
• Ceux qui font le travail réalisent l’estimation1
• Les estimateurs sont tenus de justifier leur
estimation2,3
• L’estimation se concentre sur un ordre de grandeur
approximatif4,5
1Jørgensen, Magne. 2004. A Review of Studies on Expert Estimation of Software Development Effort.
2Hagafors, R., and B. Brehmer. 1983. Does Having to Justify One’s Decisions Change the Nature of the Decision Process?
3Brenner, et al. 1996. On the Evaluation of One-sided Evidence.
4Miranda, Eduardo. 2001. Improving Subjective Estimates Using Paired Comparisons.
5Saaty,Thomas. 1996. Multicriteria Decision Making:The Analytic Hierarchy Process.

25. POURQUOI LE PLANNING POKER
FONCTIONNE
• Combiner des estimations individuelles au travers d’un groupe
de discussion mène à de meilleures évaluations
• Accentuer sur une estimation relative plutôt que sur une
estimation absolue
• Les évaluations sont contraintes à un jeu de valeur donc nous
ne gaspillons pas de temps dans des arguments vides de sens
• On écoute l’avis de chacun
• C’est rapide et marrant
6Hoest, Martin, and Claes Wohlin. 1998. An Experimental Study of Individual Subjective Effort Estimations and Combinations of the
Estimates.
7Jørgensen, Magne, and Kjetil Moløkken. 2002. Combination of Software Development Effort Prediction Intervals:Why,When and How?

26. RÉDUIRE L’IMPACT DES INFORMATIONS
INCOMPLÈTES
Groupe A
20 heures
2
Donner les spécifications du projet
Groupe B
Donner les spécifications du projet
Avec les détails suivants :
- Le type de système d’exploitation utilisé par l’utilisateur 39 heures
2
- Le type d’authentification par certificat numérique
- les besoins de performance
- Etc.
Source: How to avoid impact from irrelevant and misleading information
on your cost estimates,
Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,
Simula Research Labs Estimation Seminar, Oslo, Norway 2006.

27. LONGUEUR DES
SPÉCIFICATIONS
Groupe A
117 heures
Donner les spécifications du projet
Groupe B
Donner les mêmes spécifications du projet, mais
avec 7 pages en plus
Accroître la longueur avec les éléments suivants :
- Doubler l’espacement entre les lignes
173 heures
- Agrandir la marge
- Augmenter la taille des polices
- Ajouter plus d’espace entre les paragraphes
Source: How to avoid impact from irrelevant and misleading information on your cost estimates,
Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,
Simula Research Labs Estimation Seminar, Oslo, Norway 2006.

28. CARACTÉRISTIQUES
Groupe A
4 heures
2
Donner les exigences R1-R4
Groupe B
Donner les exigences R1-R5
4 heures
2
Groupe C
Donner les exigences R1-R5 8 heures !
2
Mais ne demander que les estimations de R1 à R4
Source: How to avoid impact from irrelevant and misleading information on your cost estimates,
Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,
Simula Research Labs Estimation Seminar, Oslo, Norway 2006.

29. RÉDUIRE LES PROBABILITÉS
Groupe A
Donner les spécifications du produit
456 heures
Groupe B
• Donner les mêmes spécifications
• Indiquer que le client pense que 500 heures est une estimation 555 heures
raisonnable, mais que :
• Le client n’est pas sur
• Vous ne devez pas vous laisser influencer par le chiffre du client
Groupe C
Donner les spécifications du produit, indiquer que le client 99 heures
l’estime à 50 heures
Source: How to avoid impact from irrelevant and misleading information on your cost estimates,
Magne Jørgensen and Stein Grimstad, Simula Research Laboratory,
Simula Research Labs Estimation Seminar, Oslo, Norway 2006.

30. AGENDA
Estimer
Planning de release

31. PLANNING DE RELEASE
Objectif
De ce poser des questions telles que :
• Qu'est-ce qui sera terminé pour le 30 juin ?
• Quand peut-on livrer avec cet ensemble de caractéristiques
• Combien de personnes seront sur ce projet ?
Entrée
• Vélocité
• Longueur du projet
• Backlog de produit avec les priorités

32. UN EXEMPLE AVEC UNE VÉLOCITÉ
Itération 1 Itération 1
Story A Story A Story F
Story L
5 Story C Story K
6 5
Story B 8
3 8 Story B Story G
8 Story M
8 1
5
Story C Story H
Itération 2 4 13
Story C Story D Story I
Story E
3 4 5
Story F
Story D 1 Story E Story J
5
5 16 8

33. MISE À JOUR PLAN DE RELEASE
Moyen (Meilleur 3) = 37
40
Moyen (Meilleur 3) = 37
Moyen (dernier 8) = 33
30 Moyen (pire 3) = 28
20
10
0
1 2 3 4 5 6 7 8 9
Itération

34. EXTRAPOLER DEPUIS LA VÉLOCITÉ
Avec notre vélocité la plus lente, nous finirons ici (5x28)
Avec notre moyenne à long terme nous finirons ici (5x33)
Avec notre meilleure vélocité, nous finirons ici (5x37)

35. PLANNING À DATE FIXE
1. Déterminer combien d’itération vous avez
2. Estimer la vélocité comme une portée
3. Multiplier la vélocité la plus lente x le nombre d’itération
• Compter le nombre de points
• C’est le nombre d'éléments « Que vous avez »
4. Multiplier la vélocité la plus élevée x le nombre d’itération
• Compter le maximum de points
• C’est le nombre d'éléments « Que vous pourriez avoir »

36. PLANNING À DATE FIXE :
Date de
release 30 juin
Nous aurons
désirée
Date
1 janvier 6 x 15
d’aujourd’hui Peut-être
Vélocité 6 x 20
15
basse Nous n’aurons pas
Vélocité
20
haute

37. DATE FIXE
Si vous écrivez, un contrat
avec «Nous aurons» :
Nous aurons • Vous avez peu de chance de remporter le contrat
• Vous allez sûrement faire de l’argent avec ce projet
6 x 15
Peut-être Si vous écrivez un contrat
6 x 20 avec «Peut-être» :
• Vous avez de grandes chances de remporter le
Nous n’aurons pas contrat
• Vous ne ferez sûrement pas de l’argent avec ce projet
C'est une question de risques
Ou voulez-vous vous positionner ?

38. QUESTION ?