J'ai assisté ce mardi 20 octobre à l'Agile Tour de Grenoble. Cette fois-ci nous avons été nombreux (au moins 300 personnes) et le programme était intéressant. J'ai dû donc prioriser les sujets.

L'Agile Tour a commencé avec une présentation de Henrik Kniberg sur ce qu'est l'agilité. Bien que connaissant le sujet, j'ai trouvé rafraîchissant cette piqure de rappel. Je suis assez reconnaissant à Henrik pour le livre qu'il a écrit "Scrum And XP From The Trenches" et qui m'a permis de commencer à mettre en place SCRUM sur mon projet actuel, il y a maintenant 2 ans.

Elle a fini, en fin de journée, sur une note de Jérome Barrand sur l'agilité dans d'autres disciplines autre que l'informatique. Nous y avons appris en l'occurrence que l'agilité n'est pas nouveau et qu'elle est même assez ancienne dans certaines disciplines. Il semblerait aussi qu'elle commence à s'introduire dans des domaines aussi surprenant que la finance ! Malgré tout, si l'agilité prend bien dans les entreprises de petites et moyennes tailles, elle a vraiment des difficultés à pénétrer les grandes sociétés qui sont encore régies par une forte hiérarchisation et une parcellisation du travail et des responsabilités.

Entre les deux, j'ai assisté à 4 séances parmi les 24 proposées (6 présentations sont proposées au choix par tranche d'heure) :

  • Retour d'expérience : Le Lean et la création de sites Internet animé par un canadien dont j'ai oublié le nom mais qui n'était pas la personne prévue (elle a eu un accident de moto !),
  • Comment concilier Agilité et projet au forfait animé par Jean-François Jagozinski,
  • La gestion des défauts et besoins non fonctionnels avec SCRUM animé conjointement par Luc Jeanniard et Éric Mignot, deux SCRUM Masters,
  • et un Coding-Dojo : Kata sur le pilotage par les tests d'acceptances (ATDD) animés en binôme par Rémy Sanlaville et Emmanuel Hugonnet.

Le retour d'expérience sur l'application du Lean était intéressant. Une Web Agency s'est créée vers 2000-2001 et n'a cessé de croître jusqu'à connaitre depuis 2007 ce que l'on appelle une crise de croissance. Celle-ci s'est manifestée par un accroissement de son stock de logiciels en développement ou à développer, dérivant dangereusement dans le temps ses livraisons et aboutissant à un mécontentement croissant des clients. Un de ses clients, qui se trouve être une société de conseils sur le Lean, lui a proposé alors ses services. Avec l'aide de la région, 60% a été pris en charge dans le cadre de Agilité PME. La Web Agency a embauché un Lean Manager qui, avec l'aide de la société en conseils, a commencé à prendre la mesure des problèmes d'organisation. A partir de là il a mis en place, via les managers et employés même de la société, une nouvelle organisation basée sur le Lean. Cette dernière a donné apparemment de très bons résultats mais il reste encore pas mal de choses à faire.

La présentation suivante a été aussi un retour d'expérience sur l'application de l'agilité dans le cadre d'un projet en forfait. Plus exactement deux retours d'expériences : un échec et un succès. Le projet qui a été un échec l'était dû au fait que le contour du projet a été imposé dès le début : le périmètre fonctionnel, le temps, et le budget, ne laissant ainsi aucune latitude à la société de services (en générale, les sociétés de services s'en tire avec le système d'avenants). Le projet réussi a tiré les leçons du premier. Le client et la SSII se sont accordés sur un temps de calibrage de trois sprints avant de s'engager sur le périmètre fonctionnel, le délai et le budget. Ce temps de calibrage a permis de mettre en lumière que le projet était impossible à tenir dans le périmètre, le délai et le budget demandé au début. Après négociations, il s'avéra que le client donna la priorité au périmètre fonctionnel, ce qui permit alors de jouer sur le délai et indirectement aussi sur le budget pour remplir les exigences. Finalement, le projet se termina avec le contentement de tout le monde : le client et la société de services y ont trouvé chacun leur compte, ils ont été gagnant-gagnant. Ce que j'en ai tiré de cette présentation est qu'aujourd'hui l'application d'une approche agile dans le cadre d'un projet en forfait dépend beaucoup du contexte et plus particulièrement du client.

La troisième présentation a été en fait un jeu assez animé de questions-réponses. Au travers d'un jeu de transparents, des problèmes que l'on rencontre souvent dans SCRUM sont posés. Il y avait entre autre comment prendre en compte les bogues ou comment considérer la mise en place de l'architecture du projet au premier Sprint. Luc présentait le problème avec des exemples de cas et Éric apportait des réponses. Chacun dans l'assistance pouvait poser aussi ses questions. Évidemment, les réponses dépendent du contexte même du projet mais il était intéressant de voir comment Éric ramenait les choses sur un autre plan afin d'appréhender le problème différemment, dans l'idée de prendre du recul et donc apprécier la solution qui des fois s'avéra évidente. Pour ce faire, il s'appuyait sur les 4 piliers de l'agilité :

  • un processus empirique,
  • un carnet priorisé,
  • des livraisons incrémentales,
  • une équipe autogérée.

et c'est sur l'une ou plusieurs d'entre elles qu'il ramenait le problème. Il était aussi amusant d'entendre comment le principe d'offshoring, tel qu'appliqué dans nos entreprises, a été démonté en quelques mots selon la perspective d'une approche agile.

Le Kata, quant à lui, a été l'occasion, au travers du défit du jeu du pendu, de montrer l'usage de Cuke4Duke (une version de Cubumber pour Java) dans l'écriture de spécifications exécutables. Tout le long de la séance, le pilote et co-pilote ont montré comment pouvait se dérouler un développement selon ATDD et comment on passait de l'ATDD (avec Cuke4Duke) à TDD (avec JUnit), et vice-versa. L'ATDD est encore jeune et les outils, s'ils deviennent maturent, ne semblent pas encore être en capacité à répondre à tous les projets. En effet, le défit portait sur un programme en mode console texte, or des projets reposent sur l'écriture d'applications avec une interface Web et dans ceux-ci il est encore difficile voir impossible de mettre en œuvre ces outils ; il faut en effet tester l'application fonctionnellement via son IHM. (J'en ai déjà fait l'amer expérience avec une application GWT.)