Pages

Friday, December 31, 2010

Il est beau mon scrum board

Le scrum board est un élément central au niveau d'un projet agile. Il est déjà fort utile sur des projets dit "non agile". Dans un contexte agile, c'est tout simplement INDISPENSABLE. Cela ne sert à rien d'en dire plus à ce sujet!

J'ai déjà pu lire des débats sur la forme qu'il doit prendre surtout dans des contextes un peu complexe d'équipes distribuées où il peut devenir numérique. Dans mon cas, sur un projet avec une équipe centralisée, on est resté très KISS : un simple tableau blanc aimanté de 2m * 1m est impeccable.




Scrum Wall
Vous parler seulement de notre Scrum board est trop réducteur. Il faut que je vous parle de notre "Scrum Wall". Un tableau blanc est un peu juste pour tout ce dont nous avions besoin. Comme nous avions de la place, nous ne nous sommes pas privé.

Voici donc notre Scrum Wall :


La photo est prise après la fin du projet, le partie tableau blanc est un peu vide :-).

Il est constitué (en partant du porte manteau, de gauche à droite) :
  • d'un A4 de rappel sur le daily Scrum :

Cette feuille n'était pas là au début, je l'ai rajoutée en cours de projet. Avec l'habitude du projet, nous oubliions parfois les fondamentaux. Ca fait toujours du bien de les avoir sous les yeux pendant notre Daily Scrum :-), même de dire que "je n'ai pas rencontré de problème particulier".
  • La partie gauche du tableau blanc : 
La partie gauche du tableau blanc est purement réservée au sprint. Dans cette partie se trouvent 4 colonnes : 
- To do
- In progress
- QA
- Done. 

J'ai dû rajouter une feuille en dessous car je n'arrivais pas à tout faire tenir sur une colonne pour un sprint. Haaa... ces équipes hyperproductives, je vous jure :-). La dernière colonne de cette partie hébergeait un ensemble de zones qui ont évoluées au cours du temps. Nous avons commencé avec :
- identification du sprint (numero et contenu)
- technique (problèmes)
- organisationnel (problèmes)
- RE7 (remontées d'infos suite à la recette)

Pour au final terminer avec : 
- identification du sprint (numero et contenu)
- corbeille (permet de faire le ménage quand la colonne "Done" devient trop remplie sans pour autant enlever les tâches du sprint en cours du Scrum Board).
- Actions après rétro (actions à effectuer sur le sprint par rapport à la rétro précédente).
- Problèmes (tous)
- Stockage des aimants : il faut bien les mettre quelque part. Au lieu de les retrouver dans la zone des problèmes organisationnel par exemple...

La partie droite du tableau blanc : 
C'est l'espace "temporaire", il sert un peu à ce qu'on veut. Comme vous pouvez le voir, comme la photo a été prise après la fin du projet, l'emplacement est déjà "squatté" pour un autre projet. Cette espace permettait de réfléchir ensemble, d'expliquer, de schématiser, d'y mettre les horaires de la prochaine démo et de la prochaine rétro.

  • La partie droite du mur : 
C'est le "A3 du projet". L'objectif est de proposer une vue synthétique du projet (la vision, les enjeux, la méthodologie, l'architecture globale, un mot sur Scrum, ...).

  • Et il manque??? Le burndown du Sprint que nous mettions entre le tableau blanc et le A3 du projet mais qui n'est plus là au moment des photos que j'ai prises.
  • Et en bonus, au dessus du tableau blanc, nous y avons mis des goodies que nous avions sur le projet, les cartes postales envoyées par les membres de l'équipe en congés,...

Beau et "clean"
Que vient donc faire la notion du "beau" dans un projet Scrum? 
Le principe d'affichage est à double tranchant. Il offre d'une part une transparence sur le projet et d'autre part justement, on ne peut rien cacher. Les apparences sont trompeuses mais elles ne laissent pas forcément une bonne impression :

Vous y croyez vous si la personne qui possède cette chambre est bibliothécaire? C'est possible mais c'est dur à croire avec cette seule vision:-) 
  • Vue de l'équipe : Le Scrum board est le seul outil qui permet aux membres de l'équipe de travailler ensemble de façon efficace sans se marcher dessus. De plus, c'est aussi cette même équipe qui s'en sert quotidiennement. le désordre attire le désordre et inversement!
  • Vue de l'extérieur, Scrum souffre parfois de son image. Les clichés ont parfois la vie dure :
-Le framework Scrum est parfois vue comme une méthode de gestion de projet exotique mais qui n'est pas applicable. On en arrive même à préférer ne pas dire qu'on fait du Scrum...
- "C'est quoi cette bande de rigolos qui joue avec des pos-its."
- "Et en plus ils font un poker au boulot"
- "Cela manque de rigueur"
- On a parfois du mal à comprendre que le fun peut faire partie du boulot.

Si on associe à cela un Scrum Wall qui n'est pas "clean", on a dû mal à projeter un image de qualité logiciel sur ce qu'on livre...

Il faut donc que le Scrum Wall soit beau!

CQFD

Des astuces
  • Un "A3 projet" de qualité : Sa réalisation est un exercice délicat qui nécessite de prendre du recul et du temps mais il est la carte de visite de votre projet vu de l'extérieur. Il facilite aussi l'intégration d'un membre dans l'équipe ainsi que la présentation du projet.
  • De la couleur : N'hésitez pas utiliser des couleurs différentes pour vos post-its d'un sprint à l'autre. En revanche, sur un sprint, essayez de vous y tenir.
  • Des couleurs et des tailles différentes :  Utilisez des post-its de tailles et de couleurs différents permet d'identifier rapidement des fonctions différentes. Nous utilisons par exemple des pos-its carré (76mm*76mm) pour décrire une User Story et des petits post-its rectangulaire (38mm*51mm) d'une autre couleur pour les tâches.
  • Utilisez un stylo feutre pour écrire. Ca augmente la lisibilité.
Une petite illustration : 
en haut : BAD / en bas : GOOD

Voici quelques illustrations de notre projet :
  • Un début de sprint (d'une semaine) :


  • Un sprint en cours (de 15jours, nous avons fait évoluer la durée de nos sprints) :

(Nous remontions la colonne de gauche au fur et à mesure des Users Storys terminées en haut).


Sur ce, bonne année à tous!

Tuesday, December 28, 2010

Intégration continue : "have fun" :-)

Je trouve que l'intégration continue est une pratique incontournable sur un projet de développement. Comme je l'avais déjà expliquée ici, la mise en place d'une démarche d'intégration continue peut ne pas prendre au niveau d'un projet de développement. Ce n'a pas été le cas sur le dernier projet auquel j'ai participé:


Un défi technique : tout doit être buildé
La mise en place d'une démarche d'intégration continue est d'abord un défi technique (en tous cas, ça peut l'être). Dans le cadre du projet dont je vous parle, nous avons un ensemble de plateformes de développements ayant des processus de builds différents (exemple : application jEE, application Iphone, application Android).

