Téléchargé 14 fois
Téléchargé parFabrice Aimetti
Une introduction à l'estimation et la planification agile
Ce document traite de l'estimation et de la planification agile, présentant des méthodes pour estimer la taille et la durée des tâches à l'aide de points d'histoire et de journées idéales. Il aborde également des techniques telles que le planning poker et la planification des releases en tenant compte des dépendances entre équipes. L'accent est mis sur l'importance d'établir des unités communes pour faciliter la comparaison et la collaboration entre les équipes.
Contenu connexe
Similaire à Une introduction à l'estimation et la planification agile
Une introduction à l'estimation et la planification agile
- 1. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Mike Cohn 12 Mars 2008 Une Introduction à l’Estimation et à la Planification Agile © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Mike Cohn – présentation Coach etformateur Agile• Membre fondateur et directeur de l’Agile Alliance et de la Scrum Alliance • Fondateur de Mountain Goat Software• Premier projet Scrum en 1995 • Manager développeur, …
- 2. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Les bonnes unités pour estimer Comment estimer Le planning de Release Planifier avec plusieurs équipes Agenda © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Combien de temps cela prendra-t-il… • …pour lire le dernier Harry Potter ? • …pour aller en voiture jusqu’à Paris ?
- 3. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Estimer la taille; en déduire la durée © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Mesurer la taille Agile •Story points •Ideal days Séquentiel •Lignes de code •Points de Fonction
- 4. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Ideal days • Combien de temps cela prendrait-il si : • c’est vous qui faite tout le travail ? • vous n’êtes pas interrompu ? • et tout ce dont vous avez besoin est disponible ? • L’Ideal time d’une partie de basket-ball est de 40 minutes • 4 périodes de 10 minutes • Le temps réel d’exécution est beaucoup plus long (≥ 2 heures) © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Story points • La “grosseur” d’une tâche • Ses dépendances • Sa difficulté • Ses occurrences • Ce que importe ce sont des valeurs relatives : • Un écran de connexion vaut 2. • Une fonction de recherche vaut 8. • Les Points sont sans unité En tant qu'utilisateur, je veux être en mesure d'avoir certains articles, mais pas tous, dans mon paquet cadeau emballé.
- 5. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Zoo points Quelle valeur en “zoo points” affecteriez- vous à ces animaux du zoo ? Lion Kangourou Rhinocéros Ours Girafe Gorille Hippopotame Tigre © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Comparer les approches • Les Story points permettent d’adopter une approche fonctionnelle transverse • Les Story points permettent d’estimer sans dégrader • Les Story points sont une pure mesure de taille • Estimer en story points est beaucoup plus rapide • Mes Ideal days ne peuvent être ajoutés à vos Ideal days • Les Ideal days sont plus faciles à expliquer en dehors de l’équipe • Les Ideal days sont plus faciles à estimer au début • Les Ideal days peuvent forcer les entreprises à découvrir les activités où l’on perd du temps
- 6. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Le problème avec des unités mélangées En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … En tant que voyageur régulier, je veux … 33 22 66 44 22 3030 2020 6060 4040 2020 Coder le…Coder le… Concevoir le…Concevoir le… Automatiser …Automatiser … Tester le…Tester le… 1212 1010 55 88 © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Les bonnes unités pour estimer Comment estimer Le planning de Release Planifier avec plusieurs équipes Agenda
- 7. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Estimer par analogie • Comparer une user story aux autres • “Cette story est pareil que celle-là, donc son estimation vaut la même chose.” • N’utilisez pas une seule règle d’or • Au contraire, essayez de trianguler • Comparer la story à estimer à plusieurs autres stories © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Utilisez les bonnes unités • Pouvez-vous distinguer une story à 1 point d’une story à 2 points ? • Et une story à 17 d’une autre à 18 ? • Utilisez un ensemble de nombres qui conserve un sens ; J’aime : • 1, 2, 3, 5, 8, 13 • Rester le plus souvent dans une fourchette de 1 à 10 • Cela reste conforme à la Nature : • Les sons musicaux et le volume sont distingués sur une échelle logarithmique Utilisez 0 and ½ si vous voulez
- 8. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Planning poker • Une approche itérative pour estimer • Etapes : • Chaque estimateur dispose d’un paquet de cartes, chaque carte porte une estimation valide • Le Client/Product Owner lit une story et elle est brièvement discutée • Chaque estimateur sélectionne une carte qui est son estimation • Les cartes sont retournées afin que tous puissent les voir • Discutez des différences (en particulier les valeurs aberrantes) • Réestimez jusqu’à ce que les estimations convergent © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Planning poker – un exemple EricEric MartineMartine IngridIngrid ThierryThierry 33 88 22 55 EstimateurEstimateur 1er tour1er tour 55 55 55 88 2ème tour2ème tour
- 9. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Estimez ceci : Items du Backlog Produit Estimation Lire un article de présentation générale haut-niveau sur le développement logiciel en mode agile dans un magazine de célébrités. Lire un article de recherche de 5 pages denses sur le déloppement logiciel en mode agile dans un journal universitaire. Ecrire le backlog produit d’une site eCommerce simple qui vend uniquement des horloges. Trouver, faire l’entretien et embaucher un nouveau membre pour votre équipe. Créer une présentation de 60 minutes sur l’estimation et la planification agile pour vos collègues. Laver et polir la Porsche de votre patron. Lire un bouquin de 150 pages sur le développement logiciel en mode agile. Ecrire une description de 8 pages sur le développement agile pour votre patron. © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® www.planningpoker.com Gratuit, sinon je n’en aurai pas parler Gratuit, sinon je n’en aurai pas parler
- 10. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Les bonnes unités pour estimer Comment estimer Le planning de Release Planifier avec plusieurs équipes Agenda © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® La planning de Release Réunion de planning de Release Réunion de planning de Release Planning de ReleasePlanning de Release Sprint 1 Sprint 2 Sprint 3 Sprints 4−7
- 11. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Sprint 3−4Sprint 3−4 Un exemple avec une vélocité de 14 Sprint 1Sprint 1 Sprint 2Sprint 2 Story A 5 Story B 8 Story E 1 Story A 5 Story B 8 Story E 1 Story C 3 Story D 5 Story F 3 Story G 3 Story H 13 Story I 5 Story J 8 Story C 3 Story D 5 Story F 3 Story G 3 Story H 13 Story I 5 Story J 8 © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Projections basées sur la vélocité 40 30 20 10 0 21 3 4 5 6 7 8 9 Moyenne (3 meilleurs) = 37 Moyenne (8 derniers) = 33 Moyenne (3 pires ) = 28
- 12. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Extrapolez à partir de la vélocité Avec notre vélocité la plus faible, nous terminerons ici (5 × 28) Avec notre vélocité moyenne, nous terminerons ici (5 × 33) Avec notre meilleure vélocité, nous terminerons ici (5 × 37) Supposons qu’il reste 5 sprints © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Planning à date fixe • Déterminez combien de sprints vous avez • Estimez la vélocité comme une fourchette • Multipliez la vélocité basse × nombre de sprints • Comptez le nombre de points ; il s’agit des items que vous “aurez” • Multipliez la vélocité haute × nombre de sprints • Comptez le nombre de points ; il s’agit des items que vous “pourrez peut-être avoir” Combien puis-je obtenir par <date> ?
- 13. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Exemple de planning à date fixe Date de release souhaitée Date de release souhaitée Aujourd’huiAujourd’hui Nombre de sprints Nombre de sprints Vélocité basse Vélocité basse Vélocité haute Vélocité haute 30 Juin 1er janvier 6 (mensuel) 15 20 “Vous aurez” “Vous pourrez peut-être avoir” “Vous n’aurez pas” 6 × 15 6 × 20 © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Les bonnes unités pour estimer Comment estimer Le planning de Release Planifier avec plusieurs équipes Agenda
- 14. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Trois problématiques Estimer dans une unité communeEstimer dans une unité commune Planning du sprintPlanning du sprint DépendancesDépendances © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Etablir une base commune • Toutes les équipes doivent être d’accord pour utiliser les story points ou les ideal days • Etablissez une base commune : • Sélectionnez une douzaine de user stories qui ont été réalisées récemment ou qui sont dans le backlog produit • Estimez les en gros avec le Planning Poker
- 15. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Soyez prudent en comparant des équipes croisées • Quand cette entreprise a-t-elle commencé à comparer les vélocités? • Quand l’équipe jaune a- t-elle découvert qu’elle était comparée ? © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Deux approches pour planifier un sprint Décaler d’un jourDécaler d’un jour • Les sprints se terminent à ± 1 jour • Permet à une ressource clé (ex: un product owner ou un architecte) de participer à de nombreuses réunions de planning
- 16. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® La Grande Salle • Tous les sprints se terminent le même jour • Tout est planifié le même jour dans la même salle • Les ressources clés changent d’équipe sur demande La Grande Salle • Tous les sprints se terminent le même jour • Tout est planifié le même jour dans la même salle • Les ressources clés changent d’équipe sur demande © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Dépendances • Dépendances critiques entre les équipes : • Impose un ordre d’exécition et a probablement une influence sur la date finale de livraison • Beaucoup moins que vous ne pensez • Nouvelles dépendances : • “OK, nous allons commencer par telle et telle chose. Comme vous le savez, nous avons besoin de ceci et cela en premier.”
- 17. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Détecter les dépendances critiques Sprint 1Sprint 1 Sprint 2Sprint 2 Sprint 3Sprint 3 Sprint 1Sprint 1 Sprint 2Sprint 2 Sprint 3Sprint 3 20 points 10 points 20 points 17 points 17 points17 points © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Dérouler le planning en avance Sprint1 TâcheTâche HeuresHeures 88Coder le …Coder le … Tester le …Tester le … 1616 Intégrer avec …Intégrer avec … 55 Coder le …Coder le … 88 Concevoir le …Concevoir le … 44 Sprint 2 Sprint 3
- 18. © 2003−2007 MountainGoat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Après le Sprint 1Après le Sprint 1 Sprint 1 Sprint 2 Sprint 3 Sprints 4−7 Codage… 8 Test… 4 Conception 4 Codage… 5 Après le Sprint 2Après le Sprint 2 Sprint 2 Sprint 3 Sprint 4 Sprints 5−7 Codage… 3 Test… 7 Test… 6 Codage… 8 • Pendant la planification du Sprint 2, une équipe déroule le Sprint 4. • Ils découvrent une dépendance avec une autre équipe. • L’autre équipe travaille sur cet item dans le Sprint 3. © 2003−2007 Mountain Goat Software Traduit par Fabrice Aimetti le 30/05/2009 ® ® Pour contacter Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com (720) 890-6110