Mon retour sur Devoxx France 2014

Cette année, pour la première fois, je me suis payé Devoxx France. Voici mon retour sur ces 2 journées intenses et riches.

Un bon titre pour une bonne session TDD et coding-dojo

Introduction

Je me permets de solliciter la(les) communauté(s) pour recueillir des avis et propositions pour un titre de session.

La session

A l'automne, j'ai animé une session "L'apprentissage du TDD en Coding-dojo" lors des conférences agiles de Marseille, Montpellier et Grenoble. Cet atelier d'environ 2h me permet de présenter un peu de théorie sur les tests unitaires et le TDD, puis de faire une rapide démo live avant d’enchaîner sur un coding-dojo de type randori (donc sur un seul poste vidéo-projeté) pour permettre à une partie des participants de s'essayer, en pair-programming, au TDD pendant 5-6', sur un sujet simple, avec mes conseils, mes remarques et le soutien de l'assistance.

Mon retour sur Mix-IT 2013

Introduction

Les 25 et 26 avril 2013, j'ai participé à Mix-IT 2013, avec une particularité cette année puisque j'étais "speaker" : voici mon retour sur ces 2 journées de folie !

Human Talks Grenoble du 11 déc 2012

Introduction

Mardi dernier, 11 décembre 2012, j'ai assisté et participé en tant que "talkeur" aux Human Talks à Grenoble. En voici un petit retour.

Principe : Une rencontre autour de présentations de 10' par des développeurs pour des développeurs.

Pour notre soirée, il y avait 5 présentations au programme.

Ingénierie agile : n'oubliez pas vos développeurs

Avec un pied dans l'agilité et un dans le développement, je me penche depuis pas mal de temps sur les aspects techniques liés à l'agilité dans le domaine du développement logiciel.

Ma constatation est simple : dans les transitions agiles, les aspects techniques sont complètement oubliés.


Une entreprise qui veut réussir sa transformation va y mettre les moyens (formations et coaching), et par exemple pour Scrum, va tout bien mettre en place : choix minutieux du Product Owner et du Scrum Master, mise en place des supports (backlog, Scrum Board, graphes, post-its, niko-niko, ...), mise en place des cérémonies (planification, revue et démo, rétro), etc ...

Agile Grenoble et Agile Innovation 2012

Cette semaine, j'ai passé 2 superbes journées à Grenoble, pour Agile Grenoble 2012 et Agile Innovation 2012. En voici quelques éléments de retour.

Ce que j’ai aimé

• Des rencontres avec plein de personnes que je connais et qui me connaissent, et des discussions très intéressantes, merci !
• Des rencontres et échanges avec des personnes que je ne connaissais pas, les nouvelles rencontres sont évidemment indispensable et riches
• La session d'Alexis Monville et Bruno Sbille (voir ci-dessous)

Objectif Cloud avec l'AlpesJUG

Hier soir, j'ai réussi à m'organiser pour assister à une des soirées organisées par l'AlpesJUG. Les invités Nicolas De Loof et Paul Sandoz étaient venus nous parler .... cloud, c'était à ne pas manquer !


Après quelques rappels sur le cloud, les solutions IaaS, PaaS et SaaS (voir par exemple sur Wikipédia si ces termes ne vous disent rien), Nicolas nous a plus précisément parlé des solutions proposées par CloudBees, notamment :

• Run@Cloud qui offre un service de type PaaS, permettant d'exécuter une application WEB dans un serveur d'application
• Dev@Cloud qui offre un service plutôt SaaS, permettant d'héberger ses sources (Git, ...) et de construire ses projets (ordonnanceur Jenkins)

En 2^ième partie, Paul a présenté les projets CloudBees pour 2012, avec notamment plusieurs évolutions autour de Jenkins et des liens entre cloud public et cloud privé. La volonté de CloudBees pour 2012 est de "faire tomber les barrières" pour démystifier le cloud et y amener les acteurs ....

En fait, je connaissais CloudBees puisque j'ai une application hébergée chez eux depuis 2 ans, enfin avec un démarrage chez Stax Networks qui a été racheté par CloudBees. En effet, en 2010, j'ai développé une application qui devait être accessible par plusieurs utilisateurs via internet. J'ai naturellement cherché un hébergé à la hauteur de mes moyens financiers pour ce projet : aucun ! L'application étant développée avec Play! framework (mince, toujours pas écrit mon article ...), j'ai cherché du côté de la communauté, et Stax m'avait été indiqué sur le forum de Play!.

Pour moi, il n'y avait pas d'alternative. D'ailleurs, je garde et propose cette approche dans bon nombre de situations. L'application mentionnée précédemment est à usage privé, mais devrait s'ouvrir à d'autres groupes d'utilisateurs, et la solution restera "cloud" ! Récemment, pour un nouveau projet, j'ai encore proposé une solution de type SaaS, avec création d'espaces privés pour chaque utilisateur, les avantages d'une telle solution sont tellement nombreux que je n'y vois pas beaucoup d'autres alternatives.

Ce qui me frappe c'est à quel point "le cloud" semble faire peur ou semble mystérieux ... Et pourtant, les solutions de type SaaS sont de plus en plus nombreuses et répandues, mais sans forcément afficher l'étiquette "cloud" : c'est le cas pour GMail, ce blog, les réseaux sociaux, etc ... Finalement, petit à petit et sans s'en rendre compte, tout le monde profite du cloud !

Bon, bien sûr, il y a différents niveaux d'approches. Mon application mentionnée plus haut est en quelques sortes simplement hébergée sur internet, comme une appli PHP chez Free il y a 10 ans (15 ? ah bon, déjà ...), elle n'est pas "scalable" pour que les traitements et les données puissent être répartis sur plusieurs instances de serveurs à la volée, mais c'est bel et bien une première étape vers le cloud, non ?

Pour revenir à CloudBees, je n'ai pas encore utilisé Dev@Cloud, mais j'ai évidemment regardé et suivi cette offre, en attendant une opportunité pour tester.

Mais c'est sûr, le cloud va prendre de plus en plus de place dans notre monde de développement logiciel, il va falloir s'y adapter, revoir nos habitudes, s'ouvrir l'esprit, et certains prestataires comme CloudBees font beaucoup pour nous faciliter la transition !

Merci aux intervenants, à l'AlpesJUG pour cette bonne soirée, et aux chauffeurs de voiture pour les covoiturages !

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

Agile Tour Marseille 2011 (retour)

Le 13 octobre dernier, j'ai assisté et participé à l'Agile Tour Marseille 2011, en voici un petit retour, selon quelques prises de notes que j'ai pu faire.

Un document agile se promène un fil - Jean-François Jagodzinski

J'ai choisi cette session pour avoir l'approche de JF sur la documentation en contexte agile.

JF commence par dresser l'approche "classique" où la documentation est au centre du système, entre "Information", "Process" et "Travail". Intéressant de noter qu'il peut se passer des mois de "travail", permettant de produire de la documentation mais ... aucun produit : bonjour le ROI !

