Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Agile tour2015
Similaire à Agile tour2015 (20)
Agile tour2015
- 1. DoDelinant de la tête Frédéric Faure Bordeaux, 30 octobre 2015
- 2. Qui suis-je ? • Un javagiliste o 16 ans d’informatique et de Java o 9 ans d’agilité et de Scrum https://twitter.com/ffaure32 http://okiwi.org/ www.agiletour.org05/11/10
- 3. Merci à nos sponsors www.agiletour.org05/11/10
- 4. Objectifs de la session • Partager des idées • Partager mes expériences • Echanger et apprendre www.agiletour.org05/11/10
- 5. Tout ce que je sais c’est que je ne sais rien • Je n’ai pas de certitudes • Je ne suis pas prescripteur • Je n’ai rien à vendre www.agiletour.org05/11/10
- 6. Sondage • Qui connaît la pratique du DoD ? • Qui a un DoD sur son projet ? • Qui utilise son DoD ? • Qui trouve que cette utilisation sert vraiment ? • Qui dit une DoD et non un DoD ? www.agiletour.org05/11/10
- 7. NOTION DE FINI Ca compile donc ça marche www.agiletour.org05/11/10
- 8. Veni Vidi Vici • La notion de fini est par défaut implicite • La notion de fini est par défaut subjective o Au sein de l’équipe de développement o Entre l’équipe et le PO o Entre l’équipe et le client • Syndrome du « Fini ! Fini Fini ? » www.agiletour.org05/11/10
- 9. Nous n’avons pas les mêmes valeurs • « The moment you have a QA group you have already lost. You can’t put quality at the end of the process » @OlafLewitz • « Tant que vous avez une équipe de test derrière, vous restez dans le vieux paradigme, quelle que soit la peinture que vous mettez dessus » @addinquy www.agiletour.org05/11/10
- 10. Definition of Almost Done www.agiletour.org05/11/10
- 11. Toujours citer le manifeste agile « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée » « Un logiciel opérationnel est la principale mesure d’avancement » « Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité » www.agiletour.org05/11/10
- 12. Intermède Bonheur au travail www.agiletour.org05/11/10
- 13. Intermède Bonheur au travail www.agiletour.org05/11/10 Promo Agile Tour 3700 €
- 14. DEFINITION OF DONE Back to the basics www.agiletour.org05/11/10
- 15. Origines • Concept introduit en 2002 par Dan Rawsthorne o http://blog.3back.com/scrum-industry-terms/done- done-done-done-in-scrum/ • Intégré dans le « Scrum Guide » o http://www.scrumguides.org/docs/scrumguide/v1/sc rum-guide-us.pdf • Intégré dans le « Scrum Primer » o http://www.scrumprimer.org/primers/fr_scrumprime r20.pdf www.agiletour.org05/11/10
- 16. Définition de fini-terminé-done « L'équipe affiche de façon visible une liste de critères génériques qui conditionnent le fait de pouvoir considérer un incrément comme "fini". Faute de remplir ces critères en fin de Sprint ou d'itération le travail réalisé n'est pas comptabilisé dans la vélocité. » http://institut-agile.fr/sashimi.html www.agiletour.org05/11/10
- 17. Propriété collective de l’équipe • Défini par l’équipe • Appliqué par l’équipe • Maintenu par l’équipe • Critères génériques pour l’équipe (et non pas pour l’ensemble de la société) www.agiletour.org05/11/10
- 18. DoD visible • Le DoD doit être explicite • Le DoD doit être visible www.agiletour.org05/11/10
- 19. Intérêts • Plus de subjectif ni d’implicite • Compréhension commune et partagée • Guide la réflexion de l’équipe en amont du fini www.agiletour.org05/11/10
- 21. Atelier • Done List Creation Exercice o https://www.scrumalliance.org/system/resource_file s/0000/0451/Done_List_Creation_Exercise.pdf o Brainstorming o Catégorisation o Tri/Priorisation o Consolidation/Publication www.agiletour.org05/11/10
- 22. Catégories • 4 niveaux de « done » définis par Dan Rawsthorne www.agiletour.org05/11/10
- 23. Acronyme maison • DoD FAIT o Fini o Accepté o Intégré o Techniquement validé www.agiletour.org05/11/10
- 24. Intermède Bonheur au travail www.agiletour.org05/11/10
- 27. Ne pas se décourager • Près de 3 ans pour trouver une formule qui nous convienne www.agiletour.org05/11/10
- 28. Afficher le DoD dans la colonne terminé www.agiletour.org05/11/10
- 30. 1 post-it par item du DoD www.agiletour.org05/11/10
- 31. 1 responsable DoD par Story www.agiletour.org05/11/10
- 32. 1 post-it DoD par Story+checklist www.agiletour.org05/11/10
- 36. Revue != Validation www.agiletour.org05/11/10 • Montrer les stories au fil de l’eau o Planifier des démos intermédiaires avec le PO • Le Sprint n’est pas un mini cycle en V • Eviter l’effet « Mais c’est pas du tout ce que j’avais demandé » du PO en revue avec toutes les parties prenantes
- 37. Intermède Bonheur au travail www.agiletour.org05/11/10
- 38. Communauté de pratiques www.agiletour.org05/11/10 Une communauté de pratiques concerne des groupes de personnes qui partagent un intérêt commun ou une passion qu’ils pratiquent et apprennent à la faire d’une meilleure façon en interagissant régulièrement http://fr.slideshare.net/CyrilleDeruel/agile-france-2013-communauts-de-pratiques-en-pratique-cyrille-deruel
- 39. DEFINITION OF READY Pour pouvoir finir, il vaut mieux être prêt à commencer www.agiletour.org05/11/10
- 40. Acronyme pas maison • DoR INVEST o Independant o Negotiable o Valuable o Estimable o Small enough o Testable www.agiletour.org05/11/10
- 42. Definition of Ready, la petite sœur du DoD www.agiletour.org05/11/10
- 43. Du gros backlog aux petits bacs – Claude Aubry © www.agiletour.org05/11/10
- 44. Encore des dérives • La culture du backlog ne doit pas être un exercice solitaire (du PO) • L’équipe de développement ne doit pas attendre une spécification détaillée • Le plus important dans une User Story, c’est la conversation www.agiletour.org05/11/10
- 45. Intermède Bonheur au travail www.agiletour.org05/11/10
- 46. Intermède Bonheur au travail www.agiletour.org05/11/10 « Essayons d’être heureux, ne serait-ce que pour donner l’exemple » Jacques Prévert
- 49. Dodelinant de la tête (et pourtant tu savais qu’elle n’était qu’une garce) www.agiletour.org05/11/10
Notes de l'éditeur
- www.agiletour.org
- Frédéric Faure, toujours javagiliste, toujours 3 enfants, tombé dans le java à ma sortie d’école d’ingé, tombé dans l’agilité en 2006 Pas de blog mais un compte twitter assez famélique. Membre passif de l’association okiwi (je paie ma cotiz mais avec mes 3 enfants, c’est compliqué de faire des coding dojos tous les mois) => avant, lien delicious, très bonne initiative : elcurator
- Arpinum : des extremistes programmers Ayeba : la classe incarnée Okiwi : mes amis Merci pour leur engagement pour la communauté informatique bordelaise
- Effectué un travail de recherche dans la littérature sur le DoD J’ai une expérience très significative dans le cadre de mon projet mais aussi dans le cadre du déploiement de pratiques agiles sur l’ensemble d’un pôle de développement
- Certains citent Kent Beck, je suis plutôt Socrate Pas de certitudes, que des convictions Je n’ai pas la vérité, une solution miracle qui marche, je sais juste des trucs qui ont marché pour moi Rien a vendre pas consultant, pas en SSII, W chez un éditeur de logiciel (y a peu de chances que vous l’achetiez)
- Si tout le monde garde le doigt levé à la fin, pourquoi sont-ils là?
- Mode ninja : Ca compile donc ca marche Mode informaticien de base : Je comprends pas, ca marche sur ma machine => arrête tout, on prend ta machine et on la branche à la place du serveur de prod Mode test after : Les tests seront fait lors du sprint d’après, on fera un sprint de consolidation en fin de version On connait tous la fameuse question du manager au développeur quand il dit « j’ai fini » : mais tu as fini fini? (relation parent/enfant, retour à l’école)
- Petite apparté sur la notion de valeur
- Faut faire des trucs qui marchent, qui plaisent au client et en plus de qualité
- J’allais de tps en tps au boulot en vélo. Ma fille a eu un projet dev durable l’année dernière et elle m’a tanné pour aller à l’école en vélo. Franchi le pas en début d’année : J’emmène les enfants en vélo et je continue jusqu’au boulot. Franchement, j’arrive avec une patate comme jamais j’ai eue. Et honnêtement, si j’arrive à le faire dans mes conditions (40 ans, surpoids, 1,5km avec les enfants, +7km ensuite) vous pouvez le faire. Bordeaux est a peu près bien desservi en terme de PC, c’est assez plat. Essayez! En plus, les statistiques prouvent que plus les gens font du vélo, moins il y a d’accident de vélo par km parcouru (les automobilistes s’habituent à la présence des cyclistes et sont plus vigilants (angles morts, ouvertures de porte, respect des pistes cyclables, etc.)
- Concept assez ancien qui s’est petit à petit ancré dans la documentation officielle, notamment de scrum Lien vers article du créateur du concept (je reviendrai dessus plus tard) Dans le scrum guide, guide de référence des créateurs de la méthode (Schwaber et Sutherland) Dans le Scrum primer (Larman et Vodde, fondateurs du fwk Less) On parle ici et par la suite du DoD au niveau item du backlog (granularité user story)
- Si vous ne connaissez pas l’institut agile, très bon référentiel initié je crois par Laurent Bossavit qui référence les pratiques liées à l’agilité. Les mots importants : Équipe Visible Critères génériques
- L’aspect fondamental du DoD c’est qu’il ne doit pas être imposé de l’extérieur mais doit émerger de l’équipe. Un travail initial de définition qui doit être suivi au niveau application On reprend le concept d’inspect and adapt cher à Scrum pour le faire vivre. Il définit des critères génériques pour l’équipe qui peuvent s’appliquer à chacun des items qu’ils développent
- Explicite pour limiter les risques d’incompréhension au sein de l’équipe et entre l’équipe et les parties prenantes Intégré au management visuel pour ne pas être oublié en fin de story
- 3ème point est important. Ca doit aider l’équipe dans la réalisation de sa story, la guider dans son cheminement et même dans l’estimation et l’identification des tâches
- Atelier que l’on a effectué dans mon équipe il y a 2-3 ans qui permet de poser les choses
- Vous pouvez également vous référer à l’article susmentionné de l’initiateur du DoD. Il était parti sur 3 niveaux de done (coded/verified/validated) auxquels il a ajouté un 4ème qui intègre tout ce qu’on aime pas faire mais qui doit être fait (doc, formations, etc). Il découpe le DoD en fonction du niveau (Story : 2D, Feature : 3D, Produit :4D). C’est discutable mais ca amène la discussion sur le sujet des niveaux de DoD
- Moyen mnémotechnique qu’on avait instauré (et dont j’avais parlé l’année dernière) pour simplifier les choses.
- Regarder cette vidéo : très drôle Productivité baisse si on reste trop longtemps Si vous être bon, vous devez faire votre boulot dans le temps imparti Avoir une vie (famille, sport, okiwi) En tant que manager, etre un exemple pour son équipe (si vous ne partez pas, ils ne partent pas) Joyeux = + productif
- Combinaison de l’ensemble des tactiques précédentes : Affichage du DoD détaillé sur le board Une étiquette platifiée en mode checklist avec chacun des points à valider Un seul post-it DoD par user Story Une personne prend la tâche et devient donc responsable de sa complétion
- Pris en compte dans le burndown : Notre burndown se limite au décompte des tâches Le DoD correspond peu ou prou à notre granularité de tâches (entre ½ et 1 journée): Merges doc Checklist plastifiée Une personne responsable de la tâche
- Même si on fait attention, on peut arriver à des dérives : Toutes les stories sont presques finies, mais elles ne sont pas done donc elle n’apportent de la valeur donc on peut planter le sprint à 100%
- « Sans vous rien ne se fera » => présentation de Cyrille Deruel 2013 Mis un an à activer le concept - Un thème, un backlog, des personnes motivées, un rdv régulier (un peu de comm, c’est mieux) Ca commence à prendre lentement (2 niveau dev : agilité et JEE, 1 à venir côté PO grace au soutien de Fabrice Aimetti
- Vous connaissez tous l’acronyme INVEST. Il s’applique bien.
- Phrase que j’aime bien. On reste attaché au mode de fonctionnement Scrum de l’itération à durée fixe (pas mal de vertus pour organiser les cérémonies, pour mobiliser l’équipe sur un engagement, etc). Par contre, le processus de maturation du backlog se prête vraiment bien au flux (et donc au kanban)
- J’ai honteusement repompé un slide d’une présentation de Claude Aubry sur la notion de bacs que j’aime bien et qui permet de caractériser ce flux de maturation. On peut bien entendu mettre des limites de WIP pour kanbaniser le tout.
- Beaucoup d’équipes qui accusent le non respect du DoR de tous les maux quant à la non réalisation de leur DoD se reposent trop sur le PO pour cette phase. Certes, c’est de la responsabilité du PO mais l’équipe doit y contribuer.
- Le bonheur est communicatif.
- Finalement, ma conclusion porte plus sur le bonheur au travail. Si on reprend les exemples cités (vélotaf, go the fuck home, communauté de pratiques, citation prévert) convergent toutes dans le même sens : le changement est entre vos mains. Chacun à son niveau a le pouvoir de faire bouger les lignes. Même si on a l’impression d’être Sysiphe parfois, il faut perséverer et poser des cliquets!
- Nascimo, Encore une journée de foutue, la balade de chez tao