Merci à l'équipe Primeweb

C’est fait, j’ai terminé ma mission de 14 mois chez BNPParibas, à l’Arbitrage, dans le département Prime Brokerage. Un pot de départ plus tard, et je suis revenu à la maison avec un Nabaztag, offert par tout le monde. Un grand merci à tout le monde, j’ai baptisé le lapin « primeoueb » en souvenir de cette année passée avec vous. Bonne chance à tous pour la suite.

Arrivé en septembre 2008, j’ai tout d’abord travaillé avec Nicolas Griso de Xebia pour remettre à plat toute l’usine logicielle. Passage de Maven 1 à Maven 2, amélioration des temps de compilation, et développements sur les parties un peu touchy, comme un cache par exemple. Zéro Scrum, pas de gestion de projet, rien. Ce n’était pas encore le moment. Quelques semaines plus tard, j’ai proposé de passer en Scrum complet l’équipe. Nous l’avons tout d’abord divisé en 3 petites équipes pour refléter les différences fonctionnelles dans le produit. Il est vrai qu’avant cela, nous faisions un stand-up à 14 personnes… qui durait trop longtemps.

En janvier je me souviens être descendu aux services généraux pour récupérer des post-its, du scotch et des grandes feuilles de papier pour préparer des tableaux Scrum. Là grosse déception : post-it d’une seule couleur, pas de stylos pour écrire, et pas de feuilles. Après avoir piqué un rouleau dans une salle qui trainait, j’ai passé une commande sur JPG afin de se faire livrer dès le lendemain un gros stock de Post-Its de toutes les couleurs, du scotch, des feutres, bref de quoi bosser. Moment marrant : l’arrivée le lendemain au bureau. Me voilà entrain de dessiner sur une grande feuille 3 colonnes: « A faire », « En cours » et « Terminé ». Je scotche le tout sur un mur, devant la cafétaria. Environ 14mn et 23 secondes plus tard, GrandChef qui passe par là me demande ce que je fabrique. Je lui explique que je fais du Scrum, avec l’accord de ChefPrimeweb, un gars bien qui est curieux de voir ce que l’on va faire. C’est là qu’il faut être rodé pour expliquer Scrum en 3 minutes, sans vous planter. Grâce aussi à l’aide de Nicolas de Xebia, à deux nous lui proposons une petite présentation rapide au coin du comptoir de Scrum. On sent le scepticisme mais je détecte de la curiosité dans le regard… c’est gagné.

Premier exercice pratique pour les développeurs un matin : je leur demande de prendre des post-its et de marquer ce qu’ils sont entrain de faire actuellement. Au bout de 10 minutes, la colonne « En cours » est tellement remplie que les discussions entre les développeurs ressemblent à une négociation pour le meilleur emplacement sur un marché dans un petit village. Et vas-y que je te pousse ton post-it pour mettre le mien, et que ça discute car en fait ils sont 2 à bosser sur la même chose (et ils ne le savaient pas), et que ça demande aussi s’il faut mettre les bugs… Oui allez-y, mettez les bugs, on mettra une deuxième feuille de 2m par 3 pour la suite… Bref j’exagère car en fait ce n’était pas autant le bazar. Mais l’intérêt de cet exercice était de montrer que chaque développeur a trop d’activités en cours. Que bien souvent, une tâche n’est pas terminée car elle attend une approbation, plus de détails. Ou parfois aussi, parce que finalement le développeur est bloqué. Alors il prend une autre tâche… Exercice simple qui permet de voir aussi la quantité de boulot que l’équipe est entrain d’effectuer.

