Agile Grenoble 2015 : atelier l'agilité de l'intérieur

Ce jeudi 19 novembre avait lieu Agile Grenoble 2015. Avec Laurent Tardif et quelques autres personnes, nous avons animé toute la journée un atelier "L'agilité de l’intérieur". Voici sur mon retour sur cette expérimentation !

Scrum : quel est le rôle le plus important ?

Introduction

Pour l'organisation agile d’un projet de développement logiciel, Scrum propose un cadre simple et précis, avec notamment 3 rôles, ni plus ni moins :

• Scrum Master
• Product Owner
• Equipier

Ces derniers mois, à plusieurs reprises, je me suis posé la question de savoir lequel de ces rôles était le plus important, voici mes éléments de reflexion.

Calendrier niko-niko : l’équipe surveille son moral !

C’est quoi ? Quel est l’objectif ?

Le "niko-niko" est un calendrier, mis en œuvre par l’équipe et pour l’équipe, sur lequel chaque membre de l’équipe reporte à la fin de chaque journée son ressenti avec une pastille de couleur.

Par "équipe", j’entends bien entendu l’ensemble des équipiers, le Product Owner s’il est bien impliqué au quotidien, et le Scrum Master (sauf peut-être s’il est uniquement un animateur ou facilitateur). En fait, il me semble intéressant que toutes les personnes participant tous les jours au stand-up, contribuent à cet indicateur !

Scrum Tower Game

Le "Jeu de la tour Scrum", ou comment découvrir les concepts de base de l'agilité et de Scrum en s'amusant ...

Introduction

Il y a quelques années, sollicité par une entreprise pour sa transition vers l'agilité (merci à eux), j'ai mis au point un jeu permettant de découvrir quelques aspects de l'agilité, et les concepts de base de Scrum. Baptisé depuis "Scrum Tower Game", j'ai déjà déroulé plusieurs fois cet atelier, qui tient ses objectifs à chaque fois.

Après en avoir parlé au détour d'une bière, je l'ai fait jouer lors d'une soirée agile du CARA à Grenoble, avec des retours intéressants des personnes présentes. 

Lors de la dernière session de Agile Game France, je n'ai pas osé l'amener dans mes valises, mais certaines personnes me l'ont fait regretter, et m'ont motivé à diffuser cet article pour le présenter (1).

Agile Grenoble et Agile Innovation cuvée 2013

Les 21 et 22 novembre dernier, j'ai assisté à Agile Grenoble 2013 et Agile Innovation 2013. En voici quelques éléments de retour.

Qualité :

• Il n'y aurait pas "la" qualité mais "les" qualités ?
• Du moins, il y a plusieurs éléments de qualité, selon qu'on regarde le code, la stabilité de l'application, sa réponse au besoin, son utilisabilité, etc ...
• Mais pour commencer, l'important est déjà de se poser des questions, quelques soient les critères d’évaluation : quelle est la qualité attendue ? quelle est la qualité de l'application actuelle ?

Mon retour sur Agile Tour Marseille 2013

Jeudi 3 octobre 2013, je suis allé passé ma journée à l'Agile Tour Marseille 2013 où j'animais une session "TDD en coding-dojo". Voici quelques éléments de retour en suivant mon programme de la journée ...

Keynote "La horde agile" par Pablo Pernot

Après un accueil café-madeleines, nous avons attaqué la journée avec Pablo pour une keynote digne de ce nom, du moins comme je les aime : sujet en lien avec l'agilité, mais sujet décalé par rapport à ce qu'on peut avoir dans les sessions.

Pablo remonte le temps pré-historique pour retrouver certaines valeurs de l'agilité, et certains principes, dans les us et coutumes de nos lointains ancêtres, qui nous ont beaucoup laissé en héritage, au fond de nous, et que souvent nous oublions ou repoussons.

Un enchaînement de réflexions intéressantes, même si je n'ai pas toujours tout capté (fatigue de la route, réveil matinal ? ....).

Agile Tour Marseille 2012

