Lundi et mardi dernier se tenait la Conférence Agile France 2010. Mon but dans ce billet, cher lecteur, est de ne pas te faire perdre ton temps. Je vais donc partir du postulat que tu ne veux pas savoir tout ce qu'il s'est dit, mais ce que j'ai pensé et retenu des sessions auxquelles j'ai assisté. Tout ceci se fera donc en toute subjectivité.

PNL (Programmation Neuro Linguistique) - Bruno Sbille

Le triangle dramatique, composé de la victime, du sauveur et du persécuteur, est intérressant. J'y ai retrouvé plusieurs situations familières. Les points à retenir, c'est qu'on peut tour à tour endosser plusieurs de ces tempéraments et que, quoi qu'il arrive, ils sont tous à bannir d'une équipe, même le sauveur.

DDD (Domain Driven Design) - François Wauquier et Nicolas Martignole

Mon but était essentiellement de préparer une présentation similaire à l'Agile Tour Bordeaux. Je pense qu'ils sont allés un peu trop loin en voulant parler des patterns stratégiques et qu'ils n'ont pas assez creusé les points de recouvrement avec XP. Mon sentiment est donc mitigé sur cette présentation.

Commencer petit pour finir grand : l'art de la construction incrémentale - Étienne Charignon

J'ai beaucoup apprécié cette session présentée avec humour et fébrilité. Des dessins des enfants d'Étienne apportaient notamment une touche humaine.

Il a introduit le concept des abstractions qui fuient. Le terme "fuir" est une traduction de leaky mais il a aussi pensé à "transpirer", que j'aime bien, parce que la transpiration, ça pue. L'idée est que les abstractions posent parfois problème car on doit se préoccuper de ce qui est derrière. Enfin c'est ce que j'ai compris. Ce que je ne suis pas certain d'avoir compris, c'est le rapport avec la conception incrémentale. Mais c'était bien. J'ai aussi retenu qu'on devait se satisfaire de son niveau de connaissance de confort. À défaut, on se retrouve très vite dépassé.

10 leçons apprises en rétrospectives - Stéphane Hanser et Emmanuel Gaillot

C'était une piqure de rappel bienvenue sur l'importance des fondamentaux. Les plus importants selon moi :

  • avoir un processus stable permet d'expérimenter,
  • il est très important de clarifier les positions de l'équipe sur des sujets polémiques qui se transforment régulièrement en bataille rangée entre deux protagonistes virulents,
  • il faut garder des tests automatisés légers, quitte à mocker ou sortir les tests d'intégration,
  • afficher une ou deux pistes d'amélioration par itération,
  • rester volontairement vocalisé, notamment en diminuant les blagues et autres digressions au moment des rétros et des démos,
  • intégrer le remboursement de la dette au processus de développement,

Agilité sous contraintes - David Brocard

Je passe. Rien à retirer.

Kata Robozzle en Haskell - Emmanuel Gaillot

Super moment passé à regarder Emmanuel développer ce kata. Propre, sans bavure. Je ne connaissais pas du tout Haskell et je ne me suis pas senti perdu un instant.

Self-help for Self-Organising Teams - Esther Derby

Je ne suis pas sûr d'avoir pu retirer tout ce que je pouvais de cette keynote car elle était en anglais, et c'est chaud de rester concentré. J'ai retenu que les équipes heureuses l'étaient toutes la même façon (petite, approche commune, humaines...) tandis que les équipes malheureuses l'étaient chacune à leur façon. Dans ces dernières, on retrouve souvent des schémas répétitifs qu'il faut casser et le premier endroit où commencer, c'est soi-même.

Satisfaire complètement son client avec le Problem Driven Development - Régis Médina

Comment résumer une heure de pur plaisir ? Allez, je me lance. Les méthodes agiles, c'est mieux que le cycle en V MAIS, il faut, en plus de faire un logiciel qui fonctionne, faire un logiciel qui satisfait le client. Il ne faut donc pas faire littéralement ce que dit le client, sinon on fait une usine à gaz. Une première idée intéressante est donc de demander à son client, pour chaque histoire livrée 1) si elle est conforme à sa demande et 2) si elle le satisfait. Attendons-nous à des surprises. Le métier du client n'est pas le développement et il est donc de notre ressort de pouvoir le conseiller et de lui apporter des solutions à son problème. C'est le principe du Problem Driven Development (PDD) : résoudre complètement le problème du client. Pour cela deux principes :

  • PDCA,
  • le gemba : réflexe d'aller voir dans les faits.

Il est important de savoir ce que veut réellement le client. D'une manière générale, il ne veut pas qu'on lui fasse perdre son temps (muda) et que la solution qu'on lui apporte lui permette de réduire son lead-time (temps d'utilisation du système pour un problème donné). Il faut que ce temps soit le plus court possible : "No service is good service". Finalement, il y a un déplacement de l'approche "on ajoute de la valeur" à "on résoud efficacement son problème". Régis a ensuite longuement parlé de l'importance de mesurer, de voir, de constater par soi-même grâce à des tests d'utilisabilité. Tout cela m'a rappelé les propos de Steve Krug dans "Je ne veux pas chercher". Enfin, il nous a parlé des deux malédictions qui pesaient sur nous, pauvres développeurs :

  • malédiction de la connaissance : nous connaissons trop bien notre système pour nous mettre à la portée de ses utilisateurs,
  • mélédiction de l'ignorance : nous ne connaissons pas assez bien le problème de l'utilisateur.

Bravo Régis, super présentation.

Consensus workshop - Thi Lan Huong Le

Il s'agissait d'un atelier pendant lequel nous avons mis en oeuvre une méthode pour répondre à une question très ouverte. Je résiste pas à l'envie de mettre une image qui résume la méthode :

Le consensus reste cependant assez frustrant sur un plan individuel même s'il faut reconnaître l'efficacité pour obtenir une réponse...consensuelle.

Le modèle d'acquisition des compétences de Dreyfus - Emmanuel Hugonnet

J'ai retenu la définition de cinq profils : le novice, le débutant avancé, le compétent, l'efficace et l'expert. Tout cela était présenté autour d'une métaphore sur la conduite automobile. Emmanuel a beaucoup insisté sur l'importance de ne pas forcer les experts à suivre des règles car cela est contre-productif pour eux qui fonctionnent à l'instinct et qui doivent pouvoir casser les limites pour innover.

Réussir ses projets à coûts, délais, périmètres et qualité fixes - Bernard Notarianni

Quand on prône un changement fort, ça grince. Bernard a voulu une session dynamique en laissant la parole à qui voulait la prendre. Et les débats ont fusé. La solution qu'il propose est très intérressante : le client fixe le délai et le coût, les développeurs définissent le périmètre et la qualité qui, évidemment, est au maximum. Le prérequis pour que ça marche est que les développeurs soient en contact avec le client. Le problème, c'est qu'on ne peut prendre n'importe quel développeur pour ça. Une des idées que j'ai trouvé pertinente, c'est que les développeurs peuvent, s'ils ont besoin, s'adresser à une équipe d'expert métier qui n'est pas en frontal avec le client et qui vient donc en support des développeurs. Le client n'est en effet pas forcément un expert du métier.

Conclusion

Ces deux journées ont été intensives mais valaient le coup. Pour résumer, je retiens trois leçons :

  • les agilistes renommés sont des valeurs sûres,
  • je vais m'intéresser au lean prochainement,
  • je me ferai quelques katas en programmation focntionnelle, juste pour voir (haskell ? clojure ? ocaml ?).