Agile Grenoble 2011 : retours et réactions

Ce 24 novembre, j'ai pu assister à Agile Grenoble 2011. En voici quelques retours et réactions.

Session plénière

Bon, le classique d'un début de conférence, "le mot des organisateurs" et petit intervention d'un sponsor, pas grand chose à en dire ... Ah si ! Frédéric DUFAU-JOEL (et son collègue) nous parle(nt) de la mutation agile au sein du groupe SAMSE, de ci, de ça, et dans le lot :

"Les chefs de projets formés au rôle de Product Owner". 

Hein ? Comment ? Whaouuuuuu. C'est ce que je disais dans ce billet, je pense que souvent les chefs de projets font plutôt mieux des Product Ower que des ScrumMaster, s'ils connaissent bien le métier. La journée commençait bien !

"Les test intégrés sont une arnaque" par J. B. Rainsberger

J'avais plus ou moins choisi cette séance depuis quelques jours. Mais la veille, avec une trentaine de chanceux, nous avons passé une super journée à coder avec Jo, lors du "Legacy Code Retreat" organisé par le CARA. Du coup, j'ai foncé à cette session !

Joe est cool, sympa et barbu, mais sans en avoir l'air, il a un recul et une maturité passionnants sur le développement, le code, les tests, et le tout plein d'humour !

Joe a commencé par expliquer ce qu'il entend par "tests intégrés" à ne pas confondre avec les tests d'intégration. Ces derniers permettent de tester le lien entre notre code et un autre système ou une librairie extérieure. Les "tests intégrés" portent sur un sous-ensemble du système, un groupe de composants qui inter-agissent entre eux, mais pas sur tout le système. Rappel : les tests unitaires, plus "bas niveau", portent sur un seul composant. Mais pourquoi ces tests intégrés existent ?

Nous connaissons tous la situation suivante : les tests unitaires sont OK à 100% mais il y a des bugs. Ces derniers viennent des interactions entre objets, d'où l'idée du développeur de créer des tests pour couvrir ces interactions, ce sont les "tests intégrés".

Les tests unitaires apportent une "pression positive" sur la conception en me signalant les problèmes par des feedbacks immédiats. Ce qui n'est pas le cas des tests intégrés. Ces derniers entrainent une conception "sloppy" ("négligée"), entrainant des interactions compliquées, donc plus difficile à tester et donc amenant le développeur à créer moins de tests unitaires. Le début de la gangraine et ... de l'arnaque ! Alors que le développeur pensait bien faire ...

Le cercle est vicieux, plus de tests intégrés entrainent ... plus de tests intégrés (car moins de tests unitaires), le "virus" s'auto-réplique menant au "system heat death", la "mort du système par surchauffe" : le coût de maintien augemente exponentiellement et devient trop important.

Ensuite, Joe est rentré plus dans le détail et la technique, parlant des mocks, d'interface entre client et serveur, introduisant les notions de "expectations" (pour vérifier les interactions) et "stubs" (pour simuler les réponses) selon le sens testé pour l'interaction entre le client et l'interface, puis l'idée de "design by contract". Les problèmes d'intégrations sont alors dûs à des désaccord sur le contrat.

Il faut donc une cohérence entre les tests de collaboration de part et d'autre de l'interface, chaque test d'un côté doit avoir son pendant de l'autre. Aux "expectations" doivent correspondre des "actions", et aux "stubs" doivent correspondre des "expected result" : on parle alors de "tests de contrats".

Joe a fini rapidement avec un exemple de tests sur l'ArrayList et la LinkedList dérivant toutes les 2 de List, avec le souci de supprimer les duplications en remontant le code similaire dans la classe parente abstraite "ListTest", aboutissant à une couverture de cas maximale.

Cette présentation était vraiment super intéressante, surtout qu'il me faut maintenant explorer en détails toutes les notions présentées rapidement ci-dessus. A noter que Joe a fait une présentation sur "tableau papier" sans aucune note : chapeau et merci !

@xnopre 28/11/2011 : Oups, tellement évident mais tellement sympa : j'ai oublié de remercier Joe pour son effort de présentation en Français, comme la veille pour le Legacy Code Retreat, effort appréciable et discours impeccable ! Merci !

"Démonstration / Kata BDD sur un logiciel pilotant un instrument" par Matthieu Gironnet et Johanny Bergeron

L'objectif de cette session était de présenter le développement piloté par les tests d'acceptances exécutables sous forme de démo, avec un vrai système qui bouge.

Je dois admettre que les orateurs ne semblaient pas super à l'aise, mais c'est difficile et il faut bien commencer, bravo à eux.