J'ai bien aimé la vision en cascade du cycle de vie d'une documentation de type spécification : collecte du besoin, analyse, conception, puis réalisation. JF plaque sur ce schéma le fait que, dans la réalité, les individus vont osciller entre ces différents états. Par exemple, dans la phase de collecte ou d'analyse, il est fréquent de faire un aller-retour vers l'état plus technique (réalisation par exemple) pour vérifier la faisabilité. De même, dans les phases de conception ou réalisation, il n'est pas rare de revenir vers l'état de collecte pour approfondir le besoin. Ajoutons à cela que chacun oscille différemment, et c'est l'anarchie, l'incompréhension, le déphasage, .... l'échec.

D'où l'idée en agilité de favoriser les échanges entre individus pour exploiter positivement ces oscillations ...

J'ai noté en vrac :

• Le travail peut être du plaisir (j'aime !)
• Il faut éviter le filtrage de l'information, d'où l'idée en contexte agile que l'équipe soit en contact direct avec la source pour faire son propre tri de l'information utile
• La documentation doit avoir de la valeur métier, doit prendre moins de temps et moins d'espace
• Favoriser l'accès et l'utilisabilité de la documentation, ainsi qu'une saisie rapide et facile, et une gestion minimum (exemple : Wiki bien sûr !)

JF est ensuite passé à une représentation intéressante de la documentation en contexte agile, avec tous les éléments la constituant : la vision, le product backlog, les conditions de satisfaction, les contenus d'itération, les spécifications exécutables, les tickets, etc ... L'idée suivante m'a beaucoup plu : il est possible à partir de ces éléments de reconstituer intégralement une documentation "classique" (planning, specs, PAQ, etc ...). Et oui, on a tout mais sous une forme différente !

Un membre de l'auditoire a posé des questions sur le planning, en expliquant qu'en méthode classique, grâce à son planning, il sait qu'il aura telle fonctionnalité au mois de mars. Pour moi, c'est un leur, tout comme un contrat au forfait en mode classique : un leur je vous dis ! Mais j'y reviendrai dans un prochain article ... Mais pour moi, un planning est prévisionnel mais jamais prédictif ....

Session intéressante, une approche différente et transversale de tous les éléments de l'agilité et de Scrum, au travers de la documentation.

"Marshmallow challenge" - Pablo Pernot

L'intitulé de la session de Pablo ne laissait pas entrevoir ce jeu, je ne sais pas pourquoi : "Planification et itération : itérations, redéfinition, équipe hétérogène". Mais bon, peu avant les sessions, j'ai su qu'il s'agissait d'un "Marshmallow challenge". J'ai donc choisi cette session car je n'ai jamais assisté à des jeux à objectifs pédagogiques pour l'agilité (à part le "Scrum Tower Game" que j'ai mis au point pour ma journée d'introduction "Agilité et Scrum").

Je n'ai pas été déçu. Pablo a la pêche ! Et c'est tant mieux, ça se prête bien au contexte.

Je ne reviens pas sur le jeu pour lequel on peut trouver plein d'informations sur le site http://marshmallowchallenge.com/. Ce qui est intéressant c'est qu'il a été joué par des milliers de personnes, et donc qu'il existe des statistiques très intéressantes dont Pablo nous a donné un aperçu : les enfants réussissent mieux que la moyenne, les équipes hétérogènes en profils réussissent également mieux, etc ...

Tout comme pour ma session (voir ci-dessous), je pense que l'intérêt dans une telle conférence mais pas tant l'intérêt pédagogique du jeu, mais plus sa découverte pour le mettre en pratique. Pablo m'a semblé surpris, voir déçu peut-être, des conclusions qui pouvaient être tirées de cette session. Mais pour moi, le contexte n'est pas comparable à celui d'une entreprise où un coach intervient, le public présent est très différent avec des attentes tout autres.

J'ai donné un ROTI de 5 à Pablo car je n'ai vraiment pas perdu mon temps, j'ai pu voir une façon de mettre en place et animer cet atelier, ça m'a donné envie de creuser ce jeu pour peut-être l'utiliser dans mes propres interventions.

Coding-dojo ou l'apprentissage du TDD - Xavier Nopre

Franchement, je ne me sentais pas les épaules pour être "orateur" dans une conférence. Mais finalement, grâce à la convergence de différents éléments, je me suis lancé, j'ai proposé une session "Coding-dojo et TDD" qui a été retenue.

C'est une animation que j'ai fait plusieurs fois en entreprise, mais là, le contexte était différent : les gens ne se connaissent pas, ils ne sont pas censés tous participer, ils ont probablement des niveaux très différents (plus qu'au sein d'une même entreprise).

Ce qui me faisait donc presque le plus soucis était la façon de faire passer les personnes au clavier. En entreprise, je mets tous les noms sur des papiers dans un chapeau et on tire au sort. Là, j'ai laissé faire, et ça a bien fonctionné, il ne m'a manqué personne durant la session.

Public varié ? Oh que oui ! Entre ceux qui ne connaissent pas le TDD et celui qui ne fait que ça depuis 7 ans ! Mais également sur les capacités de développement, d'improvisation, de frappe, d'expression, etc ... Sans compter qu'en passant devant les autres, on perd pas mal de ses moyens. Mais tout cela était très riche.

Il y avait également la question du choix des sujets. Le sujet doit être simple et très abordable pour les participants pour garder le focus sur l'objectif pédagogique (par exemple, le TDD) et éviter de perdre du temps dans des recherches algorithmiques ou autres. J'avais pensé que le public serait hétérogène mais d'un niveau minimum, surtout s'il venait à cette session, et ça a été le cas, apparemment, les sujets n'ont pas posé de problèmes, nous avons pu mettre l'accent sur le TDD.

Un autre point que j'ai pu vérifier (après l'avoir vérifié la veille en entreprise) : le coding-dojo est accessible à tous, quelque que soit le langage, quelque soit le profil. Pour le langage, certains sont passés au clavier en ne connaissant que le C et ils ont codé en Java sans problèmes apparemment, avec l'aide de l'assistance, nous sommes bien dans un travail collectif. Mais ceci s'est également vérifié pour les profils, certains n'étaient visiblement pas ou plus trop "technique" (comme par exemple un chargé de recrutement), et eux aussi ont pu s'essayer sans problème à prendre leur tour de rôle au clavier.

Au final, les retours sont très positifs, ça fait plaisir. Surtout que c'était réciproque, j'ai moi aussi eu grand plaisir à expliquer et montrer ce qu'est un coding-dojo, et en guise d'exemple, le TDD et la vision que j'en ai. Donc, un grand merci à Karine pour sa stimulation et ses bons conseils, aux participants à ma session qui ont bien joué le jeu, à toute l'équipe d'organisation pour ce bon moment, ainsi que le repas entre orateurs. Bravo !

Retour Agile Grenoble 2010

