Présentation donnée par Frédéric Faure lors de l'Agile Tour Bordeaux 2013 : "Des processus et des outils pour aider les individus et favoriser leurs interactions"
4. Objectifs de la session
• 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
8. Un contexte favorable a priori
• Editeur de logiciel
• Soutien du management
• Des moyens
05/11/10
www.agiletour.org
9. Terrain hostile a priori
• 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
21. Story Mapping
• Jeff Patton – 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
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
Arpinum : des extremistes programmers
Yaal : les fous rêveurs
Ayeba : la classe incarnée
Merci pour leur engagement pour la communauté informatique bordelaise
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)
* embauché par McKesson (3 ans) après mission JEE chez eux
* à force que je leur parle d'agilité, embauché pour essayer (décision management)
* é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
- culture du cycle en V (cycles long, phases compartimentées, documentation centric)
- culture des équipes silo (archi, CQL, Services)
- certification CMMI
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
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)
- 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
J’ai mangé mon chapeau
Existance d’un PAQ sur les projets classiques. Très détaillé
Philosophie : principes de l’agilité, scrum check list
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)
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)
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.
Le plus possible favoriser les interactions
Si possible open source, ou du moins gratuit
Installable en local
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
- 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
Stories terminées, avancées, modifiées durant le sprint
Stories mises en pause ou définitivement exclues
*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
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
- 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
Autres avantages :
- uid et permaliens;
formalisme En tant que, je peux afin de
reporting
Attention : utiliser une BDD dédiée
stories alimentées et complétées lors des backlog grooming et sprint planning
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)
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
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
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)
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
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.
On peut tracer l’évolution dans le temps
- vue différentielle dans sonar (tag à chaque fin de sprint et possibilité de comparer par rapport au sprint précédent)
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
- 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)