Le premier défi est donc de réussir à faire fonctionner le système d'intégration continue sur des plateformes hétérogènes. Le but est d'éviter que des membres de l'équipe plus ou moins spécialisés sur une ou deux plateformes et que celles-ci ne soient pas testées par l'intégration continue, seraient "à l'abri".

Notre serveur d'intégration continue est Hudson et notre gestionnaire de sources est Subversion. Un couple qui fonctionne bien.

Nous n'avons pas de soucis pour mettre en place l'intégration continue sur les applications jEE car nous utilisons maven pour les builder.

En ce qui concerne la plateforme Android, nous utilisons maven pour builder et signer l'application. L'intégration dans Hudson n'a pas posé de problème.

Le build Iphone est celui qui a été le plus complexe par rapport aux autres à mettre en place. Au final, avec un slave Hudson sur un de nos IMac et google comme ami pour trouver ça, ça s'est malgré tout fait assez rapidement.

Une fois de plus l'important est que tout soit buildé. Pour être transparent, on peut noter malgré tout des deltas sur le contenu des builds selon les plateformes. Par exemple, sur la plateforme Iphone, seul une compilation est effectuée alors que sur les applications jEE, il y a compilation, exécution des tests unitaires, execution des tests d'intégrations et déploiement.

Hudson notifie tous les membres de l'équipe par mail sur un build failed ou fixed.

 Un défi organisationnel : elle doit être adoptée par toute l'équipe
L'intégration continue c'est aussi et surtout une démarche et un fonctionnement d'équipe!
Comme je l'ai déjà dit, il ne sert à rien d'avoir une superbe plateforme d'intégration continue si un build cassé n'entraîne pas une mobilisation de l'équipe pour résoudre le problème. Même si normalement l'intégration continue est un outil pour aider l'équipe, il est parfois vu comme un outil "gênant".

Pour motiver l'équipe, il faut ajouter du fun :-). Le fun sur notre projet, pour simplifier, c'est d'être un peu ridicule le temps de corriger un build cassé. Voici notre règle : si tu casses l'intégration continue, c'est toi qui porte le chapeau jusqu'à ce que le build soit réparé. Et quand on dit porter le chapeau, c'est au sens propre et il y a même le choix :


Personne n'y a échappé sur le projet. Comme vous allez pouvoir le constater, il y a des têtes à chapeau ou pas.... On retiendra le "ou pas" dans l'équipe... :-). Juste pour repositionner le contexte, nous évoluions à cette époque sur un open space de 30 à 40 personnes qui n'étaient pas concernées par ce projet...

Au passage, merci à tous les membres de l'équipe d'avoir accepté que je publie les photos.

Je vous laisse découvrir ce que cela peut donner  : 

Bon ok, je commence par moi :
Une version sobre, discrete, ça passe presque inaperçu : 

Une version plus "je vous jure que c'est pas moi" :

