LeMondeInformatique.fr : Quels sont les bénéfices des méthodes agiles ?
Didier Girard :Les bénéfices sont étonnants. L'objectif est de maximiser la valeur : le budget investi par l'entreprise reste identique à celui d'un projet classique, mais on optimise le retour sur investissement. Avant de le vivre, j'avais du mal à l'imaginer. Le périmètre fonctionnel du projet n'est pas forcément défini au départ : on délivre au bout de 15 jours, donc le client peut remettre en cause son périmètre tous les 15 jours. Mais au moins cela part rapidement en production, et le client est content. On a vu des gens applaudir, il y a même de la jalousie de la part des utilisateurs non concernés par le périmètre et qui voient l'application sur le poste de leurs collègues, je n'avais jamais vu ça.
Pouvoir remettre un projet en cause aussi souvent n'a-t-il pas des implications sur son architecture ?
A partir du moment où on respecte disons les normes de câblage et de plomberie, bref l'état de l'art, le périmètre peut être remis en cause. Mais de toute façon, les fondements sont rarement remis en cause dans un projet.
Les méthodes agiles sont-elles accessibles à tous ?
Eh bien, tout le monde ne peut pas intervenir dans un projet agile. Il faut être capable de se remettre en cause, d'accepter la critique. Les méthodes agiles impliquent le devoir de s'améliorer. Un projet agile démarre tous les matins par une réunion où on se pose trois questions : ce que j'ai fait hier, ce que je vais faire aujourd'hui et si j'ai des problèmes. Si quelqu'un tire au flanc, cela se verra très vite. Idem pour quelqu'un qui a du mal à avouer qu'il a des difficultés. L'important pour le client n'est donc pas le choix de la SSII mais celui de l'équipe. Au sein de la SSII, je sélectionne les profils capables de mener l'équipe au succès.
[[page]]
Dans la mesure où une SSII gagne de l'argent sur les avenants au contrat dans le cadre d'un projet au forfait, quel est l'intérêt de passer à des méthodes agiles ?
Il y a un risque dans la mesure où on peut être sorti à tout moment - à la fin de chaque itération, en fait. En revanche, contrairement au forfait, il n'y a pas de prise de risque budgétaire. Si on livre effectivement en temps et en heure, et avec de la qualité - auditée par un cabinet externe - alors c'est 'win-win', pour le client et la SSII.
Du coup, tous les clients devraient s'emparer de cette méthode ?
Nous le proposons, mais tous les clients ne sont pas mûrs pour cette approche. Dans certains comptes, les interlocuteurs n'ont pas assez de poids pour remettre en cause la façon de travailler. C'est une méthode très responsabilisante : ce que le client aura, c'est ce qu'il aura demandé. Il faut assumer le fait que certaines fonctionnalités viendront en dernier, voire ne sortiront pas. Il faut aussi mettre en place des bonnes pratiques, que la recette, par exemple, soit rapide : si cela doit durer toute une journée, que fait l'équipe pendant ce temps ? Il faut donc automatiser la recette, éventuellement en créant les jeux de tests à partir des spécifications formelles. Il faut outiller l'agilité, sinon cela ne fonctionne pas.
Tout projet peut-il être candidat aux méthodes agiles ?
Certains disent que tout peut y passer. Pour moi, ce n'est pas tant un problème de taille du projet que de taille de l'équipe. On ne butera pas sur la méthode elle-même, mais sur la constitution de l'équipe. Si 100 personnes y adhèrent, il n'y a pas de problème ; on peut ensuite découper en équipes plus réduites. Il faut reconnaître qu'aujourd'hui, les succès en France sont plutôt avec des équipes d'une dizaine de personnes.
LeMondeInformatique.fr : Comment êtes-vous venus aux méthodes agiles ?
Claude Aubry : Je suis indépendant depuis 1994. A l'époque, on était plutôt dans l'objet, UML, RUP... Je m'intéresse à l'agilité depuis plusieurs années, c'est un glissement naturel. En outre, ce retour au côté humain, aux équipes, me plaît beaucoup.
Voilà quelques années qu'on parle de méthodes agiles, mais qu'on ne voit guère de projets les mettant en oeuvre. Pensez-vous que le mouvement soit vraiment en train de prendre ?
Quand on regarde les conférences aux Etats-Unis, on ne parle que d'agilité, cela me paraît être un mouvement puissant. En France, on a une culture de processus lourds, avec beaucoup de papier, cela vient donc probablement plus lentement, mais je ne pense pas qu'il y ait un problème culturel. C'est juste un peu plus difficile, peut-être, mais aujourd'hui, je n'ai que des missions sur des méthodes agiles, et dans des grands comptes. Total, Areva, la CPAM et les laboratoires Pierre Fabre sont déjà venus communiquer sur le sujet dans des séminaires que j'organise.
Quel est votre rôle dans ces entreprises, aider à démarrer ?
Oui, il faut prendre connaissance du contexte, décider des pratiques à mettre en place. Il s'agit généralement de Scrum avec quelques variantes ; le duo Scrum et XP est d'ailleurs utilisé pratiquement partout, maintenant. On démarre un projet pilote, puis je fais des interventions ponctuelles.
Quelles sont les motivations de ces grandes entreprises qui vous contactent ?
Il y a d'abord un besoin de mieux connaître les méthodes agiles. Parfois, ce sont des SSII qui leur en parlent, et elles veulent savoir ce que c'est.
Peut-on démarrer un projet avec les équipes existantes, ou bien les méthodes agiles demandent-elles de choisir des profils spécifiques ?
Oh, il y a de grands débats sur le sujet, certains disent que cela ne conviendra jamais à certaines personnes. Je crois qu'on peut aussi former les gens. Ce qui est clair, c'est qu'il faut, au moins pour le projet pilote, que la constitution de l'équipe se fasse sur la base du volontariat. Si vraiment quelqu'un n'adhère pas, il ne reste pas dans l'équipe. Mais je n'ai jamais connu ça ; on essaie de résoudre les problèmes. Des résistances au changement, il y en a. Des refus catégoriques, non.
[[page]]
Quels bénéfices les équipes de développement trouvent-elles en général dans les méthodes agiles ?
En Scrum, il y a des réunions, très courtes, tous les jours. Les échos que j'en ai : cela améliore considérablement la communication, et on voit beaucoup plus vite ce qui ne va pas.
Les méthodes agiles sont censées aider à améliorer la qualité du code. Comment cela se passe-t-il ?
Grâce à une idée simple : rapprocher le plus possible la découverte d'une erreur de sa correction. Il s'agit d'un pilotage par les tests ; il faut pratiquer les tests pendant l'itération. Il faut donc que les spécifications détaillées débouchent sur les jeux de tests, et faire cela itération par itération, au moment où on en a besoin.
Et quelle est la valeur pour les entreprises ?
Il y a une valeur métier, car on pousse les personnes du métier à définir les priorités selon ce qui leur amène le plus de valeur. Cela dit, si on me demande le ROI, j'ai tendance à répondre : savez-vous combien vous allez perdre en continuant [sans passer aux méthodes agiles, NDLR] ? Car bien entendu, le fait de passer aux méthodes agiles doit répondre à un problème : si le développement actuel fonctionne, il n'y a pas de raison.
Le fait de livrer des spécifications itération après itération risque de rendre un projet interminable ?
C'est vrai qu'on ne demande au début qu'une liste d'exigences suffisante pour démarrer une ou deux itérations. Et que le fait de voir un logiciel qui tourne peut donner des idées pour la suite. C'est pourquoi il est préférable de fixer une date pour une 'release'.
[[page]]
Cela provoque tout de même une certaine incertitude quant aux ressources de la DSI ?
Il y a une notion qui s'appelle la vélocité : on estime les choses à faire, en se basant sur des points - et pas en comptant en jours. Ces points sont attribués en fonction du coût de développement. On sait qu'on peut réaliser un certain nombre de points pendant une itération. De là, on déduit une date, et ce qu'on peut faire pendant cette durée.
Y a-t-il des tailles idéales de projets ou d'équipes pour démarrer ?
Petit. En Scrum, une équipe doit comporter 10 à 12 personnes au maximum. Au-delà, sur des gros projets, on découpe, on fait des 'scrums de scrums'. C'est relativement facile avec trois ou quatre équipes de 10 personnes, au-delà cela devient plus complexe... comme pour toute grosse équipe. Après, tout cela dépend de la volonté de l'entreprise : Salesforce a décidé de passer à 300 personnes en deux mois !
Scrum donne beaucoup de conseils de bon sens, que les gens doivent déjà avoir l'impression de mettre en oeuvre, non ?
Oui, lors de la présentation avant la formation, certains disent qu'ils font déjà telle ou telle chose. D'autres expliquent qu'ils ne peuvent pas le faire, car ils n'en ont pas l'habitude, ou parce que cela casserait leur organisation, bref, qu'ils aimeraient bien mais qu'ils ne peuvent pas. Parfois, ce sont les mêmes.
Avez-vous été amené à renoncer, dans certains cas ?
Il y a des cas où les entreprises n'ont pas tout mis en oeuvre, parfois juste certaines choses qui les intéressaient. Mais on arrive toujours au terme du projet pilote. Cela devient plus complexe quand on étend, car cela touche à l'organisation, à la hiérarchie, aux ressources humaines... L'idée, par exemple, d'avoir plus un leader qu'un manager passe bien ; après, dans la pratique, ça dépend.
LeMondeInformatique.fr : Comment les méthodes agiles se sont-elles diffusées au sein d'Octo ?
Bernard Notarianni : Octo Technology est comme son nom l'indique très focalisé sur la technologie, et voulait apporter une dimension méthodologique ; l'évolution a été naturelle vers les méthodes agiles. J'ai rejoint Octo pour participer à des projets agiles et avec deux autres personnes qui nous ont rejoints, nous avons constitué un noyau il y a quelques années. Aujourd'hui, lorsqu'on fait des tours de table en interne, l'agilité revient sur toutes les lèvres ; les consultants en contact direct avec les clients veulent faire de l'agile.
Tous vos projets de développement se font-ils en agile ?
Oui, je n'ai pas rencontré de contexte où l'agile n'était pas pertinent. Nous avons aussi une activité de conseil, où on le propose, mais on ne fait pas forcément le développement. C'est ainsi que cela s'est passé pour M6 [dont le DSI adjoint est venu témoigner lors des Rencontres agiles, NDLR].
Lorsque vous proposez de partir sur les méthodes agiles, vos clients ont-ils tendance à accepter cela comme pour vous mettre au défi ?
Non, mais c'est vrai qu'on leur dit qu'il faut le voir pour le croire. Je dirais que tout est question de confiance. A partir du moment où il y a de la confiance, cela tombe sous le sens que ça va marcher. Là où il y a un doute, parfois, c'est justement sur le fait de savoir si on réussira à créer ce climat de confiance. C'est là qu'il y a une rivière à traverser. Quand il y a des enjeux très forts, que le client est un peu dos au mur, il accepte plus facilement de traverser la rivière. Mais l'agilité n'est pas réservée à ce contexte. Rien n'empêche de décider de faire confiance à la personne avec qui on va travailler.
Les témoignages des Rencontres agiles ont tous évoqué des succès. Avez-vous de votre côté connu des ratés ?
J'ai vécu un projet que je considère comme un échec - même si de son côté le client le considère comme une réussite, puisqu'il a été livré dans les temps et dans les délais. Le projet impliquait une centaine de personnes, et était accompagné par plusieurs personnes d'Octo. J'ai introduit des éléments d'agilité : découpage du projet en une dizaine de sous-projets, intégration continue avec livraisons incrémentales tous les deux mois, et forte focalisation sur les tests. Le mécanisme a bien fonctionné, mais j'ai le sentiment qu'on aurait pu aller plus loin. Cela ressemblait à des mini-projets au forfait de deux mois, il n'y a pas eu l'enthousiasme dont parlait le DSI adjoint de M6 lors de la conférence, ça c'est fait dans la douleur. Or, mon objectif dans un projet, c'est de faire en sorte qu'on soit tous fiers de ce qu'on a accompli.
[[page]]
Une question n'a pas vraiment été tranchée lors de la conférence : faut-il adapter la méthode à l'entreprise, ou l'entreprise doit-elle s'adapter à la méthode ? Où placer le curseur ?
Quand je rencontre un client qui parle de tel projet à mener en agile, l'essentiel pour moi, c'est qu'il comprenne que le plus important est l'équipe. La qualité du produit qu'on aura à la fin ne dépendra que de la qualité qu'on aura dans l'équipe. Le curseur est là. Après, il faut donner à l'équipe tous les outils dont elle aura besoin. Et globalement, l'équipe adhère à 90 ou 95% de ce qui est écrit dans le manuel. De toute façon, si l'équipe veut réussir le projet, elle fait ce qu'il faut !
Certaines choses passent-elles particulièrement mal ?
Ce qui a souvent du mal à être implémenté, c'est le pair programming [développement en binôme, NDLR]. Là, c'est à l'équipe de choisir. Certains préfèrent travailler seuls, d'autres à deux.
Il y a toutefois des impératifs à respecter ?
Oui. Premièrement, des itérations courtes. Une période de deux semaines me semble un bon chiffre, à partir de trois semaines, je commence à être mal à l'aise. Car si on n'arrive pas à faire une itération de deux semaines, ce n'est même pas la peine de penser réussir un projet de six mois ! Ensuite, il faut être vigilant sur la qualité, réaliser des tests à chaque étape, surtout les tests de recette en les automatisant à l'aide d'outils comme Fitness ou Green Pepper. Cela permet ainsi de progresser d'itération en itération. Et ce n'est pas seulement le code qui progresse, mais l'équipe entière.
C'est avec enthousiasme qu'Eric Hennetier, DSI adjoint de M6, est venu s'exprimer aux Rencontres agiles, le 18 décembre dernier. Il y a quelques mois encore, Eric Hennetier n'avait aucune notion concernant les méthodes agiles, aussi a-t-il volontiers accepté de témoigner de sa première expérience réussie, concernant une application publicitaire. Depuis, d'autres projets agiles sont venus s'ajouter, ce qui n'empêche pas Eric Hennetier d'y mettre des limites : « A mon sens, et à notre niveau d'expérience, cela ne peut pas s'appliquer à tout type de projet. » Il faut, dit-il, qu'il y ait des contraintes fortes, les méthodes agiles étant alors une bonne solution pour ce type de projet.
Bien entendu, toutes les équipes informatiques diraient que les contraintes de leur projet sont fortes. « Nous avons toujours en tête trois axes, répond Eric Hennetier : coût, qualité et délai. Je presse toujours les MOA [maîtrises d'ouvrage, NDLR] et les chefs de projet d'indiquer leurs priorités selon ces trois axes. Si l'axe prioritaire est le délai, alors on peut jouer sur la qualité. Non pas en diminuant la qualité, mais en réduisant le périmètre, en chargeant moins le backlog [liste des tâches à effectuer, NDLR]. » L'autre catégorie de projets éligibles, pour Eric Hennetier, ce sont les projets pour lesquels les besoins ne sont pas bien connus, « ou tellement changeants que cela peut partir dans une tout autre direction que ce qu'on imaginait au départ ».
Une demande en avril pour un projet à délivrer en octobre
En l'occurrence, le projet présenté lors des Rencontres agiles comportait de fortes contraintes en termes de délai : « La demande a été faite en avril, il fallait sortir l'application en octobre ; il était impossible de mener ce projet comme on avait l'habitude de le faire. » Des consultants d'Octo Technology, qui travaillaient déjà chez M6, sont mis à contribution sur l'architecture du logiciel à développer, et évoquent pour la réalisation les méthodes agiles. Or il se trouve que Michelle Garrigues-Fredet, DSI du groupe, « avait lu quelques temps auparavant un certain nombre d'articles et de livres sur le sujet ». Décision est donc prise de passer aux méthodes agiles. Octo participe alors au coaching, ainsi qu'au choix d'un prestataire pour le développement capable de s'impliquer dans un projet agile : ce sera la SSII Sfeir.
[[page]]
Selon les principes de l'agilité, chaque spécification fait l'objet d'une « user story », un cas d'utilisation écrit par la maîtrise d'ouvrage. Ces 'user stories' sont ensuite classées par ordre d'importance, et elles serviront à la fois pour la conception des tests et celle de l'application. L'équipe définit un cycle d'itérations de deux semaines : à chaque fin d'itération, il faudra présenter des développements théoriquement prêts à entrer en production. « Quand nous avons expliqué en interne qu'une itération durerait deux semaines, reprend Eric Hennetier, beaucoup nous ont regardé avec sympathie, mais ils n'y croyaient pas du tout. Il faut le voir pour le croire. » Au moment des Rencontres agiles, l'application était « en production à la date prévue, selon le périmètre prévu ». Soit 182 'user stories' réalisées en 15 itérations. Fin décembre, l'application en était à 220 'user stories' réalisées et recettées.
« Les premières itérations ont été une découverte. Car les équipes internes ont dû être coachées, s'imprégner de la méthode. Mais on s'y est mis rapidement. » L'essentiel, raconte Eric Hennetier, est que chacun se sente impliqué. Cela est guidé aussi par la méthode. Chaque matin, un 'stand up meeting', ou réunion debout, rassemble l'équipe sur un plateau, pour une brève revue de la veille et une distribution des rôles. En outre, la capacité de montrer très rapidement quelque chose aux utilisateurs renforce l'implication de la MOA. « Elle s'est prise au jeu. On faisait une présentation tous les mois, et ils en redemandaient. J'ai vu des chefs de projet heureux et fiers de montrer tous les quinze jours le travail réalisé. »
Pour Eric Hennetier, l'agilité garantit une meilleure qualité
Cette première expérience a séduit la DSI de M6. « C'est un développement vraiment piloté par les tests, explique Eric Hennetier. On définit des tests détaillés avant de développer, c'est une garantie de stabilité et d'évolutivité. » Il faut bien sûr outiller sa démarche, afin d'automatiser les tests. M6 a eu recours à Fitness. Contrairement aux projets classiques, qui réduisent souvent la phase de tests à la fin, voire font carrément l'impasse afin de terminer à peu près dans les temps, Eric Hennetier estime que les projets agiles sont une garantie de meilleure qualité. « Avec le principe des itérations, la complétude des tests est plus grande », dit-il. L'autre secret est d'impliquer très en amont les équipes d'intégration. L'équipe avait oublié de le faire au début, mais a vite rectifié le tir.
[[page]]
Fort de cette expérience, l'agile a été utilisé pour deux autres projets. D'abord la mise en place d'un référentiel de sécurité, répertoriant les utilisateurs et leurs droits d'accès, interconnecté avec toutes les applications. Dans la mesure où il s'agit d'un projet purement technique, et connecté à diverses parties du SI, il fallait pouvoir s'adapter aux changements de ces derniers. Or justement, observe Eric Hennetier, « l'agile permet de changer le besoin en fonction de l'avancement des autres projets ». Troisième projet à en bénéficier, l'application de déclaration des obligations auprès du CSA. Il s'agit d'un projet piloté par les délais. Mais surtout, le choix de l'agile « permet d'interagir avec les utilisateurs au fur et à mesure de la constitution de l'interface ».
Eviter l'effet tunnel, impliquer tous les acteurs
D'un point de vue politique, Eric Hennetier considère aussi le passage aux méthodes agiles comme un mouvement bénéfique pour la DSI. « Avec Michelle Garrigues-Fredet, nous avons tout de suite vu que c'était un moyen de répondre correctement aux besoins utilisateurs tout en étant réactif. » Le triptyque cahier des charges (qu'Eric Hennetier compare volontiers à une liste au Père Noël), effet tunnel et correction d'un grand nombre d'anomalies avant mise en production du logiciel cède la place à une démarche où utilisateurs, études et intégration sont impliqués de la même façon.
Après trois projets réussis, Eric Hennetier se dit prêt à utiliser les méthodes agiles pour des projets plus vastes. Développerait-il un nouveau système d'information ainsi ? Pour remplacer un progiciel intégré (PGI), par exemple ? « Je dirais plutôt oui. Je crois que nous devons d'abord rendre plus agile notre système d'informations en travaillant son urbanisation et sa mise sous référentiels. Du coup, cela permettrait aussi de segmenter les projets, et de revenir à des échelles compatibles avec l'agilité. Mais a contrario, je ne ferais pas d'agile pour mettre en place un PGI ! »