Mardi 23 novembre 2010, j'ai assisté à Agile Grenoble 2010 organisé par le CARA. La journée s'est déroulée à guichet fermé avec 450 participants ! En voici un petit retour avec les points forts que j'ai noté et mes réactions.

Après un accueil efficace et sympa autour d'un café et de viennoiseries, la journée a débuté dans l'amphi par une keynote de Claude Aubry, suivie par 2 créneaux de 1h pour des sessions 7 sessions en parallèle. Après le déjeuner, une keynote de Aslak Hellesoy, suivie de 3 créneaux de sessions.

Mon programme de la journée a donc été le suivant :

• Matin :
• Keynote : Claude Aubry : Le petit Scrum illustré
• Adoption d’Extreme Programming à Kelkoo
• Atelier Story Map, là où tout commence...
• Après-midi :
• Keynote : Aslak Hellesoy : Les nouvelles tendances de l'agilité 
• TDD et Legacy
• Kata Robozzle en Haskell
• Exigences Exécutables Efficaces : "Doing the Right Software"

Ami lecteur, n'hésite pas à me contacter ou laisser un commentaire (remarque, question, correction, etc ...), je souhaite réellement pouvoir échanger sur ces sujets !

Keynote : Claude Aubry : Le petit Scrum illustré

Après une introduction et une présentation, Claude a articulé son intervention sur 9 pratiques de Scrum. J'ai bien aimé cette organisation qui permet de résumer l'agilité et Scrum, ce qui n'est pas toujours facile lorsqu'on veut présenter ces concepts à un novice. De plus, cette approche permet de couvrir de nombreux aspects drainés par l'agilité. Voici ces 9 pratiques :

• Itératif et incrémental
  Des sprints de 2-3 semaines, un rythme soutenable, une implication de toutes les activités, la notion d'incrément, sans oublier de céléber !
• Un représentant du client dans l'équipe
  Point souvent négligé. Un Product Owner par produit, et qui soit disponible et réactif
• Une équipe auto-organisée
  Le Scrum Master ne dirige pas mais facilite, les post-its améliorent la communication et augmentent la gestion collective, éviter les doublons d'outils (ex : post-its + logiciel de suivi)
• Une liste unique de choses à faire
  C'est évidemment le backlog, qui doit impérativement être priorisé, les items étant décomposés au fur et à mesure que leurs priorités augmentent (i.e. qu'ils "montent" dans le backlog)
• Un planification à 2 niveaux
• Le Plan de Release :
  Le Planning Pocker permet de mieux comprendre et communiquer, les estimations doivent être collectives, en points relatifs, elles sont souvent difficiles, ce n'est pas une science exact
• Le Plan de Sprint :
  Les histoires sont découpées en tâches, l'équipe s'engage, il faut "garder du mou" pour pouvoir réagir aux changements
• Un point quotidien
  Également appelé Daily Standup Meeting, doit être rapide et efficace, le burndown chart permet de suivre le "reste à faire" et donc la tendance du projet
• Une démo pour la revue
  Permet un feedback rapide et l'estimation de la vélocité. Cette dernière n'est pas une mesure individuelle de productivité, elle n'est pas censée augmenter tout le temps, et sert à planifier (la suite)
• Une amélioration continue
  Grâce notamment aux rétrospectives
• Finir les choses avec qualité
  Bien définir les critères de fin (Done), notion de dette technique

En marge, Claude a évoqué l' "Esprit rock" pour imager la capacité à dire "non".

Il a également précisé un point intéressant qui est que le backlog d'un produit n'est jamais vide. Il en découle un point fort : c'est la date de fin du projet qui est fixe ! Cette approche me semble très importante !!

Claude conclue sur le fait que Scrum est un cadre, que cette approche ne garantie pas le succès d'un projet, et qu'il faut compléter notamment par de l'ingénierie agile.

Une phrase retenue : L'agilité est un voyage, un apprentissage permanent...

Adoption d’Extreme Programming à Kelkoo

Par : Johan Martinsson, Kevin Creix et Jonathan Bonzy

Pourquoi cette session ? : parce que j'avais rencontré des personnes travaillant à Kelkoo, j'avais donc entendu parler de leur approche de l'agilité et de XP, et que j'étais intéressé pour avoir un retour de mise en œuvre pour compléter mes expériences personnelles.

