Encore un petit sujet sur l’amélioration de la qualité du code…

Il y a de petits efforts à faire qui ne coûtent pas cher pour alléger des codes et optimiser le fonctionnement des applications, mais encore faut-il, il est vrai, que le développeur ait un minimum d’outils à sa disposition. Chez Octo, on trouvait que de ce point de vue, dans le monde Java, aucun outil n’arrivait à la cheville de NDepend, analyseur de code .Net. Le cabinet a donc collaboré avec Patrick Smacchia, auteur de NDepend, pour en proposer une version Java, XDepend.

J’ai trouvé la démarche intéressante, et j’ai donc approfondi le sujet avec Marc-Antoine Garrigue, directeur de la R&D d’Octo Technology :
Lire la suite…

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…

LeMondeInformatique.fr a le plaisir de s’associer cette année à l’Université du SI , organisée par Octo Technology les 1er et 2 juillets prochains. Il semble que les papiers que j’avais écrits l’année dernière aient suscité un certain intérêt, notamment celui sur l’intervention de Michel Serres . En tant que partenaire presse, j’ai donc accès en amont aux intervenants de l’édition 2009. J’ai choisi de commencer avec Djamel Zouaoui, architecte senior d’Octo, qui animera avec son complice David Alia une session au titre alléchant : "Du RIA pour mon SI : Microsoft Silverlight VS Adobe Flex ". Si je pense comme lui que les RIA sont un sujet d’avenir (voilà un certain temps que je traite le sujet, d’ailleurs, et heureusement on commence à en parler davantage au présent qu’au futur !), je ne suis évidemment pas aussi catégorique sur les choix à effectuer. Mais après tout, place aux spécialistes !

Interview de Djamel Zouaoui, Architecte senior d’Octo Technology
Lire la suite…

J’ai assisté hier aux premières Assises du SI durable (et animé une table ronde par la même occasion), où les auteurs de l’ouvrage “Le SI durable” (chez Hermès Lavoisier) ont pu exposer leur vision, à rebrousse-poil des idées des grands fournisseurs, comme je le disais l’autre jour.

Pour le compte-rendu, vous pouvez le lire sur notre fil d’actualité ou sur notre section Forum SOA.

Et pour une meilleure compréhension des principes qui ont guidé les auteurs, voici un petit cadeau : l’article que j’avais écrit il y a un an et demi suite à ma rencontre avec Jean-Michel Detavernier. Difficile de retranscrire en quelques mots sont expérience et ses motivations - ceux qui l’ont vu en live savent combien l’homme est bavard et passionné - mais j’espère avoir réussi à synthétiser l’expérience de la SMABTP, et la façon dont ont été appliquées les bonnes pratiques des architectures orientées service (externalisation des données de référence et des règles métier, gros effort de modélisation amont, conception des services métier indépendamment des technologies d’infrastructure, cadre de développement pour à la fois contraindre et faciliter le travail des développeurs…).

L’article original est paru dans LMI (le magazine). Le voici pour vous, ci-dessous.

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.

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.