La session était intéressante mais certains points en ont baissé la pertinence. Le permier point est un manque de précision sur les parties de système simulées ou non. Les orateurs ont expliqué ne pas utiliser le vrai logiciel complet mais un faux ("fake"). Hors, dans les démos, l'instrument bougeait. Ca a dû apporter de la confusion à pas mal de monde, d'ailleurs en fin de séance, quelqu'un a posé la question. Mon expérience des tests fonctionnels exécutables en environnement industriel, proche de celui-là, avec le développement de pilote, m'a permis d'extrapoler et de comprendre : ils utilisaient bien un "faux" système mais qui chargeait le "vrai" driver qu'ils ont développé et voulaient tester.

Le second point portait sur la présence du code de production. Le temps de session étant court, les orateurs ont mis le focus sur l'écriture des tests par le Product Owner (copié-collé un peu trop rapide empêchant de lire ces tests et donc de bien suivre) et le développement nécessaire côté fixture pour exploiter ces tests. Du coup, une fois ce dernier code écrit, les tests sont tout de suite passés au vert puisque le code de production était là : nouvelle confusion certainement ...

Sachant que ce mode de présentation "en live" est risqué et donc audacieux, c'est tout de même tout à l'honneur des orateurs d'avoir osé cette sesssion technique sommes toutes réussie !

Slam par UnDeuxGround

Après la pause déjeuner (mieux organisée et réussie que l'an dernier), les compères slameurs nous ont fait des mélanges d'actualités (Le Monde du jour même) et d'agilité (idées piochées ici et là dans les sessions). Sympa, de bonne qualité et distrayant !

"Maîtriser le legacy avec Mikado" par Johan Martinsson et Miguel Moquillon

Les intervenants ont attaqué par un sketch en enchaînant 4 "daily stand-up meetings" pour mettre en évidence des situations concrètes que nous avons tous vécues :

• "Analysis-Paralysis" : le développeur est bloqué, mais c'est pas grave, ça va pas durer !
• "Multiplication des modifications" : plein de modifications partout, apparition d'instabilités
• "Tunnel noir" : la découverte des problèmes au fur et à mesure, pas de visibilité, "encore 2 problèmes à régler mais c'est pas les mêmes que les 2 d'hier"
• "Grand merge" : la fusion est douloureuse

Les orateurs ont ensuite enchaîné par la refonte de code en direct, en utilisant une nouvelle méthode : Mikado. Une pause au bout de quelques minutes pour nous expliquer la méthode que nous étions en train de voir "en vrai", en expliquant le principe qui consiste à noter son objectif et de quelles tâches il dépend. Ces tâches peuvent parfois être traitée, ou sinon, en nécessiter d'autres que l'ont identifie sur le tas. Il est alors impératif de revenir en arrière, dans la dernière situation stable, avec de s'attaquer à ces nouvelles tâches "feuille", et ainsi de suite ... On construit alors le graphe Mikado.

Reprise du codage, que l'on comprend alors mieux, puis une nouvelle pause pour faire l'analogie avec le "vrai" jeu Mikado : on a alors sous les yeux, d'un côté un vrai jeu Mikado (les "baguettes") sur une table, vidéo-projeté sur l'écran de droite, et le graphe Mikado sur l'écran de gauche, et l'analogie saute aux yeux. D'un côté le mikado noir qu'il faut attraper, dessous, en voyant bien ce qu'il faut enlever d'abord. D'un autre, l'objectif final (ajouter une fonctionnalité) avec toutes les tâches qu'il faut traiter d'abord (pour l'instant ....).

Par rapport aux 4 situations présentées dans le sketch initial, les réponses de la méthode Mikado sont :

1. Une analyse en local du problème, avec la découverte petit à petit des problèmes grâce au fait d'envisager des solutions simplistes
2. Des modifications avec un stabilité permanente
3. Une phase exploratoire permettant une meilleure visibilité de la situation découverte au fur et à mesure
4. La possibilité de commits et merges fréquents pour une intégration progressive

Dans le total prolongement du "Legacy Code Retreat" de la veille, cette session m'a permis de bien comprendre l'intérêt évident de l'approche proposée par la méthode Mikado. En plus, la présentation était vivante, pleine d'humour, bien rythmée entre l'alternance de "direct" et d'explications, et surtout : du vrai code ! Yeah les artisans ! ;-) (à suvire dans un prochain article sur "Innovation Grenoble" ...)

Bravo et merci !

"Git au quotidien" par Guillaume Gardais et Laurent Tardif

Je connais Git que j'ai un peu utilisé, voir mon enthousiasme dans ce REX. Néanmoins, persuadé de l'intérêt et de l'avenir de Git, j'ai choisi cette session pour vérifier ce point de vue et éventuellement en apprendre un peu plus. Je n'ai pas été déçu !

Bien sûr, Git est l'avenir. Même si la session ne le fait pas ressortir, l'outils est présenté de façon attrayante (pleins de possibilités) mais peut-être effrayante (trop de possibilités). En effet, cette grande liberté nécessite la mise en place de règles pour l'utiliser de façon commune dans une même équipe.

Et pas déçu, car j'ai appris des choses, même si les commandes présentées étaient basiques. Les explications des orateurs sur les possibilités de repo local et de repo public par développeur, les possibilités d'échange 1 à 1 entre 2 développeurs, et, très intéressant, les possibilités de build automatique par le serveur d'intégration continue de mon propre code dès que je le rend public : super intéressant ! J'ai donc mieux compris ces concepts de bases que j'avais rapidement passés lors de ma mise en oeuvre de Git.

Là aussi, bravo et merci !

"Symphonie pour PHP industrialisé en agilité majeure" par Jonathan Bonzy, Marc Nazarian et Bernard Huguet

Depuis quelques temps, notamment suite à une mission en PHP, en tant que développeur Java (essentiellement), je me questionne sur l'avenir de ce langage. Surtout que bon nombre de structures mondiales l'ont choisi pour des applications utilisées par des millions d'utilisateurs dans le monde (pas besoin de donner d'exemples !). En plus, depuis la version 5, le langage s'est orienté vers l'objet, et l'outillage ne cesse de s'étoffer ces derniers mois (ou années ?), notamment pour les tests unitaires et autres outils pour du code propre et de qualité. C'est donc sans hésiter que j'ai choisi cette session parlant en plus d'industrialisation.

