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.