Hier, pour la 3e année consécutive, j'ai participé à Agile Tour Marseille 2012, et 2e année en tant qu'orateur (après un atelier "TDD en coding-dojo" pour l'édition 2011). Grosse bonne journée dont voici quelques retours en suivant les sessions auxquelles j'ai assisté.

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

Forfait, marché public et agilité : petit REX

J'ai récemment clôturé une petite affaire, au forfait pour un organisme public, donc un marché public. Le projet a été proposé et mené dans une approche agile dont voici un petit retour d'expérience.

Contexte

• Evolutions et corrections sur une application WEB interne existante
• Liste des points à traiter fournie dans le cahier des charges mais manque de clarté et de précision
• Affaire traitée en moins de 2 mois par une personne (moi)
• Seulement 3 intervenants : 2 interlocuteurs côté client (dont 1 que je connaissais déjà) et moi-même

Idée de départ

Adepte des approches agiles, il me semble désormais difficile, voir impossible, de mener une affaire en mode "classique" :

• Etablir et signer un cahier des charges fixe
• Se mettre d'accord sur un délai et un tarif (et donc un contenu)
• Développer "hors site" pendant plusieurs semaines (ou moi)
• Le jour J, livrer ce qui a été réalisé, prendre acte des problèmes et mécontentements, les gérer au mieux, et se faire payer !

J'ai donc souhaité proposer une approche plus agile, en m'inspirant de Scrum, et de mes expériences en agilité, en me donnant quelques objectifs précis :

• Satisfaire les utilisateurs finaux et donc mon client
• Permettre les changements par le client en lui donnant le contrôle de la priorisation
• Fonctionner en cycle court pour avoir du feedback régulier

Vocabulaire

Les 2 interlocuteurs pour ce projet ne sont pas du tout expert en informatique, logiciel, développement, etc ... De plus, le projet était court en durée. J'ai donc opté pour une adaptation du vocabulaire par rapport à Scrum :

• "Histoires" (Stories) : j'ai plutôt parlé de "fonctionnalités" tout simplement
• "Carnet de produit" (Product backlog) : j'ai introduit la notion de "Référentiel des fonctionnalités" pour le document que j'ai créé en début de projet, avec la liste des points à traiter, que j'ai complètement ré-exprimés, et que j'ai maintenu à jour tout au long des développements, fournissant ainsi en fin de projet un état des lieux des points traités ou non
• "Itérations" (Sprints) : j'ai gardé le terme d' "itérations" qui reste intuitif et a été très bien adopté par tout le monde
• "Vélocité" (Velocity) : j'ai plutôt évoqué la "capacité de production" journalière permettant d'estimer un "volume de production" par itération
• "Réunion de planification" (Sprint planning) et "Revue d'itération" (Sprint review) : j'ai regroupé ces 2 cérémonies en une seule baptisée simplement "Réunion d'itération"

J'ai laissé de côté le rôle de ScrumMaster pas vraiment utile dans ce contexte. Le terme de "Responsable de produit" (Product Owner) a été évoqué dans la présentation initiale de l'approche, mais sans être utilisé par la suite.

Approche proposée et organisation

Le projet a commencé par la ré-expression des points à traiter pour donnant naissance au "Référentiel des fonctionnalités", sur base des éléments initialement fournis, et grâce à des échanges avec les 2 interlocuteurs pour leur faire exprimer les besoins (et non les solutions comme c'était le cas dans le cahier des charges fourni).

J'ai ensuite estimé chaque fonctionnalité en "points", de 1 à quelques dizaines. Les fonctionnalités ambiguës ont été estimées avec des fourchettes de points, et séparées des autres pour être précisées avant d'être implémentées. Un repère de 6 points par jour a été utilisé.

A chaque début d'itération, le RDV de la prochaine "Réunion d'itération" était fixé permettant d'en déduire le nombre de jours possibles de production (selon le calendrier et mes disponibilités), et donc le volume estimé de production selon la "capacité de production". Exemple pour l'itération 1 : 6 jours à 6 points = 36 points. Le client pouvait alors "faire son marché" et choisir lui-même les fonctionnalités à implémenter dans la prochaine itération.

Les échanges en cours d'itération ont été nombreux, surtout par mails, pour demander des précisions ou des validations mineures, et tenir informé le client des éventuels changements de planning (1 jour de production en moins par exemple).

En fin d'itération avait lieu la "Réunion d'itération" découpée ainsi :

• Point sur l'itération écoulée, bilan du temps passé, des fonctionnalités traitées ou non, évaluation de la nouvelle "capacité de production"
• Démonstration sur mon portable de chaque fonctionnalité traitée
• Si la satisfaction est au RDV, et si c'était prévu, mise en production
• Préparation de l'itération suivante

Une mise en production a été prévue et réalisée en fin d'itération 2, et bien sûr, en fin de projet.

Observations et constats

Adoption de la méthode : malgré des réticences en début de projet, la méthode proposée a été très vite adoptée, avec une satisfaction manifestée dès la fin de l'itération 1.

Référentiel des fonctionnalités : ce document a vraiment été la colonne vertébrale du projet, servant de référence permanente pour tous, mais nécessitant un investissement pour sa mise à jour quotidienne. Son intégration parmi les livrables à chaque itération, et donc en fin de projet, a permis de fournir au client un véritable état des lieux des développements, et notamment en fin de projet, une vision claire de ce qui a été réalisé, et surtout de ce qui ne l'a pas été, par exemple pour prévoir une prochaine intervention sur l'application.

Vélocité : pour la première itération, la capacité de production avait été estimée à 6 points par jour. Malgré 1 jour de production en moins, tout ce qui avait été prévu a été traité, amenant à constater une capacité de production supérieure à 7. Cette capacité a donc été portée à 7 pour l'itération suivante et est restée à cette valeur pour le restant du projet.

Priorisation : le système de "marché à points" proposé a tout de suite été compris et bien pris en main. Les interlocuteurs connaissait bien le sujet, les objectifs du projet et les points à traiter. Ils n'ont jamais eu de difficultés à choisir les fonctionnalités à traiter selon la capacité disponible.

Suivi et feedbacks : ce point a été parmi les plus forts du projet, puisque les échanges réguliers ont permis d'établir une véritable collaboration avec le client, qui avait une vision claire et transparente de l'avancement, et sentait au jour le jour sa capacité à aller ensemble vers un résultat de qualité permettant de satisfaire les utilisateurs.

Proof of concept : un exemple caractéristique de l'intérêt du feedback :
Pour plusieurs fonctionnalités, j'ai proposé une solution de pages à comportement dynamique (afficher certains champs selon des choix effectué par l'utilisateur). Pour permettre au client d'appréhender la solution proposée avant de l'appliquer à plusieurs endroits, elle a été implémentée sur un cas lors de la première itération. Le client a ainsi pu la visualiser et la valider pour qu'elle soit implémentée sur le reste de l'application.

Droit au changement : le client ayant bien adopté le système de priorisation à sa charge sur base du système de points, il a tout naturellement intégré la possibilité de changements, évidemment en respectant les volumes de charges. Ainsi, bon nombre de changements ont eu lieu au cours de chaque itération, avec des changements sur certaines fonctionnalités, sur leur priorisation, mais également la prise en compte de nouvelles fonctionnalités ou extensions de tâches réalisées.

Encore plus fort ... : lors de la préparation de la quatrième et dernière itération, une discussion a eu lieu autour de fonctionnalités de recherches au sein de l'application existante. Le client a exprimé son insatisfaction récurrente et ancienne par rapport à ces fonctionnalités, et le souhait d'un unique moteur de recherches croisées. J'ai fait quelques remarques et propositions de fonctionnement et d'ergonomie. Le client m'a demandé une estimation (en points bien sûr) qui s'est avérée assez importante, quasiment égale à la capacité de production pour la dernière itération à venir. Après réflexion, le client a décidé d'abandonner tout ce qui restait au cahier des charges pour favoriser la mise en place de ce nouveau module, qui n'avait pas du tout été prévu dans le projet ! Donc un changement complet du reste du projet aux 3/4 de son déroulement ! Et le résultat ne l'a pas déçu, sans aucun regret pour les fonctionnalités écartées, qui ne sont finalement que partie remise pour un prochain projet ;-) .....

A améliorer

Le premier point est dû à ma découverte des appels d'offres pour marchés publics, pour lesquels le montant est fixé (politiquement), alors que j'avais imaginé plus d'échanges et mises au point avant le lancement du projet (évaluation des besoins, explications sur la méthode, ajustement du volume, ...).

Le second point qui m'a piégé est d'avoir mal anticipé la fin du projet pour lequel il aurait été bon de prévoir un volume d'intervention après la dernière itération pour finaliser les développements selon les remarques et observations exprimées lors du bilan de la dernière itération.

Enfin, le "Référentiel des fonctionnalités" devrait idéalement être tenu de façon collaborative, donc un format type Wiki sur un serveur accessible de tous pourrait être intéressant. Mais dans le contexte de ce projet, l'implication du client ne serait pas allée jusque là, et la mise à disposition d'un fichier PDF en fin de projet a été apprécié.

Conclusion

Pour moi, elle est simple : une réussite totale (ou presque) du traitement en mode agile pour ce projet.

Bien sûr, il faut pondérer ce résultat en prenant en compte le contexte "favorable" de ce projet : tout petit projet, liste assez précise des besoins, interlocuteurs connus et collaboratifs, etc ...

Néanmoins, cette expérience reste intéressante et me semble transposable à plus grande échelle, vivement une prochaine opportunité ...

Et vous ? Que vous inspire ce retour d'expérience ? Quelles sont vos expériences en la matière ? ...

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 !

Coding-dojo ou l'apprentissage du TDD

Introduction

Dans le cadre de mes interventions en entreprise, j'ai eu il y a quelques temps une demande pour « pousser » une équipe de développements vers le TDD. M'a réponse a été de proposer une solution en 3 étapes sur une journée entière.

Cette journée s'est déroulée le lendemain d'une journée de formation, ou plutôt comme je préfère dire, d'information « Agilité et Scrum ». Les participants à la journée « TDD » avaient donc connaissance des valeurs et principes de bases de l'agilité et de Scrum, véritable pré-requis pour aller droit au but du TDD.

Étape 1 : théorie

La première partie de la journée est une présentation théorique sur base d'un diaporama.

On commence en abordant le sujet des tests : tests unitaires, tests d'intégration, tests fonctionnels, automatisation des tests, etc ... Pour faire du TDD, il faut évidemment être d'abord convaincu de l'intérêt d'avoir des tests, et qu'il est plus facile de les écrire avant plutôt que après le code de production, le système étant alors forcément « testable ». On revient notamment sur le coût de correction des bugs qui sera d'autant moins élevé que le bug est décelé tôt (cf Scott Ambler).

On évoque ensuite les outils : les frameworks de tests (JUnit pour Java, PHPUnit pour PHP, Hunit pour Haskell, etc …) et les frameworks de mocks (Mockito, Easymock, JMock, PowerMock, etc …). C'est l'occasion d'expliquer l'intérêt des mocks quasiment indispensables si on fait une architecture bien découpée, à couplage lâche et injection de dépendances.

On ne peut parler de tests sans poser les règles de base, ainsi que les bonnes pratiques : 1 test pour 1 cas, des tests structurés, rapides, évolutifs et propres, du refactoring avant toute chose, etc …

Vient ensuite la présentation du TDD proprement dit : pourquoi du TDD, principes, cycle (rouge-vert-bleu), les variantes, les difficultés, les erreurs à ne pas commettre, les conseils, etc …

La partie théorique se termine par la présentation du coding-dojo : c'est quoi ? Pour qui ? Le Kata et le Randori, organisations et logistique, conseils, etc ...

Étape 2 : démonstration

Pour illustrer le propos, comme on dit, la matinée se termine par une démonstration. Je me met au clavier avec mon environnement de développement, et en partant de sources vides, je montre comment se déroule le TDD.

La démonstration se déroule sur plusieurs exemples de difficultés progressives pour montrer les bases du TDD : un exemple basique, la mise en œuvre sur un exemple plus complet mais toujours simple, et enfin, l'utilisation de mocks sur une exemple bâti sur plusieurs classes, donc des tests sur une classe ayant besoin de collaborateurs.

J'ai constaté des intérêts multiples à cette phase de démonstrations : la possibilité pour les développeurs de concrétiser les explications précédentes, la preuve par la pratique de la faisabilité, un gain de crédibilité et de légitimité en mettant les mains dans le cambouis.

Étape 3 : coding-dojo

L'étape suivante, qui se déroule sur au moins 3h l'après-midi, est la plus ludique et souvent la plus attendue. C'est le moment du « conding-dojo », que j'appelle également « séance de développement en groupe ».

Ma mise en pratique est assez proche des principes que je ne rappelle pas ici, et qui sont facile à trouver sur internet. Par expérience, et après avoir testé différentes durées, je fais des « tours » de 6'. Par contre, je n'hésite pas à mettre le chrono en pause si une discussion prend place pour ne pas pénaliser et frustrer le pilote en place.

Côté sujets, je propose des choses extrêmement basiques, selon les niveaux de l'équipe présente, l'important étant de bien mettre le focus sur le TDD, et non sur une problématique algorithmique ou autre. Ça n'est pas l'objectif d'un dojo « TDD », mais ça pourrait l'être pour un autre dojo. En effet, le coding-dojo est assimilable à une séance de formation, par la pratique, extrêmement instructive. L'objectif d'un dojo doit être unique et clair, et les sujets doivent être en accord avec cet objectif : découverte d'un langage, d'une techno, étude collective de solutions algorithmiques, etc …

Pour bien démarrer la séance, je n'hésite pas allouer le temps nécessaire à l'équipe présente pour échanger sur le sujet pour définir une approche collective. Selon le niveau d'expertise des participants, je les conseille et les guides vers des approches d'architectures « agiles », tout en les laissant maîtres de leurs choix pour qu'ils restent à l'aise pour la mise en pratique ...

En ce qui me concerne, je n'interviens pas en tant que pilote pour permettre un maximum de passage pour les participants. Je joue donc les rôles d'animateur (tours de rôles, timing, …), et de Product Owner (pour les questions sur le sujet et les éventuels choix à faire, en apportant des réponses rapides et claires). Je n'hésite pas non plus à guider les intervenants en suggérant des solutions ou des pratiques, sans s'écarter de l'objectif principal du dojo : mettre en œuvre le TDD.

Mais tout cela ne suffit pas ...

Et oui, ça n'est pas en quelques heures de théorie, démonstrations et mise en pratique qu'on devient maitre du TDD. C'est pour cela que je conclue la journée en donnant quelques conseils aux développeurs : n'attaquer pas forcément dès demain matin, attendez une bonne opportunité, un bout de code qui vous semble favorable au TDD, que vous sentez bien. Mais ça n'ira pas tout seul ...

Alors je propose aux développeurs d'essayer le TDD, de noter les difficultés, les opportunités, etc ... et que nous nous revoyions de temps en temps, régulièrement, pour aborder individuellement ou collectivement ces opportunités, les essais réalisés, les succès, les échecs, etc ...

Pour moi, cette approche globale est la meilleure solution pour accompagner une équipe vers la pratique du TDD, ou du moins vers une approche plus « agile ».

Et vous ?

Quelles sont vos expériences en matière d'apprentissage du TDD, de coding-dojo, etc .... merci pour vos retours et commentaires !

Pour ceux qui peuvent ...

... je serais à l'Agile Tour à Marseille le 13 octobre 2011 pour animer un atelier participatif de 2h sur ce sujet, l'occasion de mieux se rendre compte de quoi il s'agit, et d'échanger sur le sujet !

A bientôt ...

Chef de projet ScrumMaster ... Arg !

Mission "Chef de projet ScrumMaster"

Il y a plusieurs semaines, j'ai vu passer une annonce de mission intitulée "Chef de projet ScrumMaster". Interpellé par l'intitulé, j'ai consulté l'annonce. La personne recherchée devait :

• piloter l'équipe
• faire l'interface entre l'équipe et les clients
• faire du reporting à la hiérarchie
• etc ...

Bref, toute la panoplie d'un "Chef de projet" et rien à voir avec un ScrumMaster

"En fait, le ScrumMaster c'est l'équivalent d'un chef de projet ?"

Lors de récentes formations, ou plutôt "informations" (je préfère ce terme) sur l'Agilité et Scrum, systématiquement, la question ressortait : "En fait, le ScrumMaster c'est l'équivalent d'un chef de projet ?" ...

STOP !

Et oui, STOP ! Arrêtons de chercher des comparaisons avec les méthodes classiques. Le rôle de ScrumMaster n'a pas d'équivalent dans ce que nous pouvions connaitre avant l'agilité.

Le ScrumMaster s'assure que le cadre Scrum est respecté, que l'équipe est opérationnelle, fonctionnelle, productive, que l'équipe met et peut mettre en oeuvre tous les moyens d'organisation et techniques pour assumer ses engagements de production, c'est un facilitateur, un accompagnateur, un protecteur, il anime les différentes réunions, il s'assure de la collaboration étroite entre les intervenants, il veille au respect des rôles de chacun, il intervient dans l'organisation pour accompagner le changement, il expose les contraintes et les problèmes de mutation, etc ...

Il n'est pas question de diriger l'équipe, de distribuer les tâches de développement, de faire les choix techniques et technologiques, de faire du reporting, de faire l'interface avec le client pour évaluer ses besoins, etc ...

Certes, le ScumMaster peut également être un développeur et faire partie des équipiers, il intervient alors au même titre que les autres membres de l'équipe pour les estimations, les choix, la vision d'architecture, etc ... Il peut prendre en charge la mise à jour du Scrum Board (Sprint backlog, burndown chart, etc ...) mais à titre "moteur", ça n'est pas forcément à lui de faire cela !

Donc, le ScrumMaster n'a rien à voir avec un chef de projet.

Pour conclure, et pour ceux qui se demanderait ce que devient le chef de projet lors d'une transition vers l'agilité, certes il peut devenir ScrumMaster, mais en oubliant son rôle précédent, et à condition d'avoir de bonnes aptitudes pour ce nouveau rôle très orienté sur les aspects humains. Personnellement, je constate que bon nombre de chefs de projet feraient plutôt de bons (Proxy) Product Owner par leur connaissances du métier, leur relationnel avec le client et les utilisateurs !

Vidéo de retours sur le ScrumDay 2011

Le FrenchSUG (French Scrum User Group = Groupe des Utilisateurs Français de Scrum) a mis en ligne une vidéo de compilation de retours sur le Scrum Day qui a eu lieu le 31 mars dernier.

La vidéo et le montage sont sympas et dynamiques, mais au delà de la forme, les retours collectés me semblent très significatifs de la situation de l'agilité actuellement, avec un gros engouement, un intérêt montant avec une popularité grandissante, mais également une mise en garde et donc une prise de conscience intéressante sur la dualité suivante : la simplicité de l'approche et la difficulté de sa mise en oeuvre au quotidien, "tout n'est pas si simple, mais ça vaut le coup", d'où la nécessité de se renseigner, se préparer et se faire accompagner !

La vidéo est là : http://www.facebook.com/video/video.php?v=10150198547436366

[Agilité] Estimation relatives des histoires

Je viens de lire l'article "90 stories en 45 minutes" publié par Benoit Gantaume, et ça me rappelle un atelier que j'avais animé, j'en profite donc pour partager cette expérience ...

Tout comme Benoit, le besoin était d'estimer une bonne quantité d'histoires, pour dégrossir les estimations et se donner une idée globale d'effort à fournir. Je m'étais inspiré de lectures ici et là pour proposer à l'équipe un atelier d'estimations relatives en mélangeant différentes idées, avec une grosse influence du Story Mapping.

Déroulement

L'atelier s'est déroulé en présence du Product Owner, de 3 équipiers (développeurs) et moi en tant que ScrumMaster. Nous nous sommes installés dans une salle tranquille en alignant 2 tables rectangulaires de façon à pouvoir circuler autour. Nous avons préparé un post-it pour chaque histoire.

Pour débuter, nous avons chercher très rapidement l'histoire qui nous semblait la plus petite (en terme d'effort à fournir, je ne parle ici que de cela) et nous l'avons positionné sur la gauche.