Nous travaillons ensuite sur la construction d’un Product Backlog. L’idée était de lister toutes les demandes, de les classer du plus important au moins important. Cela permet dès les premiers jours de ne se concentrer que sur les éléments les plus importants. Grâce à cela, Karim qui joue le rôle de Product Owner, peut aussi collecter les demandes des analystes financiers et les trier rapidement. Nous supprimons aussi rapidement les statuts utilisés jusqu’à maintenant. Avant, l’importance des demandes étaient classées de cette façon : « Nice to have / Normal / Important / Très important ». Le degré d’urgence : « Bas,Normal,Haut ». Et enfin la criticité dans le cas d’un bug « Trivial / Non bloquant / Bloquant ». Cette soupe de paramètre était interprétée différemment selon les personnes. Les développeurs se concentrent sur la criticité, là où quelqu’un du métier va plutôt hésiter entre « Important » et « Très important ».
Je demande un jour: « que fais-tu lorsque tu as 1 bug bloquant/Haut/Très important et qu’un deuxième bug avec ces mêmes caractéristiques entre dans ton système ? Tu mets une nouvelle catégorie comme Très très important ? ». Bien entendu non.
Nous avons donc basculé les JIRA avec un nouvel attribut « Scrum priority » afin de trier du plus important/urgent au moins important l’ensemble des bugs et des demandes d’amélioration. Chaque élément reçoit un numéro. Plus ce numéro est élevé, plus le JIRA est important. Un passage dans une Feuille Excel et voilà un Product Backlog priorisé. A l’époque les 5 premiers étaient numérotés 764 760 500 300 100 et 50. Aucunes règles de calcul, mais nous aurions pû en mettre une pour dire que « cette tâche est 5 fois plus importante que cette autre tâche » par exemple.

Ensuite nous avons tenté d’utiliser JIRA et Greenhopper. Sympa, mais finalement j’allais plus vite avec un fichier Excel pour faire notre suivi de Sprint. Les Sprint Backlog et le Burndown chart étaient fait avec Excel. Je vous donne un conseil de vieux : ne vous excitez pas sur un outil comme Greenhopper ou autre. Pensez que l’outil doit être simple, efficace. Si une feuille de papier fait l’affaire… très bien. Si vous êtes à l’aise avec Greenhopper ou IceScrum, très bien. Mais je vous recommande par contre de faire vos tableaux de suivi de Sprint sur une feuille collée au mur. Je suis aussi passé chez Vidal et ils font exactement la même chose. Rien de mieux qu’un post-it que tu déplaces le matin en discutant, lors du standup meeting.

Nous avons ensuite mis en place les cérémonies. J’ai trouvé que le rythme de mise en place était un peu lent. Un matin je me souviens avoir dit devant tout le monde : « Bon les gars… Là le projet est entrain de souffrir. On essaye de retirer un pansement tout doucement, alors qu’il vaudrait mieux arracher un bon coup ce pansement et passer à la suite. Je propose que l’on fasse du Scrum à fond, et pas du Scrum light. C’est pire que tout. » . Et bien c’était le truc à faire. Ne pas jouer avec une partie de Scrum, c’est pire.

Pour la rétrospective, j’ai un peu galéré au départ. Je ne savais pas comment faire parler les gars. Grand silence poli… certains mêmes bidouillaient leur iPhone pendant que je tentais d’animer la rétrospective… C’était gonflant. Finalement j’ai essayé quelques techniques. L’une des techniques qui a bien marché était la suivante. J’ai demandé aux développeurs de prendre les post-its des tâches livrées pendant le Sprint, et de les classer sur une ligne de temps sur un tableau. A gauche, l’élément qui a demandé le moins de temps. A droite, celui qui a demandé le plus de temps. Les développeurs ont donc dû discuter entre eux pour s’expliquer ce qu’ils avaient fait, afin de placer les post-its correctement. Pendant ce temps là je buvais un café tranquillement avec Karim, le Product Owner, qui du coup avait une rétrospective clé en main. Cela prend 5 minutes, et ça marche.
Nous sommes ensuite venu voir les écarts entre les estimations/cotations données par l’équipe 2 semaines avant, et la ligne de temps. Marrant de voir un JIRA côté à 3 points complètement à droite d’un JIRA côté à 5. En fait, celui à 5 n’était pas si compliqué et long à faire.

Aaaah les jours hommes… Unité aussi inutile que bénie des Chefs de Projets… En fait c’est une unité qui vous donne une estimation assez précise du moment où vous allez vous planter. Car cette unité ne marche pas. J’en suis convaincu. J’ai une des équipes qui continue à s’en servir, je ne sais pas comment dire qu’il faut arrêter…

Bon lorsque j’étais petit, à l’école nous parlions de voiture dans la cour. Et malheur à toi si ton père avait une voiture avec un moteur Diesel. Les enfants se moquaient de toi, booouhh ta voiture elle est toute pourrie. Et puis 20 ans plus tard, les mêmes enfants sont devenus des adultes. Avec une Golf TDI, une Seat Ibiza ou un Picasso HDi… C’est bien, vous avez compris. Et l’essence aujourd’hui, c’est old-school, limite hasbeen. J’attends le jour où ne pas avoir de véhicule hybride sera devenu ridicule…