Une version "pair programming", assez rare à obtenir :

version "total style" : 

version "j'assume" et en plus en vidéo :

version "faire abstraction, je suis au téléphone avec le client" : 

version "represent" : 

Au delà de ça, on va vu des comportements très intéressants émerger au niveau du projet :
  • Le temps de découverte du build cassé était très court : C'était en général un des membres de l'équipe qui venait gentiment déposer le chapeau sur la tête de la personne qui a cassé le build (le dernier commiteur). On devait être, la plupart du temps, en dessous des 30 secondes après que la notification par mail du "build failed".
  • Des temps de résolution de build cassé assez court aussi. De l'ordre de 15 minutes. C'est qu'en plus, ils grattent et ils tiennent chaud ces chapeaux :-)
  • Le fun, c'est contagieux : Il se trouve que le projet voisin du notre sur l'open space faisait aussi de l'intégration continue, le principe du ridicule a été réutilisé, je dirais même amélioré... Je vous laisse juger par vous même : 

Je crois qu'au final je préfère nos chapeaux :-).

Tout ça pour dire
que l'intégration continue n'a pas été vécue comme une contrainte au niveau de l'équipe. Bien au contraire : 
  • c'était un moyen d'améliorer la qualité sur le projet (notamment la qualité des commits)
  • c'était un moyen d'avoir du fun sur le projet et le fameux "team spirit".

Thursday, December 23, 2010

Scrum Box : la caisse à outil d'un projet Scrum

Avez-vous déjà remarqué la rapidité avec laquelle vos pos-its, vos stylos et autres fournitures disparaissent sur votre bureau. C'est d'autant plus gênant sur un projet utilisant Scrum car justement assez gourmand en fournitures.

Pour éviter ça, j'ai créé sur notre projet la "Scrum Box" :



C'est quoi donc "une Scrum box"? : 
On peut la voir comme la caisse à outil Scrum de notre projet.



Qu'est-ce qu'elle contient : 


  • Un assortiment de bloc de post-it carré 76mm*76mm. "les standards"
  • Un assortiment de bloc de pos-it rectangulaire 38mm*51mm. "les petits"
  • Un assortiment de marqueur pour tableau blanc.
  • Un assortiment de marqueur pour paper board.
  • Un ou deux stylos feutre.
  • Une dizaine de stylos à bille.
  • Un jeu de carte de Planning Poker.
  • l'adaptateur vga de mon mbp pour le video projecteur.
Elle doit être identifiée en tant que telle et porter le nom du projet!

Qui s'en sert?

L'équipe et uniquement l'équipe! Il peut y avoir des dérogations si c'est demandé gentiment :-)

Quand s'en sert-on?
Au quotidien, tous les membres de l'équipe viennent y piocher des post-its, prendre des stylos, et choses assez cool : les remettre une fois utilisé.

Et plus particulièrement lors des rituels de début de de fin de sprints : Nous effectuons le sprint planning, la démo et la rétro dans une salle un étage en dessous de celui où nous travaillons. Dans cette box, j'ai quasiment tous ce qu'il me faut pour mener ces rituels.

Est-ce vraiment utile?
Oui! C'est une évidence sur notre projet. On n'y prette même plus attention.
On peut se poser la question de savoir si ça permet de ne pas se faire piquer les fournitures par d'autres collègue sur d'autres projets, hé bien oui ça marche et pourtant la box est en libre service et juste en carton.

Avec elle, impossible d'avoir oublié son stylo lors d'un sprint planning!

Cela me permet d'avoir un stock intermédiaire et dédié au projet de fournitures. Elle permet d'être "toujours prêt". Il y a déjà pas mal de chose à préparer et à transporter lors d'un rituel de début ou de fin de sprint (entre le portable, son chargeur,  le video projecteur, des éléments pour faire la démo, ...), la box simplifie le transport de toutes les fournitures :-).

En tant que ScrumMaster sur le projet, ca a été un réel obstacle en moins pour moi ou pour les autres membres de l'équipe. Evidemment, il faut relativiser, il y a d'autres obstacles plus importants et plus compliqués à enlever sur un projet :-).

De retour!

J'ai délaissé un peu ce blog ces dernier temps. Ce n'est pas une volonté délibérée de ma part mais c'est plus dû à un manque de temps.

Je travaille depuis 6 mois sur un projet passionnant à Norsys où j'interviens en tant que ScrumMaster. Vous trouverez plus d'infos sur ce projet ici. Il y a deux facteurs principaux qui en font pour moi un projet très intéressant :

  • Une liberté de choix technologique : Sur ce projet, tout est centré sur le but à atteindre et non sur le comment l'atteindre.
  • "Have fun": Le facteur humain est super important. Une équipe motivée, un vrai "team spirit", la mise en oeuvre de Scrum/XP et c'est le pied! Notre Daily Scrum a même été diffusé sur M6 Capital :-).
Les idées de posts ne manquent pas sur ces différents sujets! Promis, Je m'y mets!