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
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
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
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
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
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
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
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
49. Dodelinant de la tête (et pourtant tu savais qu’elle n’était qu’une garce)
www.agiletour.org05/11/10
Hinweis der Redaktion
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