Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Dis qu’est ce que ça fait de devenir Agile?
Similaire à Dis qu’est ce que ça fait de devenir Agile? (20)
Dis qu’est ce que ça fait de devenir Agile?
- 1. Dis qu’est ce que ça fait de devenir Agile?
- 2. Marie –Laure Momplot Travaille depuis fin 2009 avec le framework Scrum http://twitter.com/MaLainDa
- 4. « Les individus et leurs interactions plus que les processus et les outils » Valeur n°1 du manifeste agile
- 6. Présentation des personnages Agathe •22 ans •Développeuse
- 7. Présentation des personnages Victor •30 ans •Expert technique
- 8. Présentation des personnages Sébastien •38 ans •Scrum master
- 9. Présentation des personnages Béatrice •44 ans •Product owner
- 10. Présentation des personnages Pedro •40 ans •Coach agile
- 11. Point de départ de l’histoire Définition d’une US DONE User User Story 1 Story 2 -La solution implémentée répond aux critères d’acceptation de l’US User -Tests automatiques finis Story N -Livrée dans l’environnement de Product backlog test fonctionnels -Documentations projet à jour -… •Nous sommes au sprint 1 •Sprint de 3 semaines
- 12. 1er Daily Meeting Sebastien est ce que tu peux me dire quelle tâche je dois prendre ? Tu dois choisir une tâche, tu te feras aider si tu en ressens le besoin.
- 13. Après 1er Daily Meeting ? Qui prendra les tâches pénibles si chacun choisit sa tâche le matin? La responsabilité de l’équipe empêchera que les tâches pénibles ne soient jamais prises
- 14. Dans la 1ère journée Je vais perdre mon temps en pair programming… Elle va me ralentir.
- 15. 2ème Daily Meeting J’ai passé plus de temps que prévu sur ma tâche. Ce n’est pas grave explique nous ce qui coince.
- 16. Dans la 1ère semaine Une bonne solution passe par une bonne communication entre vous.
- 17. Daily Meeting dans la 2ème semaine Autant de temps L’important c’est le pour faire ça ?! reste à faire des tâches. Image : http://upload.wikimedia.org/wikipedia/commons/8/8c/Burn_down_chart.png
- 18. Dans la deuxième semaine User User Story 1 Story 2 3 1 User Story N Product n backlog priorité
- 19. Rétrospective Je ne veux pas être jugé… Tu sais , la rétrospective est là pour progresser tous ensemble, c’est le process qu’on analyse. Nous en sortirons un plan d’action. Image : http://hakanforss.files.wordpress.com/2012/04/slide4.png
- 20. Avant la présentation des User stories User story #1 – 3 SP 8 Story point, User story #2 – 5 SP on va plutôt User story #3 - ??? dire 5 c’est User story #4 - ??? plus réaliste.
- 21. Présentation des User stories Tu apporteras une meilleure réponse au besoin des utilisateurs
- 22. Dans la 1ère semaine Tu détailles trop les user stories
- 23. Avant la rétrospective Est-ce que la rétrospective est vraiment utile????
- 24. Rétrospective Victor tu n’as pas avancé la doc Nous ne sommes pas ici pour blâmer les gens mais pour progresser Image : http://hakanforss.files.wordpress.com/2012/04/slide4.png
- 25. Points de vue de Pedro après plusieurs Sprints
- 30. Pedro peut s’éloigner …
- 31. Merci de votre attention. Des questions?
- 32. Merci Pierre Fauvel! (http://pierrefauvel.wor dpress.com/) Merci l’organisation de l’Agile Tour Clermont- Ferrand
Notes de l'éditeur
- Me présenter en faisant 1 petite blague chez Michelin : "dans une multinationale qui fait des choses rondes noires utiles pour rouler" ;). J'ai adopté agile pour mon travail mais surtout pour toute la psychologie qu'on retrouve autour.
- En méthode Scrum, vous avez un backlog de produit qui contient des Users stories. Les Users stories sont un découpage du besoin fonctionnel. Elles sont priorisées et estimées point de complexité par l’équipe. A chaque itération ou Sprint, on construit les users stories sélectionnées par priorisation et en fonction de la capacité de l’équipe. Au début du sprint, ces users stories sont présentées à l’équipe pour une meilleure compréhension du besoin. Et ensuite, lors du sprint planning meeting, ces users stories sont découpées en listes de tâches : c’est le backlog de sprint. Les tâches sont ensuite estimées en heure par l’équipe. Chaque jour de l’iteration, lors du daily meeting, l’équipe se réunit autour de leurs tâches. Ils passent tour à tour pour expliquer ce qui a été fait hier, remonter les difficultés et dire ce qu’ils vont faire dans la journée. A la fin du sprint, une démonstration est faite d’un produit « partiel ». Pour analyser ce qui a bien fonctionné et ce qui reste à améliorer dans le sprint, l’équipe se réunit lors d’une rétrospective.
- Je vais vous raconter une histoire ... qui je l’espère vous présentera pourquoi il faut privilégier «Les individus et leurs interactions plus que les processus et les outils », la 1 ère valeur du manifeste Agile. Cette histoire est celle d'un projet agile qui débute. Le budget est établis et l’équipe est constituée.
- Laissez moi vous présenter les différents personnages que nous allons suivre tout le long de l’histoire.
- Dans l’équipe: il y a d’abord Agathe : une jeune diplômée: assez timide peu sûre d’elle. Sans trop d’experience, elle n’a fait que quelques stages avant cet emploi.
- Ensuite, Victor, un expert technique un peu ours, peu enclin à la discussion mais qui a déjà connu quelques projets en méthode dite « classique ». Il ne s’intéresse pas trop au monde fonctionnel, il préfère la technique.
- Mais aussi, Sébastien, ancien chef de projet. Comme Victor, il n’a connu que des projets cycle en V: mais il aime expérimenter de nouvelles façons de travailler. Il aime bien garder le contrôle sur son projet. De part son nouveau rôle de Scrum Master, il doit animer les différentes cérémonies du sprint comme les rétrospectives , les démonstrations… Sans pouvoir hiérarchique, c’est en revanche un facilitateur pour les problèmes non techniques de l'équipe. Sprint après sprint, il doit aussi surveiller que l’équipe est suffisamment alimentée en travail. Mais avant tout, il doit protéger l’équipe des perturbations extérieures. Il se charge aussi des indicateurs d’avancement du sprint et du projet.
- Béatrice, la product owner, représentante des utilisateurs. Elle porte vision du produit. Elle a une solide connaissance du fonctionnel, beaucoup d’expérience et des idées des fois bien arrêtées. Elle est responsable du product backlog et de la priorisation des users stories.
- Et enfin Pedro qui est là pour les accompagner dans le changement agile, son rôle de coach est de les guider au mieux. Il a déjà accompagné plusieurs projets et entreprises dans leur démarche de transformation agile.
- Pour lancer correctement le projet une phase de préparation a été faite. Elle a, entre autres, permis à l’équipe: d’avoir un product backlog initial de définir et partager ce que sont une tâche et une user story DONE c’est-à-dire la définition d’une user story ou d’une tâche terminées de choisir la durée de l’itération : dans notre cas 3 semaines d’être former à Scrum Cette phase de préparation nous amène au commencement du sprint 1. C’est le point de départ de cette histoire. Dans ce sprint, un certain nombre d’US ont été sélectionnées pour être implémentées. Elles ont été découpées en tâches par l’équipe lors du sprint planning meeting.
- Sprint 1 – Journée 1 - 1 er daily meeting Agathe est un peu angoissée. Elle doit choisir une tâche écrite sur un post it. Toute l’équipe est là autour du paperboard. Ne sachant quoi prendre, elle se tourne vers Sébastien. « Dis moi Sebastien, quelle tâche je dois prendre » Pedro la reprend: « tu dois choisir une tâche et demander de l’aide si besoin est » Pedro a déjà en tête de pousser les membres de l’équipe à se responsabiliser. Cela commence en choisissant, chaque matin la tâche qu’on doit faire.
- Sprint 1 – Suite au 1 er daily meeting Sébastien tient pour la 1 ère fois son rôle de SM. D'ailleurs , il se pose des questions suite au 1 er daily meeting. « Dis Pedro, et si les tâches comme la documentation ne sont jamais prises?? » « Est-ce qu’il y aura des volontaires pour les faire? » C’est une inquiétude normale d’ancien chef de projet qui avait pour habitude d’attribuer les tâches de façon plus autoritaire. La réponse de Pedro ne se fait pas attendre : « Il est de la responsabilité de l’équipe de faire les tâches liées à l’user story. Je te rappelle que la documentation fait partie de la définition du DONE de celle ci. Le fait que les tâches soient identifiées en commun, pousse l’équipe à les trouver moins ingrates que quand elles sont imposées Cependant, et si vraiment personne ne prend la tâche » poursuit pedro « il est de ton rôle de Scrum master, Sebastien , de t’en apercevoir et de mettre l'équipe en face de ses responsabilités jusqu'à ce qu'elle désigne quelqu'un. Cela fait partie de ton rôle de facilitateur.»
- Sprint 1 – Journée 1- dans la journée Le daily meeting est passé. Pedro reste en veille pour savoir si tout se déroule bien. Le développement se passe. Pedro se rend compte que Victor n’est pas très disponible pour les questions d’Agathe, qui en plus de sa timidité n’ose pas trop lui en poser. « Agathe, Victor » interpelle Pedro « est ce que vous connaissez le pair programming » « Non » répond Victor « La programmation se fait en binôme explique Pedro le premier, tient le clavier. C'est lui qui va travailler sur la portion de code à écrire. le second, est là pour l'aider, en suggérant de nouvelles possibilités ou en décelant d'éventuels problèmes. Cela permet au débutant de progresser très rapidement et assure une meilleure collaboration entre les personnes » Victor retorque « je ne suis pas convaincu. Je vais perdre du temps avec Agathe ». Pedro explique « Mais non ,Agathe montera plus facilement en compétence avec toi à coté et sera efficace plus rapidement sur le projet avec cette méthode. Tu lui montreras les bonnes habitudes de programmation en plus »
- Sprint 1 – Journée 2 - nouveau daily meeting De retour en daily meeting, Agathe est encore un peu angoissée. Et oui encore ! La timidité n’aide pas. Elle a choisi une tâche hier mais ne l’a pas avancé aussi vite que prévue. Sébastien s’en rend compte « Dis nous ce qui s’est mal passé ». Ainsi les blocages sont vite remontées et toute l’équipe est au courant. « Tu devrais demander de l’aide » lui explique t il . Sébastien comprend l’intérêt de créer un climat de confiance pour que les tâches avancent, il doit faciliter le bon déroulement du sprint. « Tu peux épauler Agathe dans son travail en faisant du pair programming?. » demande Pedro à Victor «Hier je vous ai expliquer l’intérêt du pair programming , voilà une bonne occasion de vous entrainer et d’essayer ».
- Sprint 1 – Journée dans la 1 ère semaine Pedro se rend compte que personne de l’équipe ne parle à la PO Béatrice. Les User stories doivent être approfondies avec Béatrice car ce sont des recueils de besoins. Il doit y avoir des discussions entre l’équipe et la Product Owner pour parler solution. Pedro demande à Victor, Agathe et Sébastien: « Avez-vous penser à mettre des tâches pour discuter sur l’User story et la solution que vous allez mettre en place avec Béatrice? » « Pourquoi faire? » lui demande Victor, « je n’ai pas à approfondir fonctionnellement le besoin. Je fais de la technique pas du fonctionnel. » « Comment pourras tu répondre de façon optimale si tu ne sais pas ce que l’Use story raconte? » rétorque Pedro « Essaye de voir avec elle quel type d’interface tu mettrais en place pour répondre à son besoin. Tu verras c’est très instructif. Pour elle comme pour toi.» « Ne crois tu pas que ça va augmenter le périmètre de l’user story? » demande Sebastien « le Po fait partie intégrante de l’équipe, elle doit elle aussi suivre les règles que l’on a établis comme ne pas demander plus ce qui répond au besoin qu’on vient d’embarquer dans le sprint. » répond Pedro « Je vous invite d’ailleurs à la voir pour lui proposer une solution la plus simple possible. Elle ne peut pas connaître toutes les solutions techniques que vous vous connaissez. » Même si développeurs et PO n'ont pas le même métier, ils peuvent bien souvent s'entraider. Des idées d’interfaces plus esthétiques plus intuitives sortent plus souvent de ce genre de dialogue.
- Sprint 1 dans la deuxième semaine Daily meeting Le SM inquiet de pas voir sa courbe de burdown chart « tomber» à tendance à vouloir attribuer les tâches … Le burndown chart est un indicateur graphique qui permet de visualise chaque jour la quantité de travail restant à faire. Sébastien fait une remarque sanglante à Victor : « pourquoi donc mets tu autant de temps à faire ça? tu avais dit qu’il te restait que 5 h…. » Pedro répond « Tu sais l’important c’est le RAF pas le temps passé. Il arrive que certaines tâches durent plus longtemps que ce qu’on avait prévu et c’est normal, les tâches sont estimées, et certains aléas arrivent: bug imprévu, optimisme… A contrario, certaines tâches iront plus vite que ce que nous avions prévu. L’objectif et de prendre les bonnes décisions pour tenir l’engagement de début de sprint.. De plus, avec le temps, l’estimation sera de plus en plus correcte.»
- Sprint 1 – dans le sprint Pedro veut revoir la priorisation du backlog avec sebastien pour savoir quoi prendre dans le prochain sprint. Béatrice doit prioriser son backlog mais elle n’y arrive pas pour elle l’ensemble est important. « Mais c’est important de prioriser ton backlog, les 1ères user stories implémentées seront celles qui ont la plus hautes priorités. » explique Pedro « Les utilisateurs finaux verront plus vite les fonctionnalités très importantes de ton logiciel lors des démonstrations. Et donc une acceptation du produit sera plus rapide. De plus si jamais le projet s’arrête (ce qui ne sera pas le cas ;) ) , tu auras le plus essentiel quand même. »
- Sprint 1 – Dernier jour du sprint - rétrospective Victor ne veut pas parler en rétrospective. « Je ne veux pas être jugé » grogne t’il. Pedro rappelle « la rétrospective n’est pas là pour ça mais plus pour trouver des axes d’amélioration sur l’équipe et non pas de pointer du doigts les personnes qui aurait mal travaillé. C’est un moment de cohésion d’équipe. C’est aussi le moment pour souligner ce qui a bien marché dans le sprint, afin de poursuivre ces points positifs. » Pedro affiche alors quelquse règles essentielles pour la bonne tenue d’une rétro: 1 chacun a fait du mieux qu’il pouvait avec ce qu’il avait lors du sprint qui vient de finir 2 Nous devons être bienveillants les uns envers les autres.… 3 avoir une attitude honnête et transparente « Tu sais , la rétrospective est là pour progresser tous ensemble » lui dit Pedro « c’est le processus qu’on analyse. Nous en sortirons un plan d’action. Je serai là pour que la rétro ne dérive pas. »
- Sprint 2 – Estimation en points de complexité des US Des nouvelles user stories arrivent dans le product backlog il faut les estimer. Pour cela, l’équipe utilise ce qu’on appelle le planning poker. Les participants s'installent autour d'une table, placés de façon à ce que tout le monde puisse se voir. Le responsable de produit explique à l'équipe un scénario utilisateur ( user story ). Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui permettront de la considérer comme "terminée". Chacun des participants évalue la complexité de ce scénario, choisit la carte qui correspond à son estimation et la dépose, face vers le bas, sur la table devant lui. Au signal du facilitateur, les cartes sont retournées en même temps. S'il n'y a pas unanimité, la discussion reprend. On répète le processus d'estimation jusqu'à l'obtention de l'unanimité. L’équipe estime l’user story à 8 story point ou point de complexité. Sebastien ne semble pas d’accord « 8 Story point ça va pas c’est plus 5, c’est plus réaliste! » Pedro le reprend « Cela fait plusieurs sprint que l’équipe livre de manière fiable, on peut se fier a son jugement. De plus tu ne sais rien des enjeux et difficultés de construction car tu ne programmes pas »
- Sprint 2 – Présentation des US Le Po se rend compte que le besoin a évolué suite à des remontées des utilisateurs finaux. Elle demande qu’une fonctionnalité soit modifiée. Objection de Victor « Je ne comprend pourquoi je devrais refaire un quelque chose qui a déjà été fait » Il a encore des anciennes habitudes, quand une fonctionnalité est développée on ne la modifie pas . « Je sais qu’il est pénible de refaire quelque chose que tu as déjà fait Victor » lui dit Pedro « mais c’est pour correspondre au mieux au besoin, ce n’est pas un souci avec le boulot qui a déjà été fait. Le besoin peut changer avec le temps, mais c’est pour la bonne cause. La nouvelle solution conviendra mieux aux utilisateurs. Ce qui reste notre but premier.»
- Sprint 2 – début d’itération – dans la 1 ère semaine Béatrice n’est pas assez disponible pour l’ équipe L’équipe a des questions sur les Users stories, mais Béatrice n’est pas là Sebastien et Pedro vont la voir. « Béatrice je sais que tu as beaucoup de choses à faire mais est ce que tu peux te rendre plus disponible pour l’équipe? » lui demande Sebastien. « Je sais mais entre les tests des User stories du sprint précédent à tester, celles du prochain à rédiger, » répond t elle, « et les questions sur les US du sprint en cours, je sais plus où donner de la tête. (Peut être devrai je avoir un autre Po sur l’équipe?» « un autre PO non car vous auriez du mal à vous coordonner » répond Pedro) « Cependant, on peut t’aider à aller plus vite sur tes tests, ou à rédiger des User Stories. Est-ce qu’on peut voir celles qui sont rédigées ?» Pedro lit quelques US et se rend compte que Béa en ayant maintenant une connaissance du logiciel, se met à écrire des solutions plutôt que des besoins. « Tes user stories sont trop dans la solution. C’est pour cela que tu perds du temps! Et en plus, tu perds la bonne synergie dans l’équipe. Pourquoi réfléchir à une solution avec un seul cerveau alors qu’on peut s’y mettre à plusieurs?? » lui remonte Pedro.
- Sprint 2 - Avant la retro -Seb « Est-ce que c’est vraiment utile ? » Demande Sebastien. « Est-ce que les gens n’y vont pas que râler ??? Regarde notre dernier plan d’action on a presque rien fait de ce qu’on a dit. » « Puisque presque rien n’a été fait, c’est que tout de même un minimum a été fait, donc il n’y vont pas que pour râler » argumente Pedro « Est-ce que ton plan d’action est fait d’action concrètes, mesurables et on était affectées à l’équipe? » « Peut être aussi que vos actions n’était pas en priorité haute par rapport aux tâches courantes du sprint. Il faut aussi prioriser l’amélioration continue. » « Et quand bien même identifier a minima une seule mais vraie action, c’est déjà bien. La bonne adaptation aux contextes changeants passe par l’amélioration continue »
- Sprint 2 – Rétrospective Sébastien dit « Victor n’a pas avancé la documentation » Pedro rappelle« Avoir une équipe efficace, C’est faire en sorte qu’elle résout elle-même leur problème sans chasses au sorcière. » « La réunion ne peut pas être constructive si le blâme nous menace du coin de la perte » « Essayez de tourner vos phrase avec l’usage du je « je croyais que tu devais avancé la documentation » Restons sur du factuel sans pointer du doigt quelqu’un : je vous rappelle que cette réunion doit être faite dans l’optique que chacun a fait du mieux qu’il pouvait avec ce qu’il avait lors du»
- Pedro revient vers la fin du projet. Après des débuts où sa présence était quasi journalières. Il ne vient maintenant que pour les retros. Il se rend compte que l’équipe a eu le temps de se découvrir, de se challenger. Chaque personne a réussi à trouver sa place, ils ont au fur et à mesure des sprints et de leur rétrospectives associées su s’améliorer. Chaque membre a eu le courage de sortir de temps en temps de leur zone de confort. Ils vont performer. Ils ont une bonne cohésion d’équipe. Il voit que chacun a évolué :
- Elle a gagné de la confiance en elle. Va voir les gens pour leur poser des questions. Va voir la product owner, elle comprend de mieux en mieux le fonctionnel. Elle est monté très vite sur les compétence techniques avec le pair programming. Elle explique sereinement pourquoi elle a bloqué sur certaines tâches. Elle est de plus en plus volontaire. Elle communique sans difficulté et avec sérénité. Elle n’hésite plus à remonter en rétrospective ce qui lui a déplu. Mais aussi ce qui lui a plu. Elle a d’ailleurs fait par à Pedro de sa volonté de continuer à travailler en Agile.
- Il comprend de mieux en mieux pourquoi la communication est importante et prend plaisir à faire évoluer techniquement ses camarades. Et pose de plus en plus de questions fonctionnelles pour avoir un produit qui correspond le plus possible aux attentes des clients. Il s’adapte rapidement aux changements. Pour cela il est souvent sorti de sa zone de confort. Il est moins grognon qu’à ses débuts.
- En travaillant main dans la main avec l’équipe, elle comprend de mieux en mieux les enjeux techniques de l’équipe, et est très contente de l’évolution fonctionnelle de l’équipe. Cette étroite collaboration a permis de construire des fonctionnalités à laquelle elle n’aurait jamais pensé. Elle adore les démonstrations qui lui permet de voir toutes les trois semaines l’évolution du produit. Elle fait entièrement confiance en l’équipe. Elle ne discute plus l’estimation de complexité de l’équipe. Leur estimation est d’ailleurs de la plus en plus précise Au vu de ses résultats encourageants, elle reste de plus en plus dispo pour des questions
- Ne contrôle plus systématiquement ce que fait son équipe, il lui fait confiance et elle le lui rend bien. Ils sont fiers de ce qu’ils construisent à chaque sprint et n’en sont que de plus en plus motivé à chaque fois . Il mise sur l’intelligence collective et la capacité créative de chacun. Il ne contrôle plus ne gère plus mais il stimule et coordonne parce que l’équipe se gère. Il ne transmet plus de directives mais les explique Et Il fait émerger les idées. Il reste toujours vigilant sur les bonnes pratiques de SCRUM . Il est content d’avoir essayé cette nouvelle façon de travailler.
- « Il est temps pour moi de m’éloigner. »confit Pedro à l’équipe. « Je suis content de votre évolution. Content de vous sentir fier d’être une seule et même équipe. » Il est important qu’une équipe agile nouvellement constituée soit bien accompagnée pour évoluer vers une meilleure communication interne. Ce projet lui a confirmé ce qu’il savait déjà. Centrer la réussite d’un projet sur les individus est une des clés du succès. Toujours faire en sorte que les acteurs d’une équipe soient : Communiquants/collaborants Auto organisés Partages les mêmes valeurs Ce qui lui permet de conclure : « Faites des rétrospectives : parlez vous, améliorez vous, mais surtout continuez d’apprendre, de rester l’esprit ouvert encore et toujours . On ne nait pas Agile, on le devient!».
- Un dernier petit slide pour dire merci aux gens qui m’ont aidé. Je pense d’abord à Pierre à qui j’ai piqué le titre et le temps qu’il m’a accordé. Et aux personnes qui ont su me donner des idées Mais aussi aux organisateurs qui m’ont laissé la chance de faire cette conférence