Ensuite, nous avons pris les histoires 1 par 1 et les avons positionné sur la table, à gauche ou à droite les unes des autres selon leurs efforts relatifs. Pour des efforts identiques, nous avons placé les histoires les unes en dessous des autres. Les histoires trop floues et ne pouvant pas être estimées ont été placées dans un coin identifié de la table.

Constats

Les histoires ont été rapidement placées les unes après les autres, quitte à décaler certains "paquets" pour en insérer certaines. Très vite, certaines histoires ont été placées très loin sur la droite, instinctivement pour un effort conséquent mais flou. D'ailleurs, une 3ième table a due être ajoutée ... Ces histoires ne peuvent donc pas être sélectionnées pour un backlog de sprint sans être re-découpées.

Nous avons également placé 1 ou 2 histoires à gauche de celle initialement estimée comme étant la plus petite, comme quoi ça n'était pas le cas, mais ça n'a absolument pas gêné le déroulement de l'atelier, l'essentiel étant d'avoir un point de départ de faible poids (effort).

Il était intéressant de constater que certaines histoires ont été déplacées plusieurs fois, dans un sens ou dans l'autre, surtout en fonction des questions posées au Product Owner pour mieux comprendre les besoins, les questions pour une histoire venant parfois lors du placement d'une autre histoire. En effet, le positionnement proche entre 2 histoires faisait parfois émerger des questions sur l'une ou l'autre pour bien évaluer les différences.

