Gestion de projets agiles avec SCRUM - 2ème Partie PDF

Gestion de projets agiles 2ème Partie avec SCRUM Thierry Condamines On se lance ?  Sommaire 2 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revu...

Gestion de projets agiles 2ème Partie avec SCRUM Thierry Condamines On se lance ?  Sommaire 2 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revue de Sprint 5. La rétrospective  1. Découvrir le produit 3 « Si Scrum aide à BIEN faire le produit, ces pratiques contribuent à faire le BON produit » Claude Aubry  De l’idée aux « Features » : impact mapping 4 Carte Heuristique : Objectif au centre Les acteurs au premier niveau Les impacts attendus au 2nd niveau Les solutions à ces impacts (Features) au 3ème niveau Ateliers : PO, SM, personnes métier, marketing, produit, … Au tout début et au début de chaque nouvelle release  Sommaire 5 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revue de Sprint 5. La rétrospective 2. Le Product Backlog 6  Sprint 0 : début du Backlog 7 Backlog = liste ordonnée des choses à faire par l’équipe Visible de toute le monde (favorise le feedback) Vivant, il évolue continuellement MAIS : pendant un sprint, la partie du backlog sur laquelle on travaille n’est pas modifiable !  De la Feature à la Story 8 Story : description simple et compréhensible d’une fonctionnalité qui aura de la valeur aux yeux d’un utilisateur ou d’une partie prenante du produit et développable en 1 sprint Epic Story Condition Story Feature Epicentrer Trop grosse pour Storydans unStory d’acceptation sprint (ne peut acceptée passer au statut de prête) Souvent mal connue, elle doit être décomposée ou étudiée (affinage) Une fois décomposée elle disparait Thème / Feature = regroupement thématique de Stories Correspond à un service ou une fonction du produit dont l’énoncé est clair pour les parties prenantes Peut être non finie à la fin d’un sprint mais finie à la fin d’une release  De la Feature à la Story 9 Identifier des stories avec le story mapping (Jeff Patton) Une story map permet de visualiser des scénarii d’usage et de préparer l’enchaînement des stories. Priorité = maximiser l’impact/valeur, minimiser l’effort De la Feature à la Story : tableau de features 10 Opportunité  Cycle de vie de la Story 11 Règles des 3C (Ron Jeffries) … ou plutôt les 5C 1. CARTE : Une idée de Story ? On la note sur une carte de petite taille (Post-it). 2. CONVERSATION : Le Product Owner et l’équipe affinent cette story afin qu’elle puisse être réalisée en un Sprint, au cours d’une conversation. 3. CONFIRMATION : L’équipe apporte sa confirmation qu’elle est prête. 4. CONVERSATION : L’équipe réalise la story pendant un Sprint, en tenant une nouvelle conversation avec le PO sur son acceptation. 5. CONFIRMATION : Le PO apporte sa confirmation qu’elle est finie. Des test de validation sont décrits avec la Story (Ils serviront à valider qu’elle a été réalisée correctement). Idée Prêt Affinage Réalisation Finie e  Comment rédiger une Story ? 12 Sur un POST-IT : Titre Recto : En tant que , je peux afin de Infos additionnelles : chiffrage, priorité, … Verso : Condition(s) d’acceptation (on peut utiliser le Behaviour Driven Developpment) Etant donné Quand Alors  Backlog 13 Bac à sable : pour les idées Antichambre du backlog Court séjour : le temps pour le PO de comprendre la proposition et la traîter Ni ordonné ni estimé Bac d’affinage Lieu où l’équipe affine les stories de la release courante avant de les réaliser dans un sprint Taille proportionnelle à la priorité Définit le périmètre de la release : vide à la fin Bac de départ : pour les stories prêtes Le nombre d’éléments ne devrait pas dépasser l’équivalent d’un peu plus d’un sprint La story n’évolue pas ou peu  Backlog 14 Bac d’arrivée : pour les stories finies Se remplit au fil des sprints Ranger les stories par sprint et les conserver jusqu’à la fin de release Permet aux parties prenantes de visualiser les résultats des travaux de l’équipe historique de la release  Affiner le Backlog 15 Objectif : avoir suffisamment de stories prêtes pour le prochain Sprint Une Story est prête si elle est 6D : Décomposée (plus épique) Débattue (discutée en équipe au cours des séances d’affinage) Dérisquée (les risques sont réduits) Possède une Définition de fini (condition de fin) Démontrable (on pourra la montrer lors de la revue/démo) Désirable (Apporte une valeur à quelqu’un) Qui : principalement le Product Owner + conversations avec l’équipe Quand : régulièrement (1h30 à 2h par semaine pour l’équipe – 5%)  Affiner le Backlog : méthodologie 16 1. Regarder le bac de départ. Si pas assez de stories l’approvisionner en stories prêtes Si on traite en moyenne n stories par sprint, il faut entre 1,2n et 1,5n stories prêtes OPTIONNEL 2.Evite Observer au PO de le bac d’affinage devoir pour identifier les stories Stories épiques qu’ilpas qui n’ont faut purger plusieurs fois(alimenteront décomposer les le prochain sprint) d’intérêt à court terme, mêmes choses (demandes gelées jusqu’à la release 3. qui Examiner le bac à sable et reviendraient) le tableau de Features pour approvisionner suivante en stories à affiner 4. Estimer les éléments approvisionnés ou décomposés que contient le bac d’affinage (planning poker) 5. Réordonner le bac d’affinage (priorités : valeur + taille + dépendances) 6. Purger les bacs  Estimer une Story 17 Exemple de vélocité Phase 1 : Connaître la durée d’un sprint : 2 semaines = 10 jours Plusieurs Phase 2 :méthodes les ressources disponibles : Classique 5 personnes : le disponibles jours x homme (jh)8j, 6j, 10j soit un total de 44 jh 10j , 10j, Phase 3 : calcul Le Story Pointdu: combinaison coefficient de focalisation de effort, complexité et risque/inconnu. degré Equipe nouvelle ? Commencer de concentration avec un ilcoeff deavec focalisation de de 70 % Technique basée surdel’expérience l’équipe : plus est faible (analogie plus des l’équipe Stories s’attend à être perturbée ou considère (Henrik ses estimations optimistes Kniberg) référence). Coef de focalisation = Vélocité réelle / nb de jh disponibles Ex Chaque : si danséquipe le sprinta précédent son échelleon avalable traité 35que pour story elle points avec 48 jh Pointsledecoef de focalisation vélocité = somme est de des72story % points des Stories terminées Phase 4 : calcul de la vélocité estimée pour le sprint suivant Si une équipe, à la suite d’un sprint, a une vélocité de 12, elle ne Nb de jh disponibles x coef de focalisation s’engagera dans le sprint suivant que sur des stories correspondant à Ici : 44 x 0,72 = 31 points un capital de 12 Dans le sprint suivant ne surtout pas dépasser ces points !!!! Quitte Possibilité à en prendre d’estimer moins …la vélocité à partir de l’historique  Estimer une Story : le planning Poker 18 Estimer la complexité Choisir une story connue de taille 1. Le PO présente la Story et réponds aux moyenne comme questions pendant un temps fixé étalon à laquelle on attribue la valeur 2, 3 2. Chaque membre de l’équipe choisit dans ou 5 sa tête une carte en fonction de l’effort qu’il estime Carte ? = Aucune idée 3. Au signal du SM, les cartes sont carte 0 = rien à faire /existe déjà montrées en même temps Si valeur unanime , on la prend comme taille de la Story Si divergence, les membres ayant donné les min et max s’expliquent. Après discussion on cherche une valeur consensus ou on répète le jeu.  Sommaire 19 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revue de Sprint 5. La rétrospective  3. Prêts pour le 1er SPRINT ? 20 Comme au Rugby c’est l’engagement collectif plus que les décisions d’un chef qui font une équipe qui gagne  Le SPRINT 21 Sprint de 3 semaines Planificatio Rétrospectiv n de sprint Revue de e Affinage sprint 2h 1h30 1h-1h30 1h-2h C’est l’équipe, et non un chef, qui va choisir un travail à réaliser, comment s’organiser et s’engager sur un horizon assez court (souvent autour de 2 semaines)  La planification de SPRINT 22 Objectif : mettre l’équipe en situation de réussir le SPRINT (comme la réunion dans les vestiaires avant d’entrer sur le terrain de Rugby) Prérequis pour être efficace : La story doit être prête : suffisamment petite et bien comprise par l’équipe (réalisable sans risque dans un sprint) C’est l’équipe qui planifie Le PO est présent du début à la fin de la réunion (répondre aux questions de l’équipe) Pas les parties prenantes (sauf les experts dont l’intervention est prévue pendant le sprint) Durée de réunion limitée (2h max pour des sprints de 3 semaines) = motivation tout au long de la réunion  La planification de SPRINT : que fait-on ? 23 1. L’équipe se met dans le contexte du SPRINT Le PO rappelle la place du SPRINT dans la Release en cours Le PO donne la liste des stories prévues (en se basant la vélocité des sprint passés) Prévoir un peu plus de stories que la moyenne habituelle d’un sprint (20 % de plus) 2. L’équipe confirme, pour chaque story prête, sa confiance pour la finir Vérification de la capacité à la réaliser pendant le sprint Vite fait (quelques minutes) car normalement réalisé lorsque on a déclaré la story prête Mais un surprise peut amener à reporter une story La story entre dans le sprint MAIS pas définitf (cf étape 3) A la fin on a une liste ordonnée de stories : TABLEAU DE SPRINT  La planification de SPRINT : que fait-on ? 24 3. Préparer l’essaimage Division temporaire de l’équipe : l’essaim qui va s’agglutiner sur une Story le temps de la finir A l’image de abeilles, la Story aura son référent (« reine ») et ses développeurs (« ouvrières ») Référent = développeur qui connaît bien la story, reste référent pour 1 seule story jusqu’à la fin de la story Définir le nombre de story traitable simultanément (idéal 1 story/essaim à la fois). A la fin de la story l’essaim disparait 4. Identifier les tâches Tâche = petit travail qui contribue à finir la story Découpage effectué localement par chaque essaim Non figé : la liste pourra évoluer au cours du Sprint Si sprint long, les stories moins prioritaire pourront être découpées plus tard  La planification de SPRINT : que fait-on ? 25 5. S’engager Disponibilité : Si pas à temps plein, impact ? On peut élaborer un calendrier visuel Pas d’engagement sur un nombre exact de stories : garder des stories comme variable d’ajustement Permet de déceler des réticences chez certains (à prendre en compte avant la fin de la réunion) Engagement collectif nécessaire Engagement sur l’objectif du sprint (bénéfice attendu à la fin) : Objectif simple et court : ne pas abuser des « et »  Lancement du SPRINT 26 Les membres prennent eux-mêmes les tâches (dans l’ordre des stories) Pas utile d’attribuer toutes les tâches au début : on doit avoir du travail pour les premiers jours A demain L’essaimage, à priori, évite pour la … les tergiversations mêlée Une tâche pénible dont personne ne veut ? A priori il n’y en a pas : sert à finir quelque chose, identifiée à partir des stories Si pénible, elle est courte : 1 tâche d’un sprint = moins d’un jour de travail pour 1 personne. Penser à une affectation ludique : pile/face, dés, … Pas de mode directif : taches identifiées en commun = on les trouve moins ingrates que si elles sont imposées  Erreurs à ne pas faire 27 Mettre la pression sur l’équipe (PO ou SM) Le PO propose un objectif et définit l’ordre des stories candidates : c’est l’équipe qui décide ! L’équipe peut proposer des changements dans les priorités : le PO accepte ou pas. Des tâches préparées à l’avance (par le PM) Equipe moins impliquée Schéma de gestion de projet avec chef Ne pas faire de conception Attention à ne pas se lancer tête baissée dans la réalisation de la story Des stories/tâches trop longues (inspirées de la gestion de projets classique) SCRUM : 1 tache < 1 jour et 1 story = 1 à 3 jours Satisfaction, moral Idéal : 1 tâche finie pour la mêlée du lendemain  Erreurs à ne pas faire 28 Un plan de sprint rigide Garder du mou Des événements inattendus peuvent freiner le sprint, ralentir une tâche. Solution : prendre un engagement sur l’objectif Un engagement déraisonnable Ne pas prendre plus de stories que ce qui est réalisable en 1 sprint Fréquent chez les équipes qui débutent Si un engagement ne peut être tenu, cela ne doit plsu arriver après plusieurs sprints Mise en place de pratiques correctives lors de la rétrospective  Sommaire 29 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revue de Sprint 5. La rétrospective  4. La mêlée quotidienne 30 Comment fait un projet pour prendre un an de retard ? « En prenant un jour de retard, puis un autre … » Frederic Brooks  Un cérémonial balisé 31 OU : idéal devant le tableau mural où est affiché le travail de l’équipe, sinon en visioconférence. Tous les jours au même endroit QUAND : de préférence le matin en arrivant, tous les jours à la même heure DUREE : moins de 15 min FREQUENCE : Quotidienne (« no scrum no win »), sauf 1 er et dernier jour du sprint QUI : « la mêlée appartient à l’équipe » PO+SM+équipe Les personnes extérieures (parties prenantes) ne participent pas ou n’ont pas droit à la parole QUOI : …  Suivre l’exécution du Sprint 32 Deux formes d’imprévus : inhérents à l’exécution du sprint : OBSTACLES dus à des interférences extérieures dans le plan de départ : PERTURBATIONS EXOGENES OBSTACLE : Identifié au cours de l’exécution du sprint, dès qu’il apparaît Décrit dans un tableau par son état (à traiter, en cours, résolu), son impact (tâches bloquées/freinées) et la date de sa découverte Le SM a pour mission de les éliminer, mais peut demander du travail à l’équipe Une fois résolu, réfléchir à des moyens d’éviter qu’il ne se reproduise Exemples : un membre n’arrive pas à configurer un plugin de Wordpress, un expert est hospitalisé  Suivre l’exécution du Sprint 33 PERTURBATIONS EXOGENES En principe le SM protège l’équipe mais il peut arriver : L’ajout de travail à l’équipe La sortie temporaire d’un membre de l’équipe L’objectif du sprint peut être revu/modifié à la fin de la perturbation Mettre le travail ajouté sur le tableau de Sprint et l’absence d’une personne dans la liste d’obstacles Si la perturbation est régulière à chaque sprint : ajouter une story de réserve (pour le travail rajouté) ou tenir compte de l’absence d’un membre lors de l’engagement  Ajuster le tableau de Sprint 34 Tâches/ Stories finies En principe le PO Une story est finie quand sa définition de fini est vérifiée Une fois la story finie, ses taches sont supprimées (inutile d’en garder la trace) Changements dans les tâches L’équipe peut ajouter librement des tâches dans le plan (tâches découvertes pendant le sprint) ou en supprimer  Comment se déroule la mêlée ? 35 Se réunir debout en demi-cercle face au tableau mural Proscrire claviers, téléphones, … Eviter les tableaux numériques video-projetés (sauf équipes équipes dispersées) car tout le monde doit pouvoir manipuler Chacun s’exprime à son tour sur 3 questions : Qu’ai-je fait hier ? Tâche, en cours ou finie Que vais-je faire aujourd’hui ? En quoi consiste la tâche ? Pensez-vous la finir dans la journée ? Quels obstacles me freinent dans mon travail ? Si quelqu’un a la solution, il la donne. Si seulement des pistes de solution, on en discute ailleurs dans la journée. Se synchroniser par rapport à l’objectif du sprint et éventuellement adapter : renégocier l’objectif, ajouter/enlever une story, revoir les règles de fonctionnement (essaimage par ex.)  Variante de mêlée : orientée Stories 36 Pratique en cas d’essaimage Comment : Examiner les stories dans l’ordre Pour chaque Story, un membre de l’essaim présente ce qui a été fait, ce qui va être fait et les obstacles On ajuste la répartition sur les stories : un membre ayant fini une tâche reste-t-il dans l’essaim ou ouvre-t-il une nouvelle story ? Intérêt : une meilleure focalisation sur l’achèvement des stories (objectif principal) Inconvénient : risque qu’une personne ne s’exprime pas si un seul représentant de l’essaim parle.  Pour une mêlée efficace 37 Ne pas dépasser 15 min (« boite à meuh » si la discussion sort du cadre, …) Ce n’est pas un compte-rendu au SM (pas chef de projet !) Ne pas mesurer le temps passé sur une tâche ou une story (« j’ai travaillé 2h, il m’en reste pour 5h … ») Varier les mêlées pour maintenir l’énergie : Ordre de prise de parole Musique différente à chaque sprint Ballon de rugby passé de main en main pour montrer qui a la parole … Mêlée = moment où l’équipe reprend de l’énergie pour la journée  Sommaire 38 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revue de Sprint 5. La rétrospective  5. La revue de Sprint 39 « Pour connaître l’avancement d’un développement, il vaut mieux se baser sur du logiciel opérationnel plutôt que sur la documentation », Manifeste Agile  Une vraie démo du produit issu du Sprint 40 Animée par le PO L’équipe est satisfaite de montrer qu’elle a produit Les parties prenantes sont vivement conviées un résultat de qualité Pour un sprint de 2 semaines, dure 1h en moyenne Démonstration du produit qui ne porte que sur les nouveautés du sprint (20 min) CONFIANCE Eviter les Slides (projets classiques) : du concret ! InviterLes au feedback parties prenantes sont rassurées d’avoir vu un résultat concret  Déroulement de la revue 41 Préparer la revue : logistique (matériel, salle, …), répétition Ponctualité = 1er pas vers la confiance Le PO rappelle l’objectif du sprint et s’il est atteint ou pas. Si pas atteint, discussion sur l’impact en fin de réunion. Liste des stories qui seront montrées. Présentation de l’incrément du produit : démo des stories une par une. Membre de l’équipe impliqué dans la story ou PO ou les deux Collecter le feedback des participants sur les stories présentées. Le bac à sable peut être enrichi des demandes d’évolution suggérées. Manipulation éventuelle du produit par les participants. FEEDBACK POST REVUE ENCOURRAGE (avec deadline)  Déroulement de la revue 42 Evaluer l’impact obtenu : Vélocité : Comparer le nombre de stories finies à celui des sprints précédents et ajuster la moyenne Impact évalué pour savoir si le produit sera déployé Décider de l’avenir du produit Prendre une décision sur le déploiement, la date de fin de la release Décider de revoir ou pas le contenu (si date fixe de fin) Le PO présente l’objectif du prochain sprint suivi du feedback des parties premantes  Conseils pour la revue 43 Pas de modifications de dernière minute : démo qui plante … « mais ça marchait pourtant tout à l’heure ! » Ne montrer que ce qui est fini ! Et pas tout le travail réalisé Garder les discussions sur le fonctionnement (déroulement, tâches, obstacles, …) pour la rétrospective. Seul le produit compte Penser un scénario fluide pour la démo Inviter largement (parties prenantes) et expliquer que c’est un produit partiel Solliciter un feedback ultérieur  Sommaire 44 1. Découvrir le produit 2. Le Product Backlog 3. Prêts pour le 1er SPRINT ? 4. La mêlée quotidienne 5. La revue de Sprint 5. La rétrospective  5. La rétrospective de Sprint 45 Après le match, on « refait le match » avec les joueurs pour mieux faire au match suivant.  Objectif : s’améliorer continuellement 46 Se poser des questions sur la façon dont l’équipe a travaillé dans le sprint Inspection conduisant à des adaptations Un moment de réflexion collective : capitaliser sur les pratiques qui marchent et éviter de refaire des erreurs, partager des points de vue Durée 1h, la même demi-journée que la revue (vers 16h par exemple) Pour des sprints courts : faire en un seul jour revue, rétrospective et planification du sprint suivant QUI : tout l’équipe (pas les parties prenantes) Recherche d’améliorations et non de coupables Pratiques améliorées sans remettre en question les fondements de Scrum