Les présentateurs ont fait un rapide rappel sur XP et quelques pratiques, notamment le TDD et le BDD (composé de plusieurs cycles de TDD). Ils ont expliqué les raisons ayant motivé le passage à XP (remettre de la confiance dans les équipes de développements, diminuer le cout des bugs, et profiter d'un CEO convaincu), et ont présenté la stratégie (proof of concept sur 1 projet + formations + recrutements de personnes expérimentées).

Ensuite, la présentation a été axées sur l'évolution chronologique au sein de l'entreprise. J'ai noté les points intéressants suivants :

• Début par un état des lieux. Peu de TDD, un peu de tests unitaires sur les parties faciles
• Ce qui aide : présence d'un évangéliste, TDD en sa présence, pair-programming
• Le BDD a donné de meilleurs résultats malgré un cout d'entrée important
• Ne pas brader la qualité pour rattraper le retard (ça ne marche pas !)
• "Lottery learning" : un nouveau concept pour moi, a l'air très intéressant, à creuser !!
• Être attentif pour repérer les maillons faibles dans la chaine de production (ex : les scripts)
• Difficultés "classiques" : PO distant (Londres), réunion trop longues, etc ...
• Amélioration des revues avec une démo faite par le PO : intéressant ...
• Observations actuelles : trop de BDD et tests trop longs, et pas assez de tests unitaires "bas niveaux" : image de la pyramide avec beaucoup de TU à la base et moins de TF vers le haut (et non l'inverse)
• Constat : seulement 50% de TDD et 50% de "tests after" : solution : pair "ying-yang" (complémentaires et niveaux différents)

Pour conclure, les présentateurs nous ont donné les différents points de vues des managers, des équipiers, et des présentateurs eux-même. Points retenus :

• Les managers sont rassurés : code testé, documenté, plus de compétences dans l'équipe, motivation, time to market
• Grand intérêt pour le pair-programming qui coute mais présente de nombreux aspects positifs : moins de blocages des développeurs, formations, échanges de compétences, ...
• Les freins avancés par les développeurs : manque de pratique, code legacy, pression de livrer
• Néanmoins, 2/3 des développeurs rapportent que ces approches sont efficaces en ~ 2 mois

Je retiens qu'une telle migration est favorisée par :

• Un message clair (et expliqué)
• Le soutien du business, des managers, des PO
• La présence de personnes expérimentées, capable d'évangéliser et d'aider au quotidien, notamment par le pair-programming

La session s'est terminée par la proposition par les présentateurs de faire des petits groupes pour échanger autour de questions/réponses avec des membres de Kelkoo. Cette initiative est intéressante, mais sa mise en place pratique, dans une petite salle pleine de 50 personnes, n'a pas été facile ...

Pour conclure, une présentation bien préparée, très intéressante, vivante notamment par l'alternance entre 3 présentateurs, et un contenu avec de nombreux points à retenir !

Atelier Story Map, là où tout commence...

Par : Olivier Pizzato et Emmanuel Etasse

Pourquoi cette session ? : J'avais eu un aperçu de Story Map lors de ma formation de Scrum Master, ça m'avait interpellé et semblé efficace pour le démarrage d'un projet qui est cruciale et doit être réussit !

La session a débuté par une présentation rapide de la Story Map :

• Objectif : avec tous les acteurs, définir les fonctionnalités essentielles
• Principales étapes :
• Partager la vision du produit
• Lister les acteurs et leurs besoins
• Lister les activités
• Lister les cas d'utilisation, les fonctionnalités
• Répartition sur un "graphe" temps/confort
• Grouper par lots
• Vérifier l'ensemble et trouver le chemin critique (le + difficile)
• Format interactif géré par des boites de temps

La suite de la session s'est déroulée par une mise en pratique, les présentateurs ont proposé de faire 4 groupes de 4 personnes, les autres participants pouvant observer. J'ai été un peu déçu par cette partie, car là encore, nous étions environ 50 personnes dans une petite salle. La proposition d'une mise en pratique est certainement excellente pour bien comprendre le principe, le tester et l'éprouver, mais peut-être pas adaptée à un tel effectif et à ce contexte.

Néanmoins, les présentateurs étaient disponibles pour échanger et répondre aux questions. J'ai noté chez les participants la difficulté pour faire la distinction entre activités et cas d'utilisation, ainsi que pour établir et maintenir les liens avec les acteurs. L'approche présentée ici était finalement assez différente de celle que j'avais expérimenté 1 an auparavant, comme quoi les outils peuvent et doivent être adaptés à ses besoins.

Keynote : Aslak Hellesoy : Les nouvelles tendances de l'agilité

Aslak est sympa, attachant, et, norvégien d'origine, parle très bien le Français ! Son intervention sur les nouvelles tendances de l'agilité était très intéressante, mais très difficile à retranscrire ici ...

J'ai noté ses remarques sur le business qui est fait autour et avec l'agilité, notamment les certifications et certains organismes dont le but, maintenant, semble être de gagner de l'argent ...

Plus concrètement, Aslak a évoqué le découpage d'un produit en histoire et l'importance de toujours préciser le pourquoi, ainsi que la définition du "fini" (Done, encore une fois) ! Également, l'importance des critères d'acceptation, et les tests d'acceptation (Cucumber par exemple, dont Aslak est à l'origine).

Il a également évoqué l'approche Outside in qu'il traduit par Verlan (je vous passe les détails ;-) ....) avec l'idée de partir de l'IHM.

Aslak a prôné l'abandon des métriques absurdes.

Pour les délais, il nous a présenté la loi de Little, imagée par les graphes CFD (Cumulative Flow Diagram) qui permettent de bien visualiser l'avancement pour chaque étape. Un tel graphe met en évidence que le délai pour la réalisation d'une histoire est en lien direct avec le nombre d'histoires en attente et en cours, d'où l'idée de travail à flux plus tendu et l'approche Kanban.

Aslak a terminé son intervention avec quelques références au mouvement DevOps ...

TDD et Legacy

Par : Bernard Huguet, Luc Jeanniard, Cyrille Roy et Johan Martinsson

Pourquoi cette session ? : Le TDD est évident et relativement facile sur du code neuf, mais reprendre du vieux code est toujours une affaire compliquée, j'étais intéressé pour avoir de nouveaux points de vue sur ce sujet, et les confronter à mes expériences dans ce domaine.

Après de rapides rappels sur le TDD, les présentateurs ont montré par l'exemple comment reprendre du code Legacy pour :

• Corriger un bug
• Ajouter une fonctionnalité

Cette session m'a semblé évidente, même si le code à reprendre (développé spécifiquement pour la présentation) n'était pas si "horrible" que ça : j'ai vraiment connu pire et beaucoup plus compliqué à reprendre.

