Téléchargé 11 fois
Des processus et des outils pour aider les individus et favoriser leurs interactions
- 1. Des processus etdes outils Pour aider les individus et favoriser leurs interactions Frédéric Faure Bordeaux, 8 Novembre 2013
- 2. Merci à nossponsors Gold Silver 05/11/10 www.agiletour.org
- 3.
- 4. Objectifs de lasession • Partager mes expérience • Partager des idées et des outils • Echanger et apprendre 05/11/10 www.agiletour.org
- 5. ἕν οἶδα ὅτιοὐδὲν οἶδα • Je n’ai pas de certitudes • Je ne suis pas prescripteur • Je n’ai rien à vendre 05/11/10 www.agiletour.org
- 6. Qui suis-je ? •Un javagiliste o 15 ans d’informatique et de Java o 6 ans d’agilité et de Scrum https://twitter.com/ffaure32 https://delicious.com/ffaure32 05/11/10 www.agiletour.org
- 7. 3 ANS D’AGILITECHEZ MCKESSON 05/11/10 www.agiletour.org
- 8. Un contexte favorablea priori • Editeur de logiciel • Soutien du management • Des moyens 05/11/10 www.agiletour.org
- 9. Terrain hostile apriori • Culture du cycle en V • Culture du silo • Objectif Certification CMMI 05/11/10 www.agiletour.org
- 10. Démonstration par l’exemple •Mise en place sur un projet R&D adapté o 3 développeurs o Un PO du métier o Interfaces limitées avec l’extérieur 05/11/10 www.agiletour.org
- 11. Succès du projet •Produit « innovant » • Une équipe conquise 05/11/10 www.agiletour.org
- 12. Déploiement à «grande » échelle • Comment on fait sur les autres projets ? • Comment on vérifie que les gens font comme tu dis de faire ? • Comment on sait combien ça coûte ? 05/11/10 www.agiletour.org
- 13. PAQ AGILE ETCMMI 05/11/10 www.agiletour.org
- 14. PAQ Agile • Inspirépar Thierry Cros 05/11/10 www.agiletour.org
- 15. Phase exploratoire • Constructionde la vision o Product Box et A4 o Impact Mapping 05/11/10 www.agiletour.org
- 16. Pilotage par lefeedback • Scrum by the book • Suivi de release • Gestion de la valeur métier 05/11/10 www.agiletour.org
- 17. Certification CMMI • • • • Certification niveau2 Fondé sur des « evidences » Respect des principes du manifeste Inspiré par la Scrum Check List 05/11/10 www.agiletour.org
- 18.
- 19.
- 20. Outillage pour larelease 05/11/10 www.agiletour.org
- 21. Story Mapping • JeffPatton – Story Map – • • • • http://agileproductdesign.com 1ère version physique Informatisation via Xmind Découpage horizontal ou vertical selon le contexte Walking Skeleton et MMF 05/11/10 www.agiletour.org
- 22.
- 23.
- 24. XMind • • • • http://www.xmind.net/ Version gratuite etopen source Structure Org (Bas) pour les story mappings Ajout de marqueurs 05/11/10 www.agiletour.org
- 25. Burn ups • Burnup de release (epic points) • Burn up de valeur métier 05/11/10 www.agiletour.org
- 26.
- 27. Gestion du backlog •S de INVEST pour « Sized Appropriately » 05/11/10 www.agiletour.org
- 28. Outillage pour lesprint 05/11/10 www.agiletour.org
- 29. Icescrum • • • • http://www.icescrum.org/ Version mature, gratuiteet open source Hébergeable respect de la philosophie et du déroulement de scrum o Cycle de vie des stories o Cadencement des sprints o Tests d’acceptation 05/11/10 www.agiletour.org
- 30.
- 31. Cadencement du sprint •Sprint planning (phase • • • • 1 et 2) (Démos intermédiaires) Backlog grooming Sprint review Rétrospective 05/11/10 www.agiletour.org
- 32. Management Visuel • Scrumboard classique 05/11/10 www.agiletour.org
- 33. Burndown Chart deSprint 05/11/10 www.agiletour.org
- 34.
- 35. DoD et DoR •DoR INVEST • DoD FAIT o Fini o Accepté o Intégré o Techniquement validé 05/11/10 www.agiletour.org
- 36.
- 37.
- 38. Usine logicielle • Jenkinset Sonar 05/11/10 www.agiletour.org
- 39. Déploiement de pratiques •Pour les projets non agiles o Stand up meeting o Management visuel o Revues • A venir o DoD et DoR o Rétrospectives 05/11/10 www.agiletour.org
- 40.
- 41.
Notes de l'éditeur
- #3 Arpinum : des extremistes programmers Yaal : les fous rêveurs Ayeba : la classe incarnée Merci pour leur engagement pour la communauté informatique bordelaise
- #6 Certains citent Kent Beck, je suis plutôt Socrate Certains utilisent des idéogrammes japonais, je suis plutôt grec ancien Pas de certitudes, que des convictions Je n’ai pas la vérité, une solution miracle qui marche Rien a vendre pas consultant, pas en SSII, W chez un éditeur de logiciel (y a peu de chances que vous l’achetiez)
- #8 * embauché par McKesson (3 ans) après mission JEE chez eux * à force que je leur parle d'agilité, embauché pour essayer (décision management)
- #9 * éditeur de logiciel - dans mon imaginaire, idéal de l'agilité (issu du monde des SSII) - plus complexe dans la réalité -> pas un seul produit, pas une seule version, pas un seul client, etc
- #10 - culture du cycle en V (cycles long, phases compartimentées, documentation centric) - culture des équipes silo (archi, CQL, Services) - certification CMMI
- #11 Equilibrer la demande « top down » avec preuve par l’exemple. Eviter le Big Bang (et puis j’avais pas les leviers pour, il fallait que je fasse mes preuves) 3 développeurs en me comptant. 2 agilistes convaincu, 1 dev à l’ancienne PO du métier, engagé avec du pouvoir et intéressé par l'innovation
- #12 Innovation fonctionnelle et IHM Scrum by the book : aucun support électronique, seulement du papier Mais agilité sur une patte Difficulté a obtenir des User Stories prêtes Équipe conquise (un anti agiliste parfait au départ, un PO sponsor, etc)
- #13 - ok, ca marche sur ton projet mais comment on fait sur des projets ou t'es pas là - simple, on intègre le manifeste, on applique scrum, on se focalise sur la qualité technique, etc. Vérifie : Scrum check list Combien ça coute C’est pas la bonne question Les estimations sont toujours fausses Le malheur d’avoir fait un release planning très juste sur le premier projet
- #14 J’ai mangé mon chapeau Existance d’un PAQ sur les projets classiques. Très détaillé
- #15 Philosophie : principes de l’agilité, scrum check list
- #16 vision (product box : pas fan des jeux agiles mais parfois, ca marche; A4; impact mapping) Équipe Environnement matériel Construction de la vision de la release - pilotage par les dates et story mapping (walking skeleton puis MMF)
- #17 Scrum by the book important pour des équipes en découverte (Shu-Ha-Ri) Suivi de release (via story mapping) Gestion de la valeur métier (modèle de valeur métier détaillé plus tard)
- #18 M’a aidé à construire des points de contrôles avec les équipes (appelés Audit PAQ qui ont lieu tous les trimestres et qui sont des piqûres de rappel pas inutiles). Ca permet aussi de voir la progression. Cette feuille de vérification est adaptée (simplifiée) à chaque fois.
- #19 Le plus possible favoriser les interactions Si possible open source, ou du moins gratuit Installable en local
- #22 Construction avec des post-its lors d’un atelier Utilisation d’un format informatique pour tracabilité, consultation à distance, facilité de manipulation Si découpage horizontal, Walking skeleton et MMF
- #23 - une boite ~= epic (1 à n user stories) - planning poker initial rapide (par affinité). Attention, epic points et non story points - engagement de release sur la confiance de l'équipe
- #24 Stories terminées, avancées, modifiées durant le sprint Stories mises en pause ou définitivement exclues
- #26 *feuille excel pour les graphiques pas pour faire des listes : sainte horreur : cf. http://blog.xebia.fr/2013/05/06/en-finir-avec-le-pilotage-excel-driven
- #27 http://www.excel-pratique.com/fr/fonctions/index_equiv.php marquer l'avancement Marquer ce qui est marketable - mettre à jour la valeur métier - mettre à jour les epic points terminés - mettre à jour les epic points supprimés ou ajoutés
- #28 - Une boîte de l’impact mapping représente un impact métier - Chaque impact fait l’objet d’un story mapping -> 1 activité ou une feature puis des epic Quand on arrive à la préparation du sprint, on construit vraiment des user stories INVEST saisies dans Icescrum
- #30 Autres avantages : - uid et permaliens; formalisme En tant que, je peux afin de reporting Attention : utiliser une BDD dédiée
- #31 stories alimentées et complétées lors des backlog grooming et sprint planning
- #32 On finit un sprint le mercredi aprem et on commence le suivant le jeudi matin (plus facile quand les PO doivent se déplacer) Démos internes pour valider les stories au fil de l’eau La rétro n’est pas une séance de validation mais dans la logique de l’inspect and adapt (revue commune à plusieurs projets pour faciliter le rassemblement des personnes)
- #33 User stories imprimées via icescrum à gauche Taches identifiées lors de la phase 2 du sprint planning Etiquettes identifiant les personnes travaillant sur une tache Détail dans slide suivant : burndown chart, DoD/DoR, gestion des obstacles
- #34 Pas d’estimation des taches (on a d’abord estimé en jours puis plus estimé puis estimé avec fibonnaci puis juste compté) Prise en compte des taches ajoutées Utilisation d’excel et/ou d’un crayon Rajout récent du décompte des obstacles
- #35 Identification lors du stand up Consigné sur petit post-it avec équipe responsable, date de début et pastille de couleur associée Le post-it est positionné dans le backlog des obstacles priorisé qui est revu à chaque standup Une pastille de même couleur est apposée sur la tâche bloquée qui est mis dans un espace de blocage volontairement limité en place (WIP)
- #36 Plusieurs représentation : - Juste l’explicitation affichée Check list apposé sur la carte Petits Post-its déplacables Attribution de la validation à un membre de l’équipe
- #37 Inspiré par Régis Médina. C’est quoi la clé d’une bonne équipe. Savoir les gens heureux, c’est pas forcément facile et pas forcément souhaitable. Savoir les gens épanouis dans leur travail, c’est ce qui nous concerne plus. Comment peut-on le jauger : le sentiment de contribuer au projet et le sentiment d’apprendre des choses. Très bon point d’entrée pour les rétrospectives.
- #38 On peut tracer l’évolution dans le temps
- #39 - vue différentielle dans sonar (tag à chaque fin de sprint et possibilité de comparer par rapport au sprint précédent)
- #40 déploiement de pratiques faciles à vendre et à mettre en place sur d'autres projets >stand up meeting remplaçant des points hebdos d’équipe. Intérêt vu par tous. Et ca prend bien (réflexe de ne pas déranger une équipe en stand up) >Management visuel (pas faire des post its pour faire des post it mais représenter le mode de fonctionnement actuel, à la Kanban). Sert de support pour le point quotidien >Revues : avoir une culture du démontrable et du toujours prêt >Réunions sans portables, ROTI
- #41 - 5 projets en cours officiellement tamponnés agiles - les solutions proposées sont globalement adoptées - resserrement des équipes (qualité, équipes transverses) vs culture du silo - kanban sur les équipes transverses - un peu trop d'attachement aux outils et au vocabulaire - certains réflexes persistent - (confusion scrum master - chef de projet) - management attaché au contrôle Outils Rester simple Garder un historique peut avoir son intérêt Eviter le plus possible la double saisie d’infos Ne pas trop s’investir pour ne pas se fermer des portes Bilan perso Accepter les compromis mais ne pas se trahir Sacrifier l’intérêt personnel pour l’intérêt général (accepter de dire non, se fâcher parfois avec les chefs)