Tout comme Benoit, nous avons consigné au fur et à mesure les précisions données par le Product Owner, mais également des éléments de solutions techniques émergeant des discussions entre développeurs. Ce point est souvent négligé. Je l'ai souvent constaté, ces moments d'échanges amènent naturellement l'équipe vers un début de réflexions techniques et il est souvent dommage de perdre ces informations qui feront gagner du temps par la suite ...

Une fois toute les histoires en place, nous les avons passé en revue 1 par 1, de gauche à droite, pour vérifier leurs positionnement relatifs. Ensuite nous avons mis des chiffres, en partant de 1, et tout comme dans l'atelier de Benoit, naturellement, les écarts se sont creusés pour être proche de la suite de Fibonacci ( 1, 2, 3, 5, 8, 13, ... ?).

Bilan

En très peu de temps, nous avons pu estimer une bonne quantité d'histoires, avec un résultat recevant un bon indice de confiance de toute l'équipe ("Give me five") et permettant d'avoir une certaine visibilité sur le projet.

Les plus :

• rapidité
• aspect ludique
• participation collaborative de tous, naturelle et immédiate
• échanges riches et constructifs

A améliorer :

• mise en évidence des valeurs métiers de chaque histoire : nous n'avions rien mis en place pour cela, le Product Owner connaissant très bien son backlog et le ROI de chaque histoire, mais l'idée de Benoit (bandes de couleurs) est intéressante
• ... certainement plein d'autres choses dont je ne me souviens plus à ce jour ... ;-)

