J’avais fait l’impasse sur l’édition 2012, je suis revenu pour l’édition 2013. Cette année encore Agile France promettait un programme attrayant : promesse tenue ! Le “take away” de ces 2 jours de conférences ne rentre guère dans mon sac à dos, c’est un semi-remorque qu’il va me falloir. Une fois de plus, je vais vous distiller cela en plusieurs parties.

Place à l’action, ou plus précisément à la première session de la journée.

Peter Stevens : From Value to Values

Why management has to change and how IT is inspiring the solution

Nous étions quelques un à avoir eu l’occasion de croiser Peter Stevens lors d’une Scrum Beer il y a environ 2 ans. Cette fois, il nous faisait la keynote de la conférence et venait nous parler du Stoos Network. J’avais une première fois évoqué ce mouvement à l’annonce du Stoos Connect, puis plus récemment pour parler du Stoos Satellite Paris.

C’est bien du Stoos Network dont Peter Stevens est venu nous parler. Selon lui, le monde se divise en 2 types de sociétés:

• Celles qui enchantent leurs clients.
• Les autres.

Vu comme ça, c’est un peu simpliste. Creusons un peu. Aujourd’hui, les compagnies ayant un fort “focus client” sont celles qui gagnent de l’argent. Car il n’a jamais été aussi facile de changer de fournisseur ou de service. Votre service de téléphonie ne vous plait plus, résiliez-le dès aujourd’hui pour prendre un nouveau plan ! Il y a 30 ans, Peter Stevens nous confiait qu’en Suisse, un abonnement téléphonique nécessitait un dépot de garantie équivalent à un demi-mois de salaire ! Nous avons donc changé de logique :

• Autrefois : “you take what we make”.
• Aujourd’hui : “I choose what I want”.

Pour autant, ce changement de polarité ne s’est pas accompagné d’un changement de paradigme dans la logique de l’entreprise.

L’entreprise moderne continue de choisir son cap en fonction des dividendes qu’elle peut reverser à ses actionnaires. C’est une logique qui n’est en fait pas celle permettant d’obtenir les meilleurs résultats car elle part du mauvais point.

Pour enchanter le client, il faut augmenter la vitesse de réactivité, faire grandir la capacité d’innovation. L’économie d’aujourd’hui est une économie de la créativité. Toutes choses que le mode de fonctionnement “commande / contrôle” hérité du Taylorisme et du Fordisme ne permettent pas.

Il doit y avoir une meilleure façon de faire, c’est le constat que différents courants de pensée du réseau Stoos (radical management, tribal leadership, beyond budgeting, management 3.0, etc…). Et elle s’inspire de l’agilité.

Pour Peter Stevens, l’élément le plus important du manisfeste agile se situe en haut de celui-ci :

We are uncovering better ways of developing software by doing it and helping others do it.

Stoos Network est un “mouvement de mouvements” qui promeut l’entreprise non comme une structure pyramidale, mais comme un réseau “apprenant” de personnes, dont les managers seraient les servants.

Aujourd’hui, l’agilité dans les projets informatiques est confrontée à une frustration de par les conflits qui l’opposent à un management classique. Stoos est la continuité de ce mouvement vers l’organisation de l’entreprise.

Je n’ai pas trouvé la présentation de Peter Stevens, mais un support qui s’en approche de très près.

J’ai été un peu déçu par cette keynote. Bien que quelques exemples (visibles sur les supports) aient pu nous donner à réfléchir, elle est pas mal resté dans les généralités.

Géry Derbier : Le leader en tant qu’hôte

J’avais suivi de loin l’intérêt de Géry pour le host leadership, mais sans m’y intéresser plus avant, car on ne peut pas être partout, n’est-ce pas ? Mais Géry étant mon futur collègue, j’essaie de le pister un peu…

Déjà, ça commence par le coincer en face de mon objectif !

Cette session était en fait un atelier participatif. On parle toujours du “servant leadership” par opposition au “leader command & control”. Certes, mais comment cela peut-il se matérialiser ? Il y a-t-il des parallèles avec de choses que nous connaissons qui pourraient nous aider ?

Il se trouve que oui !