Ici encore, les 3 orateurs ont opté pour la mise en scène théatrale permettant d'avoir une séance vivante tout en faisant passer des messages importants sur base de comparaisons. Nous avions donc devant nous un Product Owner, avec un nouveau projet, sollicitant 2 développeurs ayant des approches très différentes mais faisant, bien sûr, au final, les bons choix ! A savoir :

• PHP pour le Web et la charge, 
• NetBeans comme IDE, 
• Symfony pour le framework et éviter de réinventer la roue, 
• PHPUnit + Behat + Selenium pour les tests à tous les niveaux, 
• Maven pour l'industrialisation, 
• et Jenkins pour l'intégration continue. 

Le tout est proposé dans un Boilerplate disponible sur internet pour permettre à chacun d'être rapidement opérationnel dans un environnement de qualité. Bravo les gars, je vais m'empresser de télécharger tout ça !

A noter au passage une remarque intéressante et très importante : les tests fonctionnels sont plus lents et plus difficiles à maintenir. Donc ne pas en abuser, bien respecter la pyramide des tests. A une époque où l'on parle de plus en plus de BDD, attention à l'effet de mode, il est bon de rappeler les limites. +1 !

La seconde partie de séance a continué par des revues de sprint toujours sous forme théatrale, permettant aux 3 compères de mettre en avant des points intéressants :

• un début de projet pas vraiment productif ("Hello world") mais permettant de mettre en place les outils pour une production de qualité, et le montrer au PO en lui expliquant
• une avancée itérative, progressive, avec une forte collaboration entre le PO et l'équipe, et bien sûr, une forte productivité en toute qualité (présence de tests, etc ...)
• la méfiance et la nécessité de ne pas s'emballer pour, par exemple, la reprise d'un projet existant, en commençant par vérifier le comportement de l'application par un dialogue fort avec le PO et la mise en place de tests, avant de commencer le moindre codage

J'ai vraiment jugé cette session de manière très positive, autant sur le fond que sur la forme qui permet de faire passer des messages importants. La mise à disposition d'un "pack" près à l'emploi est également une chouette initiative que je vais rapidement tester et évaluer, et qui ne peut que contribuer à promouvoir les valeurs de l'agilité, notamment autour de la qualité et des bonnes pratiques (même si ça ne fait pas tout).

Et là encore, bravo et merci !

Le diaporama était déjà en ligne ici, et le boilerplate est disponible sur github : cool et merci !

Conclusion

Finalement, je m'aperçois que j'ai surtout suivi le trac "technique", comme quoi ça me passionne, et je pense qu'il est important de ne pas mettre la technique de côté dans ce genre de manifestations. L'agilité ne peut pas se mettre en place dans une structure si la technique et les bonnes pratiques des développeurs ne suivent pas. Or, ce point est trop souvent négligé dans les migrations vers l'agilité, et c'est dommage, surtout si c'est pour aboutir à une réussite partielle voir un échec ...

Concernant le programme, je pense qu'il manque un trac pour les novices, pour présenter les idées et concepts de base de l'agilité, de Scrum, de l'ingénierie agile, etc ... C'est sûr, le niveau à Grenoble est élevé, tant côté orateurs que participants. Néanmois, le public est varié, et pour continuer à élargir la promotion de l'agilité, il me semble important d'en donner l'accès à tous, y compris les curieux qui n'y connaissent rien. A méditer ...

Et bien sûr, bravo et merci au CARA et à l'équipe pour l'organisation impeccable !

A suivre ici prochainement si tout va bien : d'autres retours sur cette semaine pleine d'agilité, notamment Grenoble Innovation ...