Les présentateurs ont bien montré l'intérêt du TDD, que ce soit pour l'ajout d'une nouvelle fonctionnalité ou la correction d'un bug (que j'appelle TDC, Test Driven Correction, Correction Pilotée par les Tests). Ils ont également bien insisté sur la phase Refactoring, la phase bleu, dans le cycle TDD, phase très importante et souvent négligée.

La présentation était bien ficelée, vivante (notamment grâce à l'alternance entre les présentateurs, et l'alternance entre diaporama et code), et assez didactique. Les niveaux des participants étant extrêmement différents, il n'est évidemment pas facile de faire une présentation pour tous, et celle-ci en aura certainement interpellé plus d'un, et peut-être convaincu quelques-uns, pourquoi pas ? Moi, je l'étais déjà ... ;-) ... TDD sur du code legacy, c'est toujours possible !

Kata Robozzle en Haskell

Par : Emmanuel Gaillot

Pourquoi cette session ? : ces dernières semaines, lors de différentes rencontres, j'ai entendu parler de Haskell à 2 reprises. J'avais déjà regardé un peu sur internet cette notion totalement inconnue pour moi de "langages fonctionnels". Je voulais donc en savoir plus, et une approche par la pratique me tentait bien !

Haskel, c'est quoi ? C'est un langage de programmation fonctionnelle. Ça ne vous avance pas ? Voici ce que nous précise Wikipedia :

Les fonctionnalités les plus intéressantes de Haskell sont le support des fonctions récursives, l'inférence de types, les listes en compréhension et l'évaluation paresseuse. Ces fonctionnalités, surtout si on les combine, facilitent l'écriture des fonctions.

Et oui, c'est un autre monde !

Pour sa présentation, Emmanuel est parti du jeu Robozzle, qui consiste, en résumé, à définir une suite d'actions de déplacements pour un vaisseau sur une grille (avancer, tourner à gaucher, tourner à droite) pour passer, en un minimum de coups, par des points précis (étoiles). Emmanuel a proposé de s'intéresser plus particulièrement au moteur du jeu, permettant de vérifier si le joueur a gagné, à partir de la position des étoiles et de la séquence d'actions proposées, représentées par des lettres ("a" pour avancer, "d" pour tourner à droite, etc ...).

Emmanuel a été assez pédagogue, en expliquant bien l'enchainement de ses approches, de ses raisonnements, de ses étapes, du code écrit puis ré-écrit, puis simplifié, etc ... Globalement, j'ai réussit à suivre, mais j'avoue avoir frôlé le mal de tête ... Je trouve que le code final est assez illisible. Ça va peut-être mieux avec une meilleure maitrise des concepts et du langage, ça semble très puissant, mais ..... Wouf !

Je crois ne pas être assez mathématicien et logicien ... mais j'en connais qui seront intéressés ... ;-)

Conclusion : une présentation intéressante, bien organisée (la forme Kata s'y prête bien), et qui me permet d'avancer (un peu) sur le sujet (dommage que Emmanuel ait manqué de quelques minutes pour finir sa dernière fonction et donc l'algorithme entier).

Exigences Exécutables Efficaces : "Doing the Right Software"

Par : Bruno Orsier et Remy Sanlaville

Pourquoi cette session ? : les exigences ou spécifications exécutables est un sujet qui m'intéresse parmi tous les outils de l'ingénierie agile, et c'est encore une partie que je ne maitrise pas au mieux. Une présentation concrète et axée surtout sur la méthode me semblait donc intéressante.

La session a débuté par quelques rappels, et notamment l'opposition intéressante entre contractualisation (méthodes classiques) et collaboration (méthodes agiles).

Ensuite, Bruno et Rémy nous ont fait une présentation alternant explications et petites scène théâtrales, scènes jouées 2 fois, pour l'approche classique puis l'approche agile. Trois scènes pour 3 thèmes différents :

• L'incompréhension, notamment fonctionnelle, entre ce que le client veut et ce qui est réalisé
• Dans l'arène du code, pour obtenir un code propre et compréhensible, avec un développement piloté par les exigences, le tout en évitant les régressions
• L'effet tunnel ou les alternatives permettant à tous un meilleur suivi de l'avancement

Pour chaque scène, Bruno et Rémy ont mis en avant les avantages des méthodes agiles, et plus précisément l'approche basée sur les exigences exécutables.

Je m'attendais à une session plus orientée pratique avec l'utilisation d'un ou plusieurs outils. Mais finalement, le choix de mettre en avant les méthodes est très intéressant. Je n'avais pas besoin d'être convaincu, mais ça fait toujours de bien de voir et revoir les avantages des approches agiles et de leurs différents outils. De plus, je vois un peu mieux comment "vendre" ces approches au client ou à l'utilisateur, les arguments à mettre en avant, etc ...

La présentation était extrêmement vivante, avec une alternance entre diaporama, simulation de séance de travail, et surtout, des petites scènes théâtrales très bien jouées et pleines d'humour, de quoi bien faire passer le message. J'ai passé un très bon moment, idéal pour une fin de journée : Bravo !!!

Conclusion

Une journée bien remplie, très enrichissante, un beau programme, des sessions intéressantes et bien préparées, des intervenants de qualité, des rencontres et discussions à poursuivre, .... bref, un ROTI positif !

Mais comme pour l'Agile Tour à Marseille,je reviens un peu déçu de ne pas en avoir appris plus. Mais le côté positif, c'est que je dois commencer à bien intégrer l'approche agile, ses valeurs, ses concepts, etc ...

Je retiens tout de même que l'agilité est en mouvement, en mutation, qu'elle s'adapte (le propre de l'agilité), qu'elle a encore du chemin à faire, mais que son infiltration au sein des mœurs, des pratiques et des organismes est en bonne voie, et que son extension est favorisée par des moyens simples : un minimum de personnes convaincues, des acteurs expérimentés et capables d'évangéliser, des pratiques au quotidien permettant les échanges, l'auto-formation, l'expérimentation, etc ...

Merci aux organisateurs et aux présentateurs pour cette bonne journée.
Merci à Xavier pour le covoiturage.

Retour Agile Tour Marseille

Jeudi 14 octobre 2010 avait lieu, à Marseille, une étape de l'Agile Tour (http://www.agiletour.com/fr/node/964).

Le programme (http://wiki.agiletour.org/files/Marseille/AT2010ProgrammeMarseille.pdf) proposait 3 séries de conférences en parallèle. Toujours difficile de choisir, et un peu frustrant : au final, on aimerait pouvoir en suivre plus ...

J'espère que les diaporamas seront mis en ligne, que je puisse me replonger dans chaque exposé (certains le sont déjà sur http://www.esprit-agile.com/). En attendant, je vous mets ici quelques points forts retenus, et quelques réactions personnelles.

Bonnes et mauvaises pratiques du daily meeting - Céline Stauder

J'ai choisit cette présentation, car en tant que Scrum Master, je considère le Daily (standup) Meeting comme un des points importants de la réussite de Scrum, mais également une étape pas si facile à réussir au quotidien ...

Pour commencer, Céline a rappelé quelques éléments clé pour le daily meeting : pour les pigs (= ceux qui sont impliqués dans le sprint), 15' max et timeboxé, les 3 questions, etc ... J'aime bien le concept Par l'équipe pour l'équipe qui me semble très important.

Ensuite, Céline a donné quelques conseils d'organisation auxquels j'adhère :

• rester debout pour éviter que ça ne dure, 
• mettre des sonneries (à 10 et 15'), 
• couper court aux discussions de problèmes de fond et les reporter à un autre moment de la journée (planifier une réunion si nécessaire), 
• toujours le même lieu et le même horaire, 
• plutôt en début de journée, 
• commencer à l'heure, 
• équipe intégralement présente (s'organiser pour avoir des infos concernant les absents), 
• se mettre en cercle avec le SM à l'extérieur, 
• organiser le tour de parole, 
• personne n'est avec un ordi ou à son poste de travail, 
• se regrouper devant le Scrum Board, 
• mettre en avant les questions 2 et 3, 
• présence du PO souhaitable (mais sans interventions spontanées !), 
• etc ...

J'adhère moins à certaines idées ou pratiques, comme les pénalités pour les retardataires. Mais bon, ça doit dépendre de l'équipe, de son implication et sa motivation, et je n'ai jamais eu ce genre de problème ...

Lors de questions, Céline a évoqué des tâches d'une durée de 1 à 2h max ... Personnellement, par expérience, je m'étais plutôt orienté vers de tâches de quelques heures à 2 jours maxi. Je comprends l'idée de tâches courtes de 2h, permettant d'avoir un rythme motivant, une bonne visualisation de l'avancement, etc ... Par contre, je trouve que le temps nécessaire à un tel découpage est souvent excessif, avec souvent, au final,  un découpage maladroit et inefficace. Mais là encore, c'est probablement lié au contexte métier, à l'équipe, à son rodage des pratiques agiles, etc ...

Concernant les questions, j'aime bien l'idée de changer les libellés en intégrant un lien avec le done (terminé) :

1. Qu'est-ce que tu as terminé hier ?
2. Qu'est-ce que tu vas terminer aujourd'hui ?

Cela me semble très intéressant pour la 1ère question, mais un peu moins pour la seconde. Selon la taille des tâches, une personne peut prévoir d'attaquer une tâche qui ne sera pas finie aujourd'hui, mais c'est intéressant de le savoir et de le mentionner. Donc peut-être rester sur la question classique : Qu'est-ce que tu vas faire aujourd'hui ? ...

Une autre idée que j'ai noté est la suivante. Lorsqu'une tâche est terminée, l'équipier la déplace sur la droite de la colonne "en cours", en la laissant dans cette colonne. Ainsi, on peut déplacer les post-its lors du daily meeting dans la colonne "Fait". Par contre, l'équipe est parfois intéressée pour avoir un workflow plus détaillé pour les tâches, avec notamment des colonnes "à vérifier", "à réceptionner (PO)", etc ... Dans ce cas, il peut être dommage de "ralentir" le cycle de vide des tâches en attendant le daily meeting pour les faire avancer. Encore une fois, ce sont certainement des idées à retenir et à proposer à l'équipe qui choisira le mode qui lui covient le mieux !

Concernant la 3ième question et les points bloquants, on rappelle que rendre les problèmes visibles, au plus tôt, est un des objectifs de Scrum. Céline propose 2 choses intéressantes :

• sur le Scrum Board, avoir une case "problème" pour pouvoir y mettre des post-its à évoquer lors du daily meeting
• par contre, lors du tour de parole, éviter de s'attarder sur ces problèmes : pour cela, se mettre rapidement d'accord sur un lieu, une heure et les personnes à réunir pour en parler

Ensuite, Céline a évoqué les signaux d'alerte montrant un dysfonctionnement du daily meeting et de Scrum en général (indispensable à identifier pour s'améliorer) :

• les participants parlent au Scrum Master
• trop longues discussions sur les problèmes
• intervention du PO ou d'autres personnes non membres de l'équipe
• problèmes de présence de certains participants
• le Scrum Master doit répéter tous les jours les 3 questions
• le Scrum Board n'est pas à jour, voir "abandonné"

Parmi les questions-réponses qui ont suivi, j'ai retenu les remarques sur la durée d'un sprint, préconisée entre 2 et 4 semaines, dans la pratique plutôt 2-3 semaines. C'est à l'équipe de trouver son "bon" rythme. Mais l'important est d'avoir une durée fixe, au moins pendant quelques sprints, pour que l'équipe puisse s'adapter à cette durée et évaluer au mieux si elle lui convient.

En s'élargissant, le débat a amené le point concernant le temps à prévoir ou pas, dans un sprint, pour les imprévus comme le support, la correction de bug, etc ... avec une idée intéressante : prévoir un volume temps dans le sprint, et s'il n'est pas utilisé, en profiter pour de l'auto-formation de l'équipe ! Cool ! A condition de réussir à "vendre" cela pour avoir le "budget" ...

En conclusion, cette session m'a permis de revoir les principes de base, de confirmer mon approche et mes idées sur le daily et, plus largement, l'agilité et Scrum, et de noter quelques idées complémentaires intéressantes.

Comment concilier agilité et projet au fordait ? - Jean-François Jagodzinski

Ce sujet m'intéressait car c'est une question qui revient souvent, sur laquelle je m'interroge régulièrement, et pour laquelle je n'ai pas encore trouvé d'éléments de réponse. Elle rejoint d'ailleurs un peu la question d'un fonctionnement agile en interne, au niveau de l'équipe de développement, par rapport au reste de l'entreprise (mais ça n'est pas du tout le sujet ici).

La présentation de Jean-François est intéressante sur la forme puisqu'il a présenté 2 cas concrets, 2 leçons, où il a essayé de proposer une approche agile, sur des appels d'offre "classiques".

Pour commencer, JF a fait quelques rapides rappels sur l'approche agile. J'ai noté ce comparatif intéressant :

Approche classique	Approche agile
Méthodes	Pratique
Jeu d'échec	Jeu de cartes
Qualité des procédures	Qualité des relations et des échanges
Approche par la théorie	Approche par la pratique

J'ai bien aimé l'analogie avec une comparaison Jeu d'échec / Jeu de carte, pour laquelle il faut imaginer la suite de la partie si un joueur change :

• dans le premier cas, tout est sur l'échiquier, si le joueur a le même niveau, la partie peut continuer
• dans le 2ième cas, le nouveau joueur n'a pas l'historique de ce qui s'est déjà passé, des cartes déjà tombées, il aura du mal à bien reprendre la suite de la partie ....

Cette analogie permet de mettre en évidence la particularité de l'agilité, énormément basée sur les échanges et la pratique.

Une phrase retenue : l'agilité c'est changer son point de vue ! ..... Et comment !  Non seulement pour les membres de l'équipe Scrum (PO, SM, équipiers), mais également pour toute l'entreprise, l'agilité est une révolution culturelle de toute l'entreprise !

A noter qu'ici encore la question de la durée des sprints a été abordée avec une remarque évidente mais intéressante de JF : les itérations courtes permettent une feedback client plus rapide. Mais personnellement, je trouve qu'une durée de 2 semaines est un minimum pour prendre en compte les différents meetings de Scrum, et permettre à l'équipe de bien rentrer dans le sprint.

Pour la leçon 1, il s'agissait de répondre à un appel d'offre pour la mise en ligne d'un site pour les certifications, en relation avec la parution à court terme d'une loi. Les specs et les maquettes écran étaient là, mais globalement, le projet ne s'est pas bien passé, pas mal de retards, d'échecs de livraisons en court de projet, et un dépassement de délai conséquent.

Au final, le bilan est le suivant :

• un client plutôt satisfait malgré les retards (mais la loi est sortie plus tard que prévue ... ;-) ....)
• une équipe en demi-teinte, satisfaite par l'ambiance, mais déçu du résultat pour le travail fourni
• une qualité mauvaise
• et les financiers fournisseurs mécontents (retards, bugs, avenants)

L'approche brute n'est pas la bonne ...

La leçon 2 est dans un contexte différent puisqu'il s'agissait de refaire et considérablement étendre un outils existant (mesures et contrôles techniques d'onduleurs). Il n'y avait donc pas de cahiers des charges, à part le logiciel existant et les expériences utilisateurs sur ce logiciel.

L'idée retenue est intéressante puisqu'il a été proposé au client une période de calibrage, c'est-à-dire de mesure de la vélocité pendant 3 sprints. Un backlog produit a été commencé, avec des estimations en points, pendant la mise en place technique de l'équipe qui a ensuite attaqué ses 3 itérations pendant la fin de la décomposition fonctionnelle.

L'équipe est alors capable d'estimer sa vélocité et donc sa capacité à produire pour les sprints et releases suivants. A ce stade, le client avait la possibilité de tout stopper, en ne payant que la moitié du temps passé, et en partant avec un début de logiciel et les sources.

Cette étape ne semble pas facile, elle comporte l'étude de plusieurs pistes, solutions, moyens d'actions (puisque les prévisions étaient revues à la hausse), mais elle a le mérite de permettre à chacune d'avoir une bonne vision sur la situation, et de meilleures cartes en main pour décider.

Le client a décidé de continuer. Un planning a donc été mis en place, avec des releases planifiées, comportant chacune 2 à 7 sprints, et avec la possibilité pour le client de stopper à chaque release, moyennant compensation financière (donnant-donnant).

Le bilan de cette leçon est bien plus positif :

• une client satisfait malgré une augmentation de budget, mais une bonne collaboration, et surtout, un logiciel adapté
• une équipe également satisfaite, notamment par cette collaboration, mais également une bonne ambiance et un rythme soutenable
• une bonne qualité logicielle
• et les financiers fournisseurs contents grâce à des couts maitrisés

JF fait quand même remarquer que dans les 2 cas, le contexte était favorable, avec notamment des personnes motivées par l'agilité, une direction décidée, des clients ouverts, etc ...

La meilleure réussite de la leçon 2 est probablement dûe à un meilleur équilibre dans le triptique périmètre-budget-délai ! Mais également d'autres points importants :

• une préparation basée sur une vision et du fonctionnel
• un budget orienté sur l'essentiel et des releases intermédiaires
• une organisation basée sur un début de développement, une acceptation du changement, etc ...

En conclusion, je pense que l'approche agile sur des contrats au forfait est possible, mais encore délicate. Il faut quand même faire attention, et profiter d'opportunités, de contextes favorables. Et espérer un développement fort des approches agiles dans les esprits ...

Informaticiens agiles, les agents du changement - Thierry Montulé

Thierry devant prendre un train sans trainer (grèves), la présentation a été ... express ! ;-)

Au début, j'ai eu un peu de mal à accrocher, à voir où il voulait en venir. Mais j'ai finit par comprendre !

La société est en changement permanent, avec de nombreux impacts à tous les niveaux et dans tous les domaines, notamment celui du logiciel et de la SI. On tombe vite dans un cercle vicieux entre changements, difficultés d'adaptation, stress, réactions, changements, etc ... Parmi les solutions : l'agilité (bien sûr !) où les développeurs font partie des principaux acteurs !

Une phrase retenue : "Le changement ? C'est faire ce que l'on ne sait pas faire !" ....

Thierry nous donne quelques pistes pour conduire le changement :

• accompagner plutôt que subir
• les problèmes d'ingénierie logicielle sont plus sociologiques que techniques
• il faut mobiliser les acteurs en leur apportant satisfaction et motivation
• "rendre possible de faire ce que l'on ne sait pas faire"
• mais .... pas de recette miracle !

En tant que Scrum Master, je me retrouve bien dans ces idées bien orientées vers l'humain !

Thierry nous explique que dans l'organisation, l'humain se retrouve dans différentes couches. En résumé:

• couche physique, technique : changements les plus faciles et les plus visibles
• couche régulation (mesures, reconnaissances, salaires, ....)
• couche des valeurs (notamment de l'entreprise) : changements les plus difficiles et les moins visibles

Quelques obstacles observés au changement :

• une pression à court terme, pas le temps d'apprendre
• nostalgie, doutes, inquiétude
• pourquoi changer ?
• les objectifs du changement ne sont pas clairs
• manque de leadership, de crédibilité
• saut culturel et technique trop important
• manque de compétences
• ...

La liste de témoignages qu'il nous donne ensuite me fait penser à l'effet vert dont m'avait parlé François Beauregard : plus on remonte la hiérarchie, et plus les voyants sont au vert (tout va bien) ...

Thierry nous a présenté un schéma qui m'a beaucoup parlé. Je ne sais pas s'il a un nom. L'idée est de montrer les étapes par lesquelles on va passer lors d'un changement, avec un axe du temps et un axe de "refus". Une petite recherche internet me montre que ce sujet est souvent traité. Il faudra que j'y consacre un billet ...

Il faut donc communiquer avec les acteurs, et cela commence par : écouter, s'adapter à l'interlocuteur, expliquer, prouver, succiter les envies, célébrer les réussites, ...

La fin de la présentation s'est malheureusement faite au pas de course, mais un nouveau sujet m'a interpellé concernant les différents types de réactions, de profiles. Un nouveau schéma très intéressant (pareto ?), et quelques remarques à noter :

• trouver des alliés et s'y attacher
• identifier les opposants et les ignorer
• et tous les cas intermédiaires ...

En conclusion, une présentation interpellante, avec des retours intéressants sur les aspects humains ! Et encore une fois, le fait que l'agilité nécessite le changement (de point de vue) et implique d'accepter le changement (valeur de base) : tout cela n'est évidemment pas facile !

Vers le chemin de l'amélioration : Sprint rétrospective - Céline Stauder

Pour finir, j'avais choisit cette présentation, à nouveau avec Céline. Par expérience, je sais maintenant l'importance de ces rétrospectives qui peuvent réellement apporter de l'amélioration à l'équipe !

Comme pour le daily, Céline a rappelé quelques éléments de base importants :

• pour les pigs, c'est-à-dire ceux qui sont engagés dans le sprint
• en fin de sprint
• une durée d'environ 1/2 journée pour un sprint de 30 jours (~ 45' par semaine de sprint)
• environnement adapté aux échanges, en toute confidentialité, pourquoi pas "hors cadre" (dans un café, dehors, ...), climat de confiance, pas de jugements l'idée étant l'amélioration
• 2 objectifs :
1. s'exprimer, donner son ressenti
2. monter un plan d'action
• timeboxer les 3 étapes :
1. collecter les informations
2. rechercher des solutions
3. définir un plan d'action

Pour l'environnement "hors cadre", je me souviens d'une rétrospective animée dans le train (2h de TER) avec les posts-its collés sur les vitres, ça avait très bien fonctionné, avec des échanges sincères entre les équipiers (hors contexte quotidien ?).

Pour la phase de collecte d'informations, Céline a rappelé un point important, souvent oublié : il y a des sources existantes comme :

• un backlog de problèmes (s'il existe et a été renseigné en cours de sprint, pratique pour éviter d'oublier les difficultés), 
• les compte-rendus et résultats des précédentes rétrospectives, 
• ainsi que tous les métriques intéressants (vélocité, ...). 

Concernant la collecte auprès des équipiers, Céline a évoqué le tour de table orale, avec l'animateur (le Scrum master à priori) qui crée et colle des post-its sur le tableau dans 2 colonnes + ou -.
Personnellement, j'ai testé et je privilégie une autre solution qui consiste à donner à chacun une pile de post-its et un stylo en se donnant un temps fixe de réflexion (par exemple 6'). Certains vont écrire des posts-its tout au long de ce temps. Mais j'ai observé d'autres personnes qui écrivent quelques post-its en rafale puis pose le stylo et croise les bras du genre "j'ai finit". Mais il reste encore plusieurs minutes, et finalement, ces personnes finissent par reprendre leur stylo pour créer de nouveaux post-its. Comme quoi il y avait encore des choses à dire !

Ensuite, je demande à chacun d'aller coller ses post-its au tableau selon un axe +...-, certains post-its se retrouvant au milieu. J'ai constaté que cette façon de collecter permet une expression plus riche et plus intense de tous en éliminant pas mal les blocages dus à la timidité ou autre !

Ensuite, tous ensemble devant ce tableau, nous parcourons les post-its pour les découvrir ensemble, demander des précisions pour bien les comprendre, enlever les doublons et les regrouper par thème pour dégager les points importants. Puis chacun a droit à un certain nombre de vote (3, 4 ...) ce qui permet de dégager les points les plus importants à traiter.

Céline a également parlé de ce regroupement par thème qui, accompagné par les discussions spontanées, fait parfois ressortir des causes différentes de celle initialement exprimées.

La dernière étape, qui consiste à mettre en place un plan d'action, est évidemment indispensable, et Céline a insisté sur les points suivants :

• retenir quelques points (on ne peut pas tout traiter)
• se concentrer sur des choses simples
• disposer d'indicateurs mesurables pour évaluer le résultat
• pour chaque point, nommer 1 garant qui veillera à l'application et le respect de ce point par toute l'équipe

Ce qui m'a interpellé c'est que c'est exactement ce que j'avais spontanément mis en place, aux indicateurs mesurables près : certains points sont plus difficiles à mesurer, surtout lorsqu'il s'agit de ressentis humains.

En conclusion, là encore, cette présentation m'a permis de me conforter dans l'idée que je me fais des rétrospectives, et l'importance qu'elles ont dans un processus Agile, pour l'amélioration continue de l'équipe, à condition de mettre en place un plan d'action, de le suivre, et de l'évaluer.

Conclusion

Comme je l'ai mis dans ma fiche d'évaluation en fin de conférence, je n'ai pas regretté le déplacement, au contraire. Globalement, j'ai ré-entendu pas mal d'informations que j'avais déjà, mais cela m'a permis de confirmer que pour moi, l'agilité est maintenant incontournable pour une production logicielle de qualité, dans un contexte positif.

Je constate tout de même, vu le public présent et les questions posées, que l'agilité a encore du chemin à faire, mais la curiosité, ou plutôt l'intérêt d'un nombre croissant d'acteurs, permet d'espérer un développement intéressant de ces valeurs, développement auquel j'espère pouvoir contribuer.

Un grand merci aux organisateurs et aux intervenants pour ce bon moment, bien organisé, bien sympathique et très enrichissant !

Soirée "Google et les technologies connexes" à Grenoble (17/09/2010)

Vendredi 17/09/2010, l'Alpes JUG (http://www.alpesjug.org/) organisait une soirée, chez Orange Labs à la ZIRST de Meylan, avec une présentation par Didier GIRARD (http://www.application-servers.com/) des technologies Google.

Au-delà des retrouvailles avec Didier (pas vu depuis ... 16 ans), j'ai beaucoup apprécié sa présentation qui m'a éclairé sur certains points et convaincu sur certaines technos. Je voulais donc y consacrer mon premier billet, pour partager certaines idées fortes retenues, avec mes collègues qui n'ont pas pu venir avec moi, et inciter ceux qui le peuvent à aller voir une telle présentation (si l'occasion se représente).

