Comme promis, la suite de mes interviews consacrées aux méthodes agiles, après celles de Didier Girard et de Claude Aubry. J’ai préféré attendre après la conférence Rencontres agiles pour discuter avec Bernard Notarianni, un des deux organisateurs. Bernard estime qu’au vu du succès de cette première édition, il devrait y avoir d’autres itérations, certainement plus thématiques. Le site Rencontresagiles2007.com sera d’ailleurs rebaptisé, pour ôter ce 2007 dangereusement proche de l’obsolescence.

Bien entendu, après avoir lu cette interview, vous vous direz, comme moi, bon, d’accord, il faut le voir en action. Et surtout en discuter avec M6. Rassurez-vous, c’est prévu, le rendez-vous est booké

Interview de Bernard Notarianni,
consultant chez Octo Technology

Les Rencontres agiles 2007 viennent de s’achever. On aurait pu s’attendre à ce que cette matinée d’information sur les méthodes agiles serve à l’évangélisation, or un rapide sondage de la salle a montré que la majorité des présents était déjà convaincue par leur intérêt. N’est-ce pas un peu dommage ?
Il est vrai qu’on aurait pu faire un effort particulier pour amener des gens qui ne voient pas plus que ça l’intérêt des méthodes agiles. On essaiera peut-être dans les mois qui viennent. Mais pour commencer, on voulait faire quelque chose de très simple, nous n’avons donc pas fait d’effort particulier. Toutefois, c’est toujours un exercice difficile, d’évangéliser quelqu’un qui n’en a pas forcément envie. C’est un peu ce qu’on vit chez les clients, il y a un premier investissement à faire.

Comment les méthodes agiles se sont-elles diffusées au sein d’Octo ?
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.

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.

J’ai rédigé un premier compte-rendu des Rencontres agiles de ce matin. Franchement, l’événement a attiré du monde, et regorgeait d’exemples intéressants.

Je n’ai pas mentionné l’intervention d’Eric Mignot (Pyxis Technologies) dans mon compte-rendu, car elle est complexe à résumer, mais j’ai - comme le reste de la salle - beaucoup apprécié son anecdote : lors de l’introduction du concept d’agilité chez un célèbre opérateur, il a commencé par mettre à la poubelle les 100 ou 200 pages du cahier des charges… On imagine la bonne ambiance ensuite. Toujours est-il qu’il dit avoir fini par leur extorquer leurs besoins prioritaires, et que le projet a été achevé dans les temps. Parmi les dialogues croustillants qu’il a rapportés : "Mais vous garantissez que toutes les exigences seront remplies ? - Bien sûr que non." Eh non, puisque la particularité d’un projet agile, c’est que ce sont les besoins prioritaires qui sont remplis, et qu’au fur et à mesure des itérations, les besoins peuvent évoluer.

Juste un regret : si l’on considère le sondage express mené au début de la matinée (alors que tout le monde n’était pas arrivé), la plupart des personnes présentes étaient déjà convaincues de l’intérêt des méthodes agiles. Dommage, car ce type de séminaire est, à mon sens, un très bon moyen de sensibiliser les gens.

Côté interviews (cf. ici et là), j’ai prévu de continuer, stay tuned

Cela n’a rien à voir avec la choucroute, je sais, mais voilà. Je viens de lire sur Slashdot que Terry Pratchett a annoncé qu’on lui a diagnostiqué les prémices de la maladie d’Alzheimer. Pour l’avoir vécu dans ma famille, je sais ce que cette maladie peut avoir de terrible, et j’espère que Terry Pratchett, incommensurable auteur des Annales du Disque-Monde, me fera hurler de rire encore longtemps.

Et puis après tout, si, ça a à voir avec la choucroute : si Pratchett n’est pas un auteur culte chez les geeks, alors qui l’est ??

Comme promis lors de la première itération, voici l’interview de Claude Aubry, consultant indépendant, expert en méthodes agiles, mais aussi enseignant à l’Université de Toulouse et organisateur de séminaires sur le sujet, que j’ai eu la chance de pouvoir rencontrer lors d’un de ses séjours à Paris, où il est justement en mission pour un grand compte.

Prochain RV en direct live aux Rencontres agiles, mardi !

Interview de Claude Aubry

Comment êtes-vous venus aux méthodes agiles ?
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 œuvre. 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.

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’.

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 œuvre, 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 œuvre, 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.

L’agilité, c’est bon, mangez-en !