Les jours hommes c’est pareil. Cela serait bien que vous arrêtiez. Vraiment. C’est bien trop réducteur. Alors lorsque quelqu’un demande « Combien de temps pour faire ce développement ? » vous devez mettre en marche votre cerveau afin de calculer un chiffre composé de la façon suivante:

temps estimé X risque X niveau_de_confiance X ce_que_vous_avez_mangé_ce_midi

Cela donne des chiffres rigolos qui ne veulent rien dire. Alors nous vous donnons un jeu de carte, estampillé Xebia, appelé « Planning Poker ». Je vous en ai parlé il y a bientôt 2 ans, ne faîtes pas ceux qui ne savent pas. Vous demandez à l’équipe de regarder la liste des tâches à faire. Quelle est la tâche que tout le monde connait le mieux, et qui a le moins de risque ? Pour nous, c’était faire une release du logiciel. Cette activité prend 2 jours calendaires, elle est subordonnée à quelques étapes importantes, des tests etc. Nous lui avons attribué la note de « 3 ». Ensuite, j’ai demandé à chacun de classer les JIRA en utilisant cette échelle. Et nous avons mis 3 sprints pour nous créer une échelle de valeur. Un JIRA côté à 1 représente quelque chose qui ne prend qu’une demie journée, voir une journée, qui est facile et qui n’a pas de risque. Un JIRA côté à 3 peut représenter quelque chose de facile à faire mais qui est long (>2 jours) ou simplement une tâche compliquée mais qui ne devrait pas prendre plus de 2 heures (identifier la raison d’un bug en jouant un test fonctionnel). Bref nous avons mis du temps à nous créer cette échelle de valeur. Et vu de l’extérieur, impossible pour un nouveau de comprendre qu’un JIRA marqué à 20 représente en fait 4 jours ou 7 jours…

Cette unité Scrum permet de mixer intelligemment votre confiance par rapport à la demande (est-ce que je sais faire ou pas), votre niveau d’expertise (est-ce que c’est mon domaine ?), votre peur (je le sens bien ce développement là) et aussi votre humeur (en ce moment je suis fatigué donc compte pas trop sur moi).

L’exercice de vote était sympa à faire avec l’équipe. Cela permettait d’animer la réunion. Il fallait un peu aussi montrer comment cuisiner le Product Owner afin de cadrer ce qu’il y avait à faire et ce qu’il ne fallait pas faire. Grâce à cela, les engagements et le contenu était plutôt précis.

J’ai regretté que les développeurs ne bossent pas à deux si souvent, mais c’était normal vu le contexte du projet et la quantité de travail à fournir.

Après avoir lancé Scrum, j’ai fait aussi quelques développements, du tuning Hibernate, de l’amélioration de certains composants, des tests et de l’analyse des performances, de l’analyse de la dette technique avec des outils comme XDepend, un peu d’architecture… bref des trucs sympas. En août 2009 j’ai commencé une étude sur les Portails d’Intégration suivants : Liferay, eXo Portal et Oracle Weblogic Portal. Bonne expérience, qui m’a donné aussi l’occasion de rencontrer du monde chez Oracle, chez eXo Platform et chez Jahia. Au final il n’y a pas de vainqueurs, plus une recommandation par rapport aux besoins de l’équipe.

Nos voisins américains ensuite sont venus travailler avec nous. Sympa, mais j’ai aussi mis les pieds dans le plat en expliquant que leur solution de portail basée sur GWT-Ext était morte (depuis juin 2008). Mon boulot est aussi de dire lorsque le client fait un mauvais choix. Depuis ils basculent vers GXT. C’est mieux.

En partant je garde de bons souvenirs, où j’ai aussi appris beaucoup du côte fonctionnel, grâce à des personnes qui aiment leur boulot.

Bonne route à tous et merci pour cette expérience. Et le lapin s’appelle « primeoueb » donc je penserai à vous.

Articles similaires:

Merci Mr Jobs Java BarCamp 2 : merci OCTO Jug Summer Camp 2010 : merci au Poitou-Charentes JUG et au sponsor de Serli