Méthode agile, 1er test

Ça y est, l’équipe de dev de DuProprio vient d’accoucher de la nouvelle version du site de location. Devant le chaos qui avait accompagné le développement des différents projets toute l’année dernière (du type tout est encore plus prioritaire que ce qui est prioritaire), j’ai été séduit par la sirène de la méthode agile. Armé du livre Scrum and XP from the Trenches sugéré par Nicolas de chez Wanted, on a mis sur le feu le premier projet à être réalisé à la sauce agile chez DuProprio.

La méthode agile est très simple conceptuellement. On peut l’aborder de différents angles, selon la nature de nos projets. Les grandes lignes de comment on s’y est pris:

• Deux équipes — Chez DP, on doit vivre avec le fait qu’il y a aura toujours des cheveux qui arrivent sur la soupe (bugs, campagnes de pub à intégrer, opportunité à saisir, etc.) Réaliser en parallèle des projets et régler des problèmes courts termes, ça devient très étourdissant et très peu productif. On a donc séparé l’équipe en deux,  une pour les affaires courants, l’autre qui peut se concentrer sur le sprint.
• Basecamp — Cette application web est utilisée pour centraliser les échanges et gérer les échéanciers, colliger les choses à faire. Dans le cadre du scrum, on s’en est servi seulement pour discuter et logger les heures (pour comptabilité). Les développeurs ont aussi séparé les grandes tâches en to-do plus digestibles.
• Mindmap — Mindomo a été utilisé au départ pour la planification, discuter avec la direction des priorités et de ce qui allait être inclus dans le sprint. C’est une façon très visuelle et intuitive d’avoir une vue d’ensemble et de changer l’ordre durant la planification. Au départ, les objectifs d’affaires ont été discutés. Les programmeurs ont pu repartir de ça pour traduire en actions techniques.
• Gros tableau — Avec des aimants dans une salle. Sur chaque aimant une tâche assez macro (1/2 à 5 jours)
• Planning poker - Pour estimer la durée de chaque action au départ.

Globalement, l’expérience a été positive. Ce que j’aime de l’approche:

• Focus sur l’essentiel — On a tous la même maladie de bouillonite cervicale. C’est bon la créativité, mais à un moment il faut canaliser. Une fois le but clairement établi (dans ce cas-ci c’était de simplifier au maximum), toutes les discussions divergentes peuvent se régler. C’est vrai autant dans les discussions avec la direction qu’au sein de l’équipe de dev. Comme le temps de projet est fini, on coupe court aux solutions fonctionnelles et on se débarrasse de ce qui, au fond, ne compte pas vraiment.
• Prise en charge par l’équipe — Ceux qui ont travaillé avec moi savent que je ne suis pas du type à mettre de la pression, pour le meilleur et pour le pire. La beauté de la méthode agile, c’est que toute l’équipe prend possession du projet. Les estimés sont effectués de façon démocratique au départ, puis on se voit une fois par jour. Tout le monde est autonome mais a des comptes à rendre le lendemain matin à toute l’équipe.
• L’effet démo — Tout sprint se termine par une démo à qui veut bien la voir dans l’entreprise. C’est un aspect qui semble anodin mais qui est d’une subtile puissance. Ça m’a toujours irrité de voir comment on se force pour des comptes à rendre à l’externe mais qu’on est moins rigoureux envers nous-mêmes. Avec une démo, on se trouve à extérioriser le reste de l’entreprise et ça motive à faire quelque chose de fonctionnel à temps. C’est aussi valorisant pour l’équipe de dev, et très positif de passer l’information horizontalement dans l’entreprise.
• Partage des connaissances — L’idée de la méthode agile, c’est que tout le monde devrait être capable de tout faire. Pour que le projet avance, certains doivent quitter leur zone de confort et en apprendre des autres. À long terme, je crois que c’est très positifs pour une organisation.

Comme n’importe quelle première expérience, il y a des choses qu’on aurait aimé faire autrement, mais on ne le sait pas tant qu’on ne l’a pas fait. Ce qui a été plus difficile:

• N’importe qui ayant construit ou rénové une maison sait que la finition est toujours plus longue que le rough. Au début, on peut avoir le mirage qu’on avance vite alors que ce n’est pas le cas. Il y a pleins de détails qu’on n’a pas su prévoir et qui ont causé des retards.
• Dans le même ordre d’idée, comme tout est inter relié, j’ai trouvé difficile de définir ce qu’on peut considérer comme “terminé”.
• On aurait aussi dû séparer le travail en action un peu plus courtes. Plus les durées sont longues, plus l’incertitude grandit. 3 jours devrait être maximal.

Utilisez-vous ces méthodes dans votre organisation? L’utilisez-vous à autre chose que pour de la programmation? Je suis curieux de connaitre vos expériences ou conseils.