Bon, au moins, si vous n’êtes pas un expert en méthodes agiles (enfin, même si vous en êtes un, après tout), mais que vous vous intéressez à la façon dont on peut améliorer à la fois la productivité et la qualité des projets de développement, je vous invite à vous pencher sur le sujet. Et à venir aux Rencontres agiles 2007, organisées par Didier Girard et Bernard Notarianni.

J’avoue - un peu honteusement - que nous n’avons pas consacré beaucoup d’articles à ce sujet. Ceci dit, nous sommes aussi, en quelque sorte, tributaires de l’actu. Or, il y a une actu : ce séminaire gratuit du 18 décembre. J’ai donc sauté sur l’occasion pour apporter ma pierre à l’édifice.

Je vous propose en premier lieu une interview de Didier Girard qui, sous sa casquette de directeur technique de Sfeir, a mis sur pied une équipe agile pour répondre aux demandes de certains clients. Suivront un entretien avec Bernard Notarianni, et avec Claude Aubry, qui interviendront aussi lors des Rencontres agiles. Je compilerai le tout sur le site, mais j’offre la primeur aux plus agiles de mes lecteurs, ceux qui viennent sur le blog

Interview de Didier Girard

Quels sont les bénéfices des méthodes agiles ?

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.

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.

Il semble que je me sois mal exprimé dans un récent article sur les SOA. Je voulais contextualiser le sujet, histoire de ne pas simplement reprendre les propos du CTO d’Accenture, mais mal m’en a pris (enfin non, ça génère de la discussion, et j’aime ça

Voici le passage en question :

Difficile de contredire Donald Rippert quand il explique que les
retours d’expérience en SOA ne sont pas encore légion, ou que toutes
les promesses n’ont pas été tenues. Néanmoins, on pourra objecter que
sa vision est extrêmement réductrice : des SOA sans XML, services Web
ou ESB peuvent exister ; de même, baser systématiquement un projet SOA
sur l’existant n’est pas forcément une bonne idée. Comme le préconisait
le directeur du conseil d’Orchestra Networks lors de notre SOA Forum,
il vaut mieux partir sur un projet avec l’idée de tout refondre à
terme, car la valeur d’une SOA dépend de la valeur de l’existant
informatique - si on se base dessus. Or, soulignait l’organisateur du
symposium architectes de Capgemini il y a quelques jours, construire un
système à partir des transactions existantes est un non-sens qui risque
de mener les projets dans une impasse.

Deux passages peuvent prêter à confusion.

Le premier, lorsque je dis que “baser systématiquement un projet SOA
sur l’existant n’est pas forcément une bonne idée”. Cela ne veut pas dire qu’il ne faut jamais le faire. De même que je ne dis pas qu’il ne faut pas d’interfaces XML, ou qu’il ne faut pas de services Web. Je n’ai jamais été un ayatollah des services Web ; on peut faire des SOA sans ça, je l’ai suffisamment écrit dans mes articles au moment où il était à la mode d’en mettre partout. De la même façon, je n’aimerais pas être vu comme un ayatollah anti-existant. Et quitte à me faire traiter d’employé de Capgemini par un lecteur mécontent, je paraphraserai la citation de Hyacinthe Choury (architecte leader de la SSII) parce que je l’ai sous la main et que je la trouve pleine de bon sens : il n’est pas nécessaire de tout renouveler, mais il faut avoir dans l’idée de tout renouveler à terme. En d’autres termes, ce serait bête de se priver d’un existant qui fonctionne, s’il remplit son office et qu’on peut l’intégrer dans une architecture plus vaste. En revanche, et c’est à mon sens une part de la beauté des SOA, le découplage que l’architecture induit permet à terme de remplacer un des composants - l’existant - quand le besoin s’en fait sentir (obsolescence, nouveau besoin…), ou lorsque le budget le permet.

Le second passage est le moment où mon interlocuteur parle de non-sens : pour être plus précis, je lui ai demandé si, à son avis, c’était une bonne idée de recourir à des outils de type web-to-host, qui permettent de récupérer les écrans pour les exposer en tant que services. Ce type de solution peut être utile, pour récupérer à moindre coût l’existant. En revanche, on perd énormément en agilité, puisque le processus reste figé dans le code. On perd donc une grande part du bénéfice. Et comme le soulignait Pierre Bonnet à notre Forum SOA, si on se contente de ce qu’il appelle une SOA de façade, le projet global n’a finalement pas plus de valeur que l’application mainframe. A-t-il raison ? J’ai tendance à le croire. Mais comme le disait ce matin un urbaniste d’EdF au séminaire organisé par BEA et Devoteam, on manque encore de recul pour véritablement évaluer tous les choix.