Introductions

Avant de rentrer dans le détails des technos, Didier a fait quelques "rappels" en commençant par le cloud. et les différentes solutions :

• IaaS = Infrastructure as a Service : location de matériel [voir : Amazon, Salesforce, EC2, ES3, ...]
• PaaS = Platform as a Service : hébergement d'application [voir : Google App Engine, Amazon, Salesforce, VMWare, ...]
• SaaS : Software as a Service : location de logiciels [voir : GMail .... et oui, vous consommez déjà du SaaS ... ;-) ... ]

Didier : "Nous entrons dans un monde d'abondance, notre 'carburant' (CPU, stockage) ne coute rien, de nouvelles opportunités sont là !

[NDLA : ce sujet du "cloud" est vraiment passionnant (*)]

Didier a également parlé des RIA (Rich Internet Application) en évoquant GWT, Flex, JQuery, Silverlight, ... et en présentant succinctement quelques éléments de comparaison, toujours bon à entendre !

Sans oublier la mobilité, secteur en plein expansion, explosion, avec notamment ... Android, évidemment !

Google App Engine

Les mot clés que je retrouve dans mes notes : hébergement d'application, gratuit (quotas), mail, batch, XMPP, base NoSQL (Bigtable), namespace (partitionnement des données entre utilisateurs), MapReduce, déploiement en 1 clic, import/export Bigtable, ...