Que se passe-t-il quand nous participons à une fête que nous jugeons réussie, que fait l’hôte pour rendre cela possible ? C’est à ce travail de reflexion que nous a invité Gery aujourd’hui. Par petits groupes, nous avons cherché à décortiquer les ingrédients d’une fête réussie

Une reflexion pas très facile à mener en un temps limité. Je vous livre en vrac les points qui sont remontés :

• Favoriser l’émergence, laisser de la liberté pour permettre la créativité.
• Avoir une (des) réactions en chaine. A l’image de ce qui se passe quand on commence à danser.
• Créer le lien entre les personnes. C’est vrai surtout quand nombre d’entre elles ne se connaissent pas. C’est moins le cas dans des réunions de famille.
• Le pouvoir de l’invitation. On ne vient pas sous la contrainte, c’est un acte volontaire.
• Donner la permission, ou comme le dira Olivier Pezziardi “pas faire chier les gens”.
• Ne pas chercher à obtenir un résultat. On créé les conditions, le résultat vient en second.

Mais est-il possible de considérer un projet de la même manière ? Sommes-nous invités à nous joindre à un projet ? J’aurais tendance à répondre “oui”. En fait, cela se passe beaucoup dans la tête: nous sommes invités si nous avons envie de nous sentir l’être. Mais c’est juste un avis personnel. Je vous invite à lire le white paper accessible sur le site host leadership.

Cyrille Martraire : Code legacy : Faire évoluer ou réécrire ?

Cyrille est un adepte fervent du DDD et un membre actif de la communaute du software craftmnship. Aujourd’hui il vient évoquer avec nous les stratégies de travail sur le code hérité (legacy code). Cette présentation s’appuie sur un projet mené chez Sungard autour d’un système d’asset management. Nous parlons ici d’une application vieille de 20 ans lourde de 20 millions de lignes de code avec des procédures stockées, des EJB2, etc…

Mais qu’appelle-t-on “code legacy” ? Pour Michael Feathers, du code hérité n’a pas de tests. Si l’on se calque sur cette définition, du code hérité n’a pas besoin d’être vieux pour être considéré ainsi !

Alors, faire évoluer ou récrire ?

Il faut regarder les choses avec lucidité: espérer que tout soit “beau” un jour est illusoire. Ca n’arrive pas !

Le postulat de départ est donc : on garde tout ! Mais pour faire évoluer en gardant l’existant, il faut se munir de tests, d’une manière ou d’une autre. Comment faire ?

Je vous présente le “Software Testing Ice-Cream Antipattern” ! On commence par le haut: si on a rien, on fait des tests manuels. Puis on essaie d’automatiser les tests par l’IHM. Dès que le découpage en couches devient à peu près présentable, on passe à des tests d’intégration pour tester les API. Enfin quand le niveau de découplage interne le permet (le plus souvent jamais) on met en place des tests unitaires !

Bien sûr, c’est très coûteux, et l’orateur évalue le différentiel de vélocité de 1 à 4 par rapport à du code neuf écrit en TDD.

Et s’il faut réécrire, doit-on réécrire ?

Pas toujours. C’est la fameuse question du “make vs buy”. Si le processus métier habillé avec le logiciel est un différenciateur de l’entreprise, alors il faut faire ! Comment se différencier en pratiquant la même chose que les autres ? Si ce n’est pas différenciateur, alors il faut essayer d’acheter. Oui, mais le logiciel sur étagère ne corresponds pas exactement à ce que je fais … N’essayez pas d’adapter, même si l’éditeur dit que l’on peut, même si de nombreuses société qui sont prêtes à vous vendre du conseil disent que l’on peut (et qu’elles peuvent vous “aider”). Ou alors, faites-le à minima, faites votre possible pour plutôt adapter vos processus au logiciel. De toute façon, ce ne sont pas eux qui vous rendent différenciant, ce sont des centres de coût.

Visualiser

Il est bien rare que l’on doivent intervenir partout en même temps dans du code hérité. En fait cela concerne le plus souvent un volet précis de l’application : une phase de traitement, de nouveaux instruments financiers, etc…

La première étape que nous propose Cyrille est de visualiser le flux métier. A l’image de ce que l’on montre lorsque l’on construit une story map (là c’est moi). Il s’agit de donner de la structure. Sur celle-ci s’appuient des fonctions secondaires et des concepts. C’est le travail péparatoire qui va nous permettre de passer à la suite. Ce que Martin Fowler appelle l’Asset Capture.

