Estimation et planification Agile

  • 5,257 views
Uploaded on

Présentation sur la planification Agile

Présentation sur la planification Agile

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,257
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
239
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Méthode Agile Session 2 : Introduction à l’estimation et la planification Yannick Quenec’hdu 2010 vendredi 14 mai 2010
  • 2. Imaginer... • Vous en avez marre de faire du développement de logiciel • Et vous dé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 vendredi 14 mai 2010
  • 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 • Je pense que cela fait 80 chargements • Après une heure, j’ai déplacé 20 chargements • Donc, cela fera 4 heures au total vendredi 14 mai 2010
  • 4. Ma petite entreprise vendredi 14 mai 2010
  • 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 vendredi 14 mai 2010
  • 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 vendredi 14 mai 2010
  • 7. Les différents niveaux de plannings Backlog de sprint Backlog de produit Coder l’IHM 8 Comme les voyageurs Écrire test unitaire 5 3 fréquents, je voudrais... Coder la fonction A 3 Comme les voyageurs Écrire test unitaire 5 5 fréquents, je voudrais... Automatiser les tests 6 Comme les voyageurs 5 fréquents, je voudrais... Comme les voyageurs 2 fréquents, je voudrais... Hier : j’ai commencé le dév. de l’IHM. Je pense que j’aurais fini en Comme les voyageurs fréquents, je voudrais... 2 fin de journée vendredi 14 mai 2010
  • 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 vendredi 14 mai 2010
  • 9. Agenda Estimer Planning de release vendredi 14 mai 2010
  • 10. Mesurer la taille • Les méthodes traditionnelles et Agile diffère dans la manière de mesurer la taille Méthodes Méthodes traditionnelles Agile Ligne de code Story Points Point de fonctions Ideal Days vendredi 14 mai 2010
  • 11. Estimer en story points vendredi 14 mai 2010
  • 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 vendredi 14 mai 2010
  • 13. Considérer deux piles de travail Quelles sont les valeurs en story point que l’on pourrait positionner pour ce travail ? vendredi 14 mai 2010
  • 14. Les trois avantages • Estimer en story points : 1. Nous force à 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 vendredi 14 mai 2010
  • 15. Comparons des pommes avec des pommes Backlog de sprint Backlog de produit Coder l’IHM 8 Comme les voyageurs Écrire test unitaire 5 3 fréquents, je voudrais... Coder la fonction A 3 Comme les voyageurs Écrire test unitaire 5 5 fréquents, je voudrais... Automatiser les tests 6 Comme les voyageurs 5 fréquents, je voudrais... Comme les voyageurs 2 fréquents, je voudrais... Hier : j’ai commencé le dév. de l’IHM. Je pense que j’aurais fini en Comme les voyageurs fréquents, je voudrais... 2 fin de journée vendredi 14 mai 2010
  • 16. Estimer la taille - déduire la durée Taille Calcul Durée vélocité 300/20=12 300 kg itérations =20 vendredi 14 mai 2010
  • 17. Estimer en Ideal Days vendredi 14 mai 2010
  • 18. Ideal Time • Combien de temps prendra quelque chose pour être réalisée : • Si vous travailler dessus • Si vous n’êtes pas interrompu • et si tous ce que vous avez besoin est disponible • Le temps idéal pour le football est 90 mn • deux mi-temps de 45 mn vendredi 14 mai 2010
  • 19. Coefficient Ideal Time • L’Ideal Time nécessite un coefficient complémentaire pour le remettre dans le contexte réel • Chaque membre de l’équipe reçoit un coefficient K • La valeur du coefficient est adapté au profil de la personne • Par exemple : • Pour un développeur K=0,25 • Pour une personne dont on possède des données, le coefficient est ajusté K=0,2 • Le résultat est donc Ideal day x K vendredi 14 mai 2010
  • 20. Comparer les deux approches • Les story point sont cross fonctionnelle • Les story points sont une pure mesure de taille • Estimer en story point est plus rapide • Mon ID ne peut être additionner à ton ID • ID est plus facile à expliquer à l’extérieur de l’équipe • ID est plus facile pour les estimation la première fois vendredi 14 mai 2010
  • 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 vendredi 14 mai 2010
  • 22. Planning poker Participants Round 1 Round 2 Aurélien 3 5 Benoit 8 5 Salim 2 5 Germain 5 5 Nicolas 8 8 vendredi 14 mai 2010
  • 23. www.planningpoker.com It’s free ! vendredi 14 mai 2010
  • 24. Estimer cela Éléments du Backlog de produit Estimation Lecture de haut niveau, 10 pages de synthèse sur le développement Agile dans Match Lecture dense, 5 pages de recherche à propos du développement Agile dans Science et vie Écrire le backlog de produit pour votre oncle qui possède une horlogerie et veut maintenant un site d’eCommerce Recruter, interviewer et négocier les prétentions d’un nouveau collaborateur pour votre équipe Créer une présentation de 60 min pour introduire les méthodes de développement Agile pour une équipe qui ne connaît pas Agile Nettoyer et lubrifier la porche de votre patron Lire un ouvrage de 150 pages sur le développement Agile Écrire 8 pages de synthèse sur le futur livre de votre patron vendredi 14 mai 2010
  • 25. Pourquoi le planning poker fonctionne • Ceux qui font le travail réalisent l’estimation 1 • 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. vendredi 14 mai 2010
  • 26. 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? vendredi 14 mai 2010
  • 27. Réduire l’impact des informations incomplètes Groupe A 20 heures 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 - 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. vendredi 14 mai 2010
  • 28. 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 173 heures Accroître la longueur avec les éléments suivants : - Doubler l’espacement entre les lignes - 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. vendredi 14 mai 2010
  • 29. Caractéristiques complémentaires Groupe A 4 heures Donner les exigences R1-R4 Groupe B 4 heures Donner les exigences R1-R5 Groupe C Donner les exigences R1-R5 8 heures ! 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. vendredi 14 mai 2010
  • 30. 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. vendredi 14 mai 2010
  • 31. Agenda Estimer Planning de release vendredi 14 mai 2010
  • 32. 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 vendredi 14 mai 2010
  • 33. Un exemple avec une vélocité = 14 Itération 1 Itération 1 Story A Story A Story F Story L Story C Story K 6 5 5 Story B 8 3 8 Story B Story G 8 Story M 8 1 Story C 5 Story H Itération 2 4 13 Story C Story D Story I Story E 3 Story F 4 5 Story D 1 Story E Story J 5 5 16 8 vendredi 14 mai 2010
  • 34. 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 vendredi 14 mai 2010
  • 35. 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) vendredi 14 mai 2010
  • 36. 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 » vendredi 14 mai 2010
  • 37. Planning à date fixe : exemple Date de 30 juin Nous aurons release désirée Date 1 janvier 6 x 15 d’aujourd’hui Peut-être 6 x 20 Vélocité basse 15 Nous n’aurons pas Vélocité haute 20 vendredi 14 mai 2010
  • 38. Date fixe contractualisée 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 avec «Peut-être» : 6 x 20 • 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 ? vendredi 14 mai 2010
  • 39. Merci de votre attention vendredi 14 mai 2010