Agile Tour Bordeaux 2012 : j'y étais

Toi aussi tu y étais

Voici mon petit compte-rendu en "Agilarium-style".

Ce qui était bien

  • La keynote de Samir Hanna. Keynote n'est pas un synonyme pour "session plénière qui ouvre ou clôture". La keynote, comme son nom l'indique, c'est ce qui donne le ton pour ce qui va suivre et la courte introduction de la journée mettant en avant des valeurs était, en ce sens, la bienvenue.
  • What Testers and Developers Can Learn From Each Other par David Evans. Un véritable appel à la réconciliation des développeurs avec le test sous toutes ses formes et un orateur vraiment au dessus du lot.
  • Tests automatisés, le mythe du ROI par Gilles Mantel. Une taxonomie des tests très détaillée (peut-être un peu trop pour mon goût de la concision) mais surtout une modélisation du ROI des tests automatisés sur un principe d'option d'achat qu'il faut avoir vu avant d'émettre le moindre avis sur le sujet.
  • La voie du programmeur par Jean-Baptiste Dusseaut. Ma session préférée parce qu'elle aborde plein de thèmes qui me tiennent à coeur sur une question fondamentale : comment devient-on un professionnel du développement logiciel ? Elle devrait être imposée dans tous les agile tours de France et d'ailleurs.
  • Sociocratie: une gouvernance agile par Thierry Cros. J'ai encore du mal à voir comment cette idée disruptive peut prendre de l'ampleur dans le contexte actuel mais comment ne pas faire confiance à quelqu'un qui a senti la lame de fond du mouvement agile dès ses débuts ?
  • La soirée qui a suivi mais vous ne saurez rien : il fallait être là.

Ce qui était moins bien

  • La densité des sessions de l'après-midi. Quatre sessions en quatre heures, c'est un peu trop. Du coup, j'ai zappé le dernier créneau qui ne manquait pourtant pas d'interêt avec les sessions d'Isabel, Jérôme et Jonathan.
  • "Utilisateur mon amour ma migraine" par Sophie Freiermuth. De mon point de vue, la session fut à côté de la plaque sur l'aspect méthodes agiles. Des notions mal utilisées : quand on retravaille un existant, on fait de l'incrémental, pas de l'itératif ; une user story n'est jamais une spec détaillée, c'est au plus une invitation a discuter... Les plus gros travers restent cependant le BDUF omniprésent (le développeur est content quand on lui apporte une spec hyper détaillée et qu'il n'a pas à se poser trop de questions sur ce qu'il doit coder), la communication érigée en non-valeur ("le designer n'est pas intéresse par le code" - et donc il n'a aucune raison d'aller s'asseoir à côté du développeur) et l'hyper-spécialisation ("un développeur c'est quelqu'un qui résout des problèmes techniques" - qu'il ne se mêle pas de choses qui le dépassent !) Je suis pourtant convaincu qu'il y a une marge de progression énorme en User eXperience pour la plupart des produits logiciels mais il faut une approche qui colle avec un développement logiciel professionnel. A noter : je n'ai pas encore vu cette session de Sophie Freiermuth à Mix-IT qui, parait-il, était très bien.
  • Comme dans toutes les conférences de ce genre, il est impossible de voir toutes les sessions et j'ai donc surement raté des trucs intéressants.

Les questions (que je me suis) posées

  • Tests UX, tests exploratoires, tests de sérendipité ne sont-ils pas tous assimilables à des explorations au sens où même si on a une idée en tête, on ne sait pas vraiment où on va ?
  • Peut-on écréter la pyramide des tests de Mike Cohn ?
  • Y a-t-il des maîtres de l'artisanat logiciel et où sont-ils ?
  • Qui sera le premier à écrire un recueil de citations de Kent Beck ?
  • Peut-on être expert en développement logiciel à la sortie d'une école ? (nan j'déconne)
  • Les loldogs existent-ils ? (la réponse est oui)

Les lecons (re-)apprises

  • Une présentation devrait toujours commencer par un gag visuel
  • Ce n'est pas en rajoutant des tests que le logiciel devient de meilleure qualité
  • L'activité de test n'est jamais terminée, elle n'est qu'arrêtée
  • Les testeurs sont nos amis
  • Un ami, c'est celui qui aide a démenager un divan ; un meilleur ami, c'est celui qui aide a déplacer un corps...
  • Mettre en place des tests automatisés, c'est payer une prime limitée pour un gain potentiellement infini
  • Il faut nourrir sa passion
  • Le coding dojo, c'est comme le fight club : quand on y vient, il faut coder[1]
  • Pas de commentaires dans le code

Remerciements

  • Merci aux organisateurs : Bastien, Florian, Samir, Jérôme, Mickaël et Guillaume.
  • Merci à toutes les personnes qui m'ont dit avoir apprécié ma session. C'était, comme d'habitude pour cet atelier, un peu le bazar par moments mais je pense que tous ceux qui se prennent au jeu en retirent forcément quelque chose - et moi aussi par la même occasion car, malgré le thème et les attentes imposées, c'est à chaque fois différent.
  • Et merci à tous les autres sans qui cet évènement n'aurait pas été ce qu'il a été.

Ils en parlent aussi

Pour aller plus loin

Notes

[1] dans le vrai fight club, cela n'est vrai que la première fois où l'on y vient - et de toutes façons on ne doit pas en parler