Didier nous a fait une démo. Grâce au plugin Eclipse, la création d'une application avec un squelette basique, puis le déploiement "sur le cloud" sont vraiment faciles.

Ensuite, Didier a longuement expliqué et insisté, démos à l'appui, sur les quotas et les "hors quotas" (quand on dépasse) avec les possibilités de paiements, la gestion de son "budget", les suivis très détaillés dans le tableau de bord, etc ... GAE est vraiment bien pensé, et surtout très bien outillé, autant côté développement que console d'administration.

Une des principales difficultés, peut-être, est la base Bigtable, de type NoSQL, ce qui peut surprendre. Mais des frameworks existent pour pouvoir faire du développement plus type JPA, comme par exemple Objectify.

Je connaissais déjà un peu GAE, la création facile, le déploiement en 1 clic, la "surprise" de Bigtable, les aides de Objectify, etc ... mais certains précisions apportées par Didier m'ont bien éclairé, et surtout, encore plus convaincu de l'intérêt du cloud !!!

Didier nous a montré pas mal de choses en se basant sur son application pour Android http://www.abonentendeur.com/ (petite pub au passage ... ;-) ...). Dans la console GAE, il était intéressant de voir la courbe de fréquentation monter au fur et à mesure de la soirée, puisque nous étions un vendredi, soir de départ en week-end (et les automobilistes s'intéressent au bouchons et autres radars ...).

