Ce coup-ci, je m’y mets tout de suite, sans traîner comme pour celui de Rennes. Comme ça, les idées seront fraîches…
Keynote
On attaque en musique avec une session très exotique, où une vingtaine d’extraits de musiques sont passés, puis le conférencier nous explique comment les paroles lui rappellent quelques fondements de l’agilité. Intéressant, car on retrouve des notions. Par contre, peut-être un peu ardu pour ceux qui ne connaissent pas le vocabulaire agile ou Scrum. Et pour ceux qui connaissent, c’est fun, mais ça n’apporte pas réellement une connaissance supplémentaire.
Lean Agile Camp
Dominique de Premorel nous explique comment elle a fait le grand saut d’Agile à Lean. Très approfondi comme approche, avec des exemples du terrain. Cela confirme bien la première impression que j’avais eue à Rennes sur le fait que Lean est une approche plus holistique que Scrum par exemple. Pas nécessairement que l’agilité au sens large, car l’agilité, ce sont des valeurs, qui peuvent être appliquées sur le Lean qui est une structure d’apprentissage.
Mais là où Scrum peut buter car on n’est que dans l’exécution d’un projet, Lean peut apporter la réponse en donnant le recul nécessaire, et en faisant se poser la question de ce dont a réellement besoin notre client. Si ça se trouve, ce n’est pas d’un produit qu’il a besoin, mais d’une formation, d’une nouvelle méthode. Et dans ce cas là, exécuter parfaitement un produit ne servira à rien. Je reviens sur cette phrase qui m’avait marquée à Rennes : Scrum, ça peut très bien servir à exécuter parfaitement un projet qui est inutile.
LeanAgileCamp.fr pour retrouver le livre écrit par Dominique, Christophe Kéromen qui organisait également, et huit autres agilistes.
La phrase du jour
Scrum est comme une belle-mère : elle met le doigt là où ça fait mal, mais c’est pour notre bien.
Urbanisation des SI : l’agilité au niveau du SI
On remet sur le métier notre ouvrage avec Johan Le Lan. Nous avons tenu compte des feedbacks de la première session de cette conférence à Rennes, mais malheureusement peut-être un peu trop, car nous avons glissé sur le temps, et la conclusion s’est faite un peu rapidement. Nous le saurons pour être nickel à Nantes la semaine prochaine 
Merci à Nicolas Ledez, qui présentait juste après nous, de nous avoir offert ce petit souvenir :
Y sont pas chers, mes tests !
Justement, donc, je suis allé voir Nicolas Ledez, juste après. Notre schizophrène de service (ce n’est pas moi qui le dit, c’est lui) nous a gratifié au passage du record du monde de retard dans la fin de sa conférence . Mais on lui pardonne, parce que c’était super intéressant, et parce qu’on a quand même réussi à manger quelque chose après…
La conférence était axée sur le Test Driven Development, et permettait de bien remettre au clair les pratiques. Ca m’a permis de remettre au clair ma pratique, et de mieux comprendre le problème que j’ai avec la couverture de code. Je me demandais quelle était le bon pourcentage, et la réponse de Nicolas est sans équivoque : 100%.
J’ai souvent ce problème, car je travaille sur du code en partie créé avant qu’on connaisse l’importance des tests unitaires (et même pour une partie de notre code, avant qu’on connaisse l’existence même de ce type de tests). Et dans ce cas, on essaie de rajouter du test après, et en fonction de l’importance du code, on se limite à 20% en espérant l’effet Pareto, ou on monte à 80% et ça nous paraît déjà énorme. Mais j’ai compris ce que Nicolas expliquait : quand on part sur du TDD, il faut dès le début être à 100% et s’y tenir. C’est ce qui garantit qu’on ne se trouvera pas dans une situation qu’on ne peut pas remonter plus tard.
En TDD, il ne faut surtout pas oublier de ne jamais refactoriser le code en même temps que les tests. Les tests représentent beaucoup de code mais peu de temps, tandis que l’implémentation, c’est l’inverse : beaucoup de réflexion pour un peu de code.
Une question sur le Coding Dojo ? Qu’à cela ne tienne, Nicolas sort directement la présentation qui va bien et nous la fait au pied levé ! Et la référence qui va bien avec : codingdojo.com pour le katacatalogue. Bon timing pour les randori : 7 minutes.
Et pour finir, Nicolas nous rajoute une référence de livre intéressant, à savoir Trust Driven Development, par Noël Rappin.
Atelier de sociocratie
Intéressante approche que la sociocratie. Le concept d’élection sans candidat m’avait interpelé, et je voulais en savoir plus sur cette pratique, donc je suis allé voir l’atelier de fin d’après-midi.
L’atelier faisait la part belle au cercle, c’est-à-dire la méthode de prise de parole les uns après les autres, dans l’ordre du cercle autour duquel on est assis. Les objections sont traitées de manière la moins conflictuelle possible, à savoir l’expression d’une objection, la proposition d’une résolution, et si celle-ci permet de lever l’objection, on continue.
L’approche m’a semblé un peu difficile à mettre en place sur des questions ouvertes, et je pense qu’elle doit fonctionner au moins lorsque le sujet est relativement contraint. Une des idées est de ne pas chercher à tout prix un consensus qui laisse chacun finalement peu satisfait, ni de voter pour trancher sur une proposition, mais de faire émerger par une approche méthodologique de la parole une idée qui pourra convenir à tout le monde.
Conclusion
Un peu moins de monde cette année que la précédente, mais les organisateurs se sont encore une fois bien débrouillés. Et le buffet de l’Agile Tour Vannes est sans conteste le plus original et le meilleur de toutes les conférences auxquelles je sois jamais allé
