Suite de mes entretiens en amont de l’édition 2009 de l’Université du SI , dont LeMondeInformatique.fr est partenaire presse. Le créateur de l’événement, François Hisquin, DG d’Octo Technology, avait demandé à me voir il y a quelque temps, pour voir ce que nous pourrions faire ensemble. Il était normal qu’après Djamel Zouaoui , et Didier Girard (de Sfeir mais intervenant à l’USI), je discute un peu avec l’organisateur lui-même (en plus autour d’une côte de boeuf de l’Aubrac, ce qui ne gâte rien). (A lire aussi, l’entretien de Jean-François Helie )

Comme vous le verrez, la conversation est venue à un moment sur les notions de ‘lean’ et d’agilité. Ce qui explique pourquoi, quelques jours après, j’ai suivi avec grand intérêt ce thème lors de l’IT Forum de Forrester. J’ai rapporté cela dans un article hier .

Du côté d’Octo, lean et agilité sont des notions qui enlèvent énormément de complexité à certains problèmes. Lire la suite…

Fin de ma journee Lean / Agile. (Et vu que Monfils s’est fait sortir en trois sets, je regrette moins

(Du coup, si vous etes amateur de tennis, comme il n’y a plus de Francais a voir, je vous encourage a prendre 7 minutes pour regarder l’interview que j’ai faite la semaine derniere de Guy Forget, sur son utilisation des nouvelles technos pour analyser les matches.)

Serieusement, je ne suis pas mecontent de ma visite. J’ai parle a des clients, qui ne sont pas necessairement ravis, pour diverses raisons. Certains ont pris de facon personnelle des remarques s’adressant a la majorite, et qui visiblement ne les concernaient pas. Mais c’est aussi interessant de voir de telles reactions face a des remarques quasiment anodines : on sent encore beaucoup d’animosite dans la relation entre architectes et partisans du developpement agile… Or chez ces derniers, comme Dave West, on tient a preciser qu’il faut absolument infuser, justement, des architectes, comme des mentors, pour guider les developpements et empecher le chaos tant redoute. En bref, meme s’il aime se moquer des gars de l’architecture - lui-meme venant du developpement - Dave West valorise leur savoir. De meme, Henri Peyret, analyste Forrester de la branche EA (Enterprise architecture), m’a confie qu’il conseillait aux architectes d’entreprise d’introduire du lean dans leurs methodes, de “ne pas rechercher ceinture et bretelles a chaque fois”.

L’interview complete de Dave West viendra sous peu. Enfin, le plus vite possible…

Que sera l’informatique en 2020 et le rôle de l’informaticien à cet horizon ? Chacun doit avoir son petit avis sur la question, mais évitera de répondre en se réfugiant derrière un "je suis pas madame Soleil". Nous avons pourtant été quatre cobayes, hier, à essayer de répondre à la question, lors d’une table ronde au salon Plein emploi (au Cnit de Paris La Défense).

Lire la suite…

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.

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.