GWT

Les mot clés que je retrouve dans mes notes : compatibilité tous navigateurs, très bon pour "touch Web" (smartphones), très facile pour le développement (langage Java), très "open source" (avec les avantages de la communauté), coûts réduits, Javascript optimisé (en taille) et téléchargé 1 fois, mode "offline" possible, gestion i18n, possibilité de debug (points d'arrêts), outils et plugins de "design" (GWT Designer rendu public la veille de la soirée), ...

Je dois l'avouer, j'étais plutôt "GWT-septique", mais Didier m'a vraiment convaincu, surtout par les avantages (voir ci-dessus).

A noter que Didier anime un blog dédié à GWT : http://www.ongwt.com/.

Android

Didier étant bavard, il n'a plus eu beaucoup de temps pour nous parler d'Android. Il nous a quand même fait une démo, avec à nouveau la création simple et rapide d'une application basique, avec test dans un simulateur, puis test dans son smartphone. Une plateforme très prometteuse et très porteuse, à saisir !

Conclusion

Une soirée vraiment intéressante et enrichissante. Didier ma surpris par son enthousiasme communicatif.
Merci à l'AlpesJUG pour l'organisation et l'accueil.
Et Didier .... à bientôt ... ;-)



(*) J'ai également regardé la vidéo de la présentation Opportunités du cloud pour la Direction des Etudes par Arnaud Héritier et Julien Jakubowski à l'USI 2010, excellent !