A partir de là, il va falloir identifier le ou les assets concernés par l’évolution.

Comment intervenir

Quand on part d’un legacy à priori inconnu, il y a une démarche logique pour aborder la bête :

1. Lire la documentation
2. Interroger les anciens qui la connaisse peu ou prou.
3. Utiliser l’application.
4. Lire le code.
5. S’essayer dessus en fixant des bugs.

Le principe de base des évolutions, est de ne pas essayer de faire plusieurs choses en même temps. Il faut y aller prudemment, s’insérer dans l’existant même si on n’aime pas ce que l’on voit. Des conseils souvent prodigué dans les Reengineering Patterns.

Comment s’organiser

Comment pensez-vous procéder : en opérant une réécriture iso-fonctionnelle ? Sachez-le, personne ne paie pour cela.

Une réécriture s’accompagne toujours d’une certaine dose d’évolutions. Oubliez l’idée d’une équipe refonte constituée de pur techos, il va falloir une vrai équipe projet regroupant des compétences diversifiées (analystes, testeurs, etc…).

Maintenant il faut se mettre au boulot !

Strangler application

Le pattern préféré de Cyrille est le Strangler Application Pattern, lui aussi décrit par Martin Fowler. Comme son nom l’indique, ce pattern consiste à “étrangler” progressivement l’application existante en envoyant les traitements qui ont été réécrits vers la nouvelle application. Le point faible étant ce dispatching qui doit alors exister dans l’ancienne application, nécessitant un refactoring pas nécessairement négligeable… Les deux points clés de l’approche sont:

• Le décomissionement des concepts : on travaille concept par concept, et on switch complètement l’un d’entre-eux quand il est prêt dans la nouvelle application. C’est donc mieux quand les concepts sont assez atomiques.
• Le “feature toggle” qui doit permettre le basculement vers la nouvelle application. Attention, parfois cela se passe mal, il est alors souhaitable dans ce cas de pouvoir revenir en arrière.

Bubble context

Le développement de nouveaux concepts s’opère dans une “bulle” isolée des adhérences avec l’existant, du moins autant que faire se peut. C’est l’Autonomous Bubble Context décrit par Eric Evans.

Isolé du monde legacy, le développement s’opère comme un nouveau développement, en TDD & BDD. Entre l’ancien et le nouveau monde, une Anti-Corruption Layer isolée vers le haut par une API et par le base par une SPI, opère comme un sas entre les deux environnements.

Quelques points clés à ne pas oublier :

• Se faciliter la vie en ayant un certin niveau de mapping avant l’existant. On pense surtout ici au mapping avec la base de données.
• Décréter le “freeze” de l’existant : toute évolution doit s’opérer dans une Bubble Context. On touche seulement à l’existant pour opérer des renvois vers la bubble context.
• Ne pas oublier qu’une bulle n’a qu’un temps. Avec le passage du temps, elle-même deviendra du legacy à son tour un jour.

Pour résumer la stratégie de réécriture, l’orateur nous résume la chose :

Réécriture = Frontières clairement définies + stratégie d’étranglement + intégration minimale.

Je n’ai pas exactement le support que Cyrille a utilisé, mais un très proche. Le voici 

Lectures recommandées

Essentiellement 3 ouvrages à connaitre. Ils sont tous sur mes étagères mais n’ont pas encore fait l’objet d’une note de lecture publiée :

• Domain-Driven Design, par Eric Evans
  
• Object-Oriented Reengineering Patterns, par Serge Demeyer, Stéphane Ducasse & Oscar Nierstrasz
• Working Effectively with Legacy Code, de Michael Feathers
  

Vous pouvez également lire l’excellent retour de Vincent Uribe sur cette session, sur le blog Soat.

Break !

Le début de matinée a déjà été bien rempli. Il est temps de faire une pause. C’est une occasion pour reprendre contact avec les uns et les autres. On est là aussi pour ça.

C’est aussi la pause pour la publication de mon retour d’Agile France. Nous sommes agiles, on va faire tout ça de manière itérative, que diable ! Rendez-vous bientôt pour la suite de mes périgrinations agilistes.