Scrum Day France (Part 3)

"ScrumMasters, devenez le coach de votre équipe agile" par Véronique Messager

(Type : vidéo et diaporama mixés)

En introduction, Véronique évoque une révélation que j'ai eu moi aussi : la réponse que les méthodes agiles apportent lorsqu'on cherche (cherchait) une approche plus "humaine" dans la gestion de projet. J'ai pris conscience de cela au bout de pas mal de temps : l'approche et l'organisation qui m'étaient proposées pendant des années ne me convenaient pas, l'agilité a pointé ce qui manquait : l'aspect humain ...

Véronique rappel quelques points importants avec des variantes ou point de vue qui m'ont intéressé :

• Le ScrumMaster protège l'équipe, de l'extérieur bien sûr, mais également des siens, des membres de l'équipe
• Parmi les valeurs poussées par l'agilité, le droit à l'erreur, pas assez mis en avant
• L'équipe s'engage sur les résultats, le ScrumMaster s'engage sur les moyens (moyens pour l'équipe de tenir ses engagements, notamment moyens techniques)

Comme souvent, la question : le ScrumMaster peut-il être un responsable hiérarchique ?

Véronique précise que c'est un débat, mais n'y répond pas. Personnellement, malgré mon pragmatisme, je suis assez formel : par expérience, il faut absolument éviter que le ScrumMaster soit un responsable hiérarchique. Pour obtenir la concrétisation de valeurs comme Transparence, Confiance, Ouverture, etc ..., pour obtenir l'affichage par les équipiers de leurs faiblesses pour qu'ils expriment leurs difficultés du moment lors de la mêlée quotidienne, il ne faut pas que le ScrumMaster soit hiérarchique !

Autre sujet abordé, pendant la présentation, mais également, pendant les Questions/Réponses : le ScrumMaster est-il un ancien chef de projet. Véronique dit qu'elle constate que c'est souvent le cas. Je pense que c'est possible, il n'y a rien qui s'y oppose, mais ça ne doit pas être systématique : un chef de projet peut très bien devenir (Proxy) Product Owner, notamment s'il a une bonne compétence métier et relationnel avec le client. L'important est que le ScrumMaster soit à l'écoute des équipiers et dans la communication, un chef de projet trop habitué à un rôle directif aura du mal avec cette approche très humaine, en "position basse" comme dit Véronique. J'y reviendrai dans un autre billet ...

Véronique a un point de vue intéressant sur le rôle de ScrumMaster : qu'il adopte une posture de "coach". Je pense que le rôle de "coach agile", comme je peux le faire en indépendant extérieur à l'entreprise, est une mission bien spécifique et différente de ScrumMaster. Mais en écoutant la suite de la présentation, je comprends ce que Véronique veut illustrer à l'auditoire pour lui faire sentir ce rôle de ScrumMaster :

• Faire en sorte que chacun (individu ou l'équipe) trouve lui-même la solution à ses problèmes
• Non pas intervenir sur une problématique mais plutôt sur la façon dont l'équipe appréhende et traite cette problématique

Véronique insiste ensuite sur ce que cet aspect humain implique pour le ScrumMaster :

• Connaissance de soi et contrôle de soi-même
• Connaissance (humaine et non privée) des autres
• Relations entre les personnes
• Prise en compte des émotions de chacun

Selon les situations et les contextes, une "charte" au sein de l'équipe peut-être intéressante comme cadre, notamment en cas de relations difficiles.

Obligé d'accélérer sur la fin de sa présentation, Véronique aborde rapidement des points souvent délaissés, voir inconnus, et pourtant très importants à intégrer pour le ScrumMaster (et finalement tous les acteurs) :

• La notion de deuil qui accompagne souvent les changements nécessaires pour chacun (développeurs, managers, ...), la prise en compte du cycle de deuil, et l'accompagnement au changement nécessaire (coaching)
• La notion de cycle de vie d'une équipe (Création, Turbulence, Harmonisation, Performance, Séparation) impliquant une équipe stable où les acteurs apprennent à travailler ensemble

Dernier point noté qui ouvre le rôle de ScrumMaster : ce dernier intervient à différents niveaux :

• Individu : accompagnement au changement, adaptation individuelle à l'agilité de chacun
• Équipe : permettre la meilleure transformation "de groupe" vers l'agilité
• Organisation : dynamique globale nécessaire, évangélisation dans l'entreprise

Scrum Day France (Part 2)

Retour sur une autre présentation que j'ai visionné

Pratiques avancées des tests avec Nathaniel Richand

(Type : audio sur diaporama sous forme de video)

Nathianel attaque fort avec 2 qestions qui interpellent (tests des messages dans les exceptions et des messages dans les logs), en rappellant qu'il faut rester pragmatique selon le contexte !

Outre le TDD evidemment très intéressant, Nathianel évoque les tests qui vieillisent mal (notamment par la mise en commentaire des vérifications "assert"), et le fait que le TDD peut devenir un frein en augmentant la rigidité du code.

Il propose donc 2 axes pour éviter cela :

• augmenter la lisibilité
• diminuer la fragilité

Pour augmenter la lisibilité :

• choisir des noms explicites pour les méthodes de tests en donnant le contexte et l'intention
• ne pas masquer les informations utiles, qui peuvent par exemple venir de fichiers XML non visibles dans le code de test (cf DBUnit ou Unitils)
• masquer tout ce qui est inutile en utilisant les Setup, les Teardown, les import static, du code "Fluent interface" avec le pattern builder, etc ...
• éviter les "try/catch" avec "fail()" en remontant simplement les potentiels exceptions (throws sur les méthodes de tests) idem pour les "if/else" avec "fail()"
• éviter les messages explicites en début d'assert en utilisant des tests natifs ou des bibliothèques favorisant l'affichage les messages d'erreur (cf FestAssert)
• éviter des nombres et textes dans le code de test, utiliser des constantes, y compris pour des paramètres à null
• garder la même structure pour tous les tests, comme par exemple "Given/when/then" proposé par Nathianel, ou plus perso pour moi, "Préparations/Tests/Vérifications", ce qui a en autre l'avantage de pousser le développeur à ne faire qu'un test par méthode
• soigner ses assertions, notamment en utilisant les bons assert ("assertEquals" plutot que "assertTrue") et les librairies comme Festassert ou armcrest
• utiliser Spock, dont j'ai déjà parlé dans un précédent poste et qu'il va vraiement falloir que je teste !

Remarque "évidente" (...) en passant : si les tests sont compliqués, c'est que potentiellement, le code est ... compliqué ! A méditer ...

Pour rendre les tests plus robustes :

• pas de duplication de code (utiliser des fixtures, des builders, des assertions "maison", ...)
• tester un comportement à un seul endroit
• éviter la réflexion (reflect java pour tester des méthodes privées ..... bahhhhhhhh)

[NDLA] Sur ce point, je n'approuve pas l'idée de changer la portée "private" d'une méthode pour la tester, il y a d'autre solutions, notamment un changement d'architecture pour extraire cette méthode dans une autre classe testée unitairement ... éternet débat ? ...

• adapter ses tests selon que le code est bas niveau (basique) ou haut niveau (interaction entre plusieurs collaborateurs), utiliser des mocks pour vérifier le comportement global de la méthode

Je note l'idées intéressante consistant à ajouter au TDD un étape après l'étape "rouge" pour vérifier les messages d'erreurs et les rendre explicites.

Je recommande moi aussi le livre "Clean code" de Robert C. Martin traduit en Français sous le titre "Coder proprement" dont la première moitié est tout simplement pleine de bon sens !

S'en est suivi une séance de Questions/Réponses sur différents sujets :

• tests sur environnement de prod : plutôt éviter (selon contexte) !
• tests des classes abstraites : Nathianel évoque la possibilité pour le code de test d'hériter du code de test de la classe abstraite

[NDLA] Perso, j'utlise de moins en moins l'héritage et les classes abstraites, et de plus en plus l'aggrégation ;-) donc la question ne se pose plus ...

• alternatives à DBUnit : mocker les DAO, ou sur-couche DBUnit pour éviter les fichiers XML (DBUnit et Unitils n'étant plus maintenus)

Sur l'utilisation de mocks, mon approche est très différente de Nathianel qui dit les utiliser peu. Je développe depuis pas mal de temps de façon très découpée pour respecter le principe "1 classe - 1 role", et beaucoup de base d'interfaces et de collaborateurs. J'utilise donc énormément les mocks pour simuler et maitriser le comportement de chaque collaborateur pour que le test ait tout son sens, et je n'ai jamais rencontré de grandes difficultés lors d'évolutions et refactorings de code, du moins rien à voir avec l'apport d'une telle architecture !

En tout cas, une présentation intéressante, efficace, et que j'approuve entièrement, aux détails près mentionnés précédemment ;-)

2011 nri-pratiques tests-avancees

View more presentations from Nathaniel Richand

Scrum Day France - Les présentations sont en lignes !

Je n'ai malheureusement pas pu me rendre au Scrum Day France le 31 mars dernier. Mais bon nombre des présentations sont en lignes sur le site du French Scrum User Group. Merci au groupe et à Xavier Warzee !

J'avais commencé à regarder quelques présentations dès leurs mises en ligne. Voici quelques retours sur :

• Automatisation des tests : le mythe du ROI avec Gilles Mantel
• Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin
• Le Product Owner « Proxy », Bertrand Dour

Automatisation des tests : le mythe du ROI avec Gilles Mantel

(Type : vidéo et diaporama en parallèle)

En début de présentation, Gilles rappelle les différents types de tests. J'y ai découvert les Tests fonctionnels exploratoires, non automatisables, mais sujet certainement d'avenir.

Ensuite, Gilles présente la formule du ROI (=Coût des tests manuels - coût des tests automatisés) en détaillant le contenu de chaque terme. La courbe présentée ensuite montre, sans surprise, un ROI positif au bout d'un certain nombre de cycles d'exécution, le point de début de rentabilité pouvant être atteint au bout de 2 à 3 ans (période d'investissement au bout de laquelle on ne gagne rien !). Pas motivant ...

Gilles met donc ensuite le doigt sur le fait que dans cette approche très mathématique et financière, on oublie bon nombre d'intérêts des tests automatisés comme par exemple :

• la possibilité de lancer les tests plus souvent, y compris la nuit, sans nécessité de disponibilité de ressources humaines
• des retours (feedbacks) plus rapides
• le coût des anomalies

Gilles détaille ce dernier point avec des graphes très intéressants mettant en évidence que plus une anomalie est découverte tard, plus elle coûte chère, évidemment. Mais un critère supplémentaire très important est la phase à laquelle l'anomalie a été créée : plus une anomalie a été introduite tôt dans le process (par exemple architecture, design, ...), plus elle va coûter chère, le tout étant accentué si elle est découverte tard !

La suite de la présentation reste très théorique en se basant sur le modèle de gain d'une option d'achat. Mais cette approche m'a enfin permis de comprendre pourquoi, en contexte agile, j'ai souvent été moins motivé à mettre en place des tests sur le GUI (par exemple) : tout simplement parce que par expérience, il y avait peu d'anomalies dans cette partie des logiciels, donc un ROI pressenti moins intéressant !

Gilles présente également un graphe très intéressant, de Scott Ambler, qui a fait une projection des pratiques, agiles ou non, sur la courbe de coût d'une anomalie, excellent ! Avec là aussi une mise en évidence d'un ROI, pour l'automatisation des tests, moins intéressant en contexte agile.

Conclusion : commençons par passer à des pratiques agiles, et les tests, ça vaut le coup à bon escient.

Une présentation que j'ai beaucoup apprécié, à voir !

Automatisation des tests: le mythe du ROI

View more presentations from gmantel

Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin

(Type : audio sur diaporama sous forme de video)

Après une introduction sur une première raison d'échec, Alex anime sa présentation sur base du serious game "Buy a feature" (cf Innovation Game), en proposant 12 raisons d'échec de Scrum à acheter par les participants, raisons basées sur des exemples concrets vécus.

Parmi les sessions présentées :

• Une seule personne ! : cas d'une personne malhonnête et méchante, ayant beaucoup de pouvoir
• Casting du PO : une situation où tout semble parfait sauf que le PO n'était pas le bon, plus gestionnaire que visionnaire (pas impliqué), et non maitre des aspects financiers
• Contrat agile : j'en retiens trop de contractualisation, trop d'adaptations de Scrum, trop de difficultés liés aux distances, aux mélanges d'équipes agiles ou pas, ...
• Mission impossible : avec la blague de Ken Schwaber qui conseille à un ami, ayant un projet impossible, d'opter pour ..... la méthode Waterfall ! Scrum mettrait "trop" vite en évidence l'aspect impossible du projet
• Les Geeks : échec d'un projet à cause des geeks, excellent techniquement, qui se font plaisir, mais pas du tout ouvert sur le métier. Personnellement, je me considère comme geek, par l'aspect passion, ou du moins, je me sens proche des geeks. Et je les perçois plus comme une réserve d'énergie et d'innovations. Je ne partage donc pas le point de vue d'Alexandre. Mais je comprends bien la raison d'échec de ce projet, plus dû à des développeurs renfermés sur leur focus technique, sans intérêt pour le métier. Et cela m'amène une question : quel est le rôle du coach agile et/ou du ScrumMaster dans une telle situation, intéressant ...
• Micro management : présence d'un manager hiérarchique trop présent sur l'équipe, avec des pratiques incompatibles avec Scrum (déplacement des post-its, affectation des tâches, suivi du consommé, ...) et donc un ScrumMaster avec un rôle très réduit. Bilan : passivité et désengagement de l'équipe, Scrum devient impossible !
• Multiples PO : présence réelle de plusieurs PO avec une répartition officielle (documentée) des rôles de chacun, rôles très répartis, aboutissant à un auto-blocage dans les décisions

Un rappel important au passage : l'agilité, avant tout, c'est un état d'esprit !

Une présentation intéressante (même si j'ai des différences de points de vue sur les geeks et les ScrumMaster qu'il est bon de faire "ramer"), avec une forme agile à différents points de vue. Évidemment, Scrum, ça fonctionne "presque" tout le temps, et il est intéressant et enrichissant de se repencher sur les raisons d'échec pour les comprendre et les éviter à l'avenir. Ce que j'ai pas mal fait personnellement ces derniers temps.

La conclusion est importante,puisqu'en général, ce n'est pas la méthode qui ne marche pas, mais son application, les limites de l'organisation, et les personnes concernées.

Le Product Owner « Proxy », Bertrand Dour

(Type : audio sur diaporama sous forme de video)

Une présentation rapide suivant d'une longue séance de questions/réponses. Malheureusement, difficile d'entendre toutes les questions, mais les réponses restent intéressantes ...

Bertrand présente le contexte de la mise en place,  chez PMU, pour 3 métiers différents, d'une structure agile sur base de 2 équipes de 4-5 personnes (permet de répondre à 2 thématiques à chaque sprint), travaillant sur 1 seul product backlog multi-activités, avec la présence d'un Product Owner Proxy dont Bertrand rappelle l'intérêt :

• Un interlocuteur unique
• Une gestion des priorités consolidées
• Une planification de release cohérente

Bertrand lisse les problèmes et solutions :

• Expertise métier : mise en place d'implication forte des experts métiers, vocabulaire commun et granularité similaires entre les métiers
• Gestion des priorités : 
• vrais jetons de pocker pour les valeurs métier (Business values)
• augmentation de la transversalité entre métiers : fédération et collaboration
• créations d'événements : démos au PO et aux personnes avec qui le PO est en contact, ateliers (écritures d'histoire, gestion du backlog, ...)

Bertrand dresse ensuite un bilan sur la mise en place de ce Proxy PO, que je complète avec les questions/réponses :

• Avantages : gestion du besoin consolidé et interlocuteur unique, échanges transversaux entre métiers (ouverture)
• Difficultés : connaissance métier (atelier indispensables), légitimité du PO, complexité du processus, Proxy PO avec pouvoir d'arbitrage mais sans pouvoir de décision (obligation de consulter la hiérarchie)

Les questions/réponses ont également permis de couvrir d'autres points plus généralistes sur l'agilité et Scrum : open space, évangélisation de l'agiliité au sein de toute l'entreprise (pas facile, comme souvent), etc ...

Une conclusion intéressante : un PO Proxy ça marche, mais commencer par essayer d'améliorer d'abord l'organisation ...

Le Product Owner proxy, Bertrand Dour

View more presentations from Xavier Warzee

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.