Global day of code retreat

Ce samedi 14 novembre, à l’initiative de Jérémie et de l’association Nord Agile, se déroulait dans nos locaux l’édition Lilloise du Global day of code retreat.

Le GDCR est une journée mondiale durant laquelle des développeurs se réunissent pour améliorer ensemble leurs skills.
Cette année, plus de 140 événements ont été organisés à travers le monde : http://globalday.coderetreat.org/timeline-2015.html

Pourquoi un Code Retreat ?

Beaucoup de développeurs, pendant leurs études ou durant leur vie professionnelle, apprennent des langages de programmation / frameworks / outils.
Mais il n’y a pas ou peu de choses pour apprendre pas à bien coder. Combien de personnes ont déjà suivi une formation « Améliorer la qualité / maintenabilité de son code » ? Pourtant cela coûte cher ! (1)

Le principe du code retreat, c’est justement d’essayer de lever la tête, sortir de son quotidien pour travailler ça.

Comment ça fonctionne ?

Tout au long de la journée, des binômes travaillent par sessions de 45 minutes sur l’implémentation d’un jeu : Le Jeu de la vie.
A l’issue de la session, on efface le code et une rétrospective est menée pour partager les expériences et trouvailles de chacun.
Puis changement de binôme et on recommence avec des contraintes différentes : interdiction de parler, mode ping-pong, pas le droit d’utiliser de « IF », …

Quels enseignements ?

Certains seront sceptiques quant à l’apport réel d’une telle journée et pourtant… sortir de sa zone de confort, ça incite sacrément à la remise en question et à l’ouverture d’esprit !

Code Retreat en action !

Code Retreat en action !

Cette journée, c’est comme vivre plein de petites revues de code en accéléré, avec une mise en pratique immédiate.
Changer de binôme tout le temps permet aussi de découvrir d’autres langages de développement, IDE, méthodes de travail.

Pour aller plus loin : software craftmanship

KPI : 100% de gens satisfaits !

(1) http://www.nist.gov/director/planning/upload/report02-3.pdf – The Economic Impacts of Inadequate Infrastructure for Software Testing

Agile Tour Lille 2015 (Partie 1/2)

Ce 15 octobre 2015 avait lieu la 8ème édition de l’Agile Tour Lille. C’était une excellente journée riche en retours d’expériences, approches différentes et comme toujours lors de ce type d’événement, en rencontres enrichissantes.

Cette année, l’Agile Tour Lille comptait 400 inscrits et 120 personnes en liste d’attente ! Et effectivement, on se sentait parfois un peu à l’étroit dans les salles jusqu’à suivre une conférence assis par terre 😉 Concernant l’accueil j’ai adoré l’idée du badge de la conférence qui contient un plan des lieux et le planning de la journée : c’était juste parfait.

La journée a commencé sur les chapeaux de roues, avec 30 secondes et un slide par speaker pour présenter leur conférence. Et le choix ne fut pas simple !

Pour ma part j’ai suivi les conférences suivantes :

  1. Des lean startups dans l’administration !? – par Pierre Pezziardi
  2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain
  3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry
  4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud
  5. L’estimation, un formidable outil de discussion, même pour les projets #NoEstimate – Par Sébastien Delest
  6. Le Kanban expliqué par Bison futé – Par Cyrille Deruel
  7. Alliés contre les défauts – pourquoi et comment nous relisons ensemble le code que nous produisons – Par Julien Jakubowski et Antoine Blancke
  8. Intégration continue, DevOps et après ? – Par Laurent Tardif

Je vous propose d’en extraire ici quelques idées.

1. Des lean startups dans l’administration !? – par Pierre Pezziardi

Pierre nous parle de son expérience et de ce qu’il réalise en lean management pour le Secrétariat Général à la Modernisation de l’Action Publique.

Il évoque les difficultés de travailler avec les systèmes environnant particulièrement lourds et complexes de l’administration. Il nous révèle une technique redoutable pour estimer la charge d’un projet : systématiquement, c’est 6 mois pour 4 personnes, avec un objectif précis en tête (exemple : un taxi en un clic !)

Pierre évoque aussi la difficulté d’être innovant dans une organisation fortement ancrée dans des procédures dont la relative efficacité est éprouvée depuis des années. Être disruptif avec les procédures habituelles, c’est comme proposer une interface web pour remplir un formulaire Cerfa, ça fonctionne, mais l’efficacité n’est pas là.

Il indique également qu’une petite équipe de 50 personnes ne peut pas bouleverser une structure de 4000 personnes du jour au lendemain. Il faut gagner la confiance, convaincre et propager une nouvelle culture de travail.

Pour être plus efficace, il propose de s’isoler au maximum des processus existants, quitte à garder des tâches manuelles. En effet, si une nouvelle fonctionnalité est utilisée une centaine de fois par jour et demande une action manuelle du côté administratif, au moins dans un premier temps, ça peut être acceptable et permet d’avoir la fonctionnalité en production très tôt.

Pour ouvrir l’Agile Tour, cette conférence était a point nommé, un véritable retour d’expérience sur l’efficacité de l’agilité là ou l’on ne l’attendait pas : dans l’administration. Et Pierre est toujours très pertinent avec des propos souvent si évidents qu’on aurait trop tendance à les oublier. Par exemple, le chef : c’est l’usager !

2. Si le TDD est mort, alors pratiquons une autopsie – Par Bruno Boucard et Thomas Pierrain

Bruno et Thomas tiennent à souligner le fait que le TDD ne se résume pas au classic Red-Green-Refactor. Ce n’est que la partie visible de l’iceberg.

Tout d’abord un petit rappel de RGR :

  • Red : on écrit le test sur un code mort => il est en échec : rouge
  • Green : on implémente le minimum pour que le test passe : vert
  • Refactor : on améliore

… puis on recommence.

Voilà pour la partie visible, d’ailleurs je me permets toute de suite une petite note personnelle :

Toute personne qui s’est déjà essayé au TDD vous le dira : au début commencer par écrire un test, c’est compliqué car ce n’est pas dans nos habitudes. Quand on a une idée que l’on veut implémenter, on le fait et on a une idée relativement précise de ce que l’on doit faire. Dans notre métier les choses se présentent un petit peu différemment : il s’agit d’implémenter ce que quelqu’un d’autre a en tête ! Et parfois même plusieurs personnes… Finalement, se poser la question de savoir ce qui m’est demandé, avant même de savoir comment y répondre parait beaucoup plus légitime. Voilà ce qu’apporte le TDD dans un premier temps : s’assurer que nous répondons à la bonne question ! A condition bien sûr, de trouver la question…

Mais revenons donc à la conférence. Thomas et Bruno font remarquer que voir sa liste de test validée fait partie des satisfactions de la journée. Le fait d’écrire un premier test devient quelque chose de simple et un vrai coup d’épaule pour démarrer. Une lutte efficace contre la procrastination. Ils insistent également sur la nécessité de s’entraîner en rappelant la théorie des 10000 heures de Anders Ericsson. Il évoque par exemple les codes kata, et les coderetreats. D’ailleurs à ce sujet le prochain Global Day of Code Retreat (CRTGD) à lieu chez Salto le 14 novembre!

Enfin quelques idées sont soulevées :

  • Commencer par les tests c’est difficile, il n’y a pas de design émergeant. En effet commencer par les tests impose de s’imprégner de son sujet, d’en discuter avec les différents interlocuteurs pour bien décomposer les choses. La technique du « should » est mise en avant, il s’agit de parler de comportement, pas d’une API.
  • Il ne suffit pas d’écrire beaucoup de tests. Au contraire, trop de tests rendent la maintenance difficile. Il ne s’agit pas de tester des méthodes, mais des « gestes métier ». Il faut donc rester haut niveau. C’est la couverture de test qui importe, pas la quantité.
  • TDD est-il vraiment efficace ? Oui ! par essence même, on ne test que ce qui est demandé et on écrit alors le minimum de code qui répond au besoin. Pas de sur-conception ou d’hypothèse hors spécification. On rappelle ici les bases : YAGNI (you ain’t gonna need it) et KISS (keep it simple stupid).

Une méthode intéressante est celle de la double boucle qui consiste à faire une première boucle avec un test d’acceptance contenant lui-même plusieurs boucles de tests unitaires.

Les auteurs rappellent également la nécessité pour le développeur de connaître des design patterns et d’avoir des notions d’architecture.

En résumé, si vous ne faites pas encore du TDD, il est temps ! Et si vous avez abandonné : parfait, il est temps se s’y remettre sérieusement !

3. Construire plus vite en apprenant plus vite – Retour d’expérience du Monde.fr – Par Ismaël Héry

Ismaël Héry nous fait part de son expérience au Monde.fr. Il nous rappelle le petit miracle que représente la publication d’un journal tous les matins, et le bouleversement actuel entre la presse écrite qui décroit indéniablement et la presse numérique qui monte mais avec des profits inférieurs. Dans ce contexte compliqué, il faut avancer et s’améliorer pour rester dans la course. La spécificité des médias est aussi l’approche du délai. Lorsqu’il y a une élection présidentielle ou tout autre événement, si une application dédiée est prévue il faut qu’elle soit livré à l’heure, pas au jour ou à la semaine… Dans un tel contexte on peut comprendre que les éventuelles pénalité de retards soient infinies !

Avec de telles contraintes, il faut savoir être rapide et prendre de l’avance. Cela implique de travailler sur des technologies nouvelles, non éprouvées et pose donc certaines questions :

  • Quel temps est nécessaire à l’apprentissage ?
  • Les tests sont ils automatisables ?
  • Comment se comporte cette technologie en cas de montée en charge ?

Pour pouvoir répondre à ces questions il n’y a qu’une option, il faut mesurer et avoir un retour au plus tôt. Cela implique :

  • Expérimenter : le meilleur moyen de savoir si une solution peut répondre au besoin reste tout simplement de l’essayer.
  • Mesurer : mettre en place au plus tôt un monitoring de la solution, intégrer des bêta testeurs et en prendre soin. Ce sont eux qui vous diront si la solution est pertinente. Il faut savoir trouver des personnes bienveillantes qui seront indulgentes et d’autres plus « pointilleuses » qui vous feront beaucoup de retour.
  • Mettre en production ! : c’est ce qui apporte le plus de retour. Techniquement, au plus tôt on met en production, au plus tôt on aborde les différentes difficultés liées aux technologies choisies. De même, cela permet d’obtenir plus vite des retours utilisateurs et de décider si on doit continuer ou pas sur cette voie.

Ismaël insiste sur l’importance des avis utilisateurs. Jusqu’à mettre en place des « fakes » qui ne feraient que récupérer l’avis des utilisateurs. Il explique également qu’il faut prendre une bonne dose d’empathie. Souvent ce que l’on pense compliqué pour l’utilisateur passera sans soucis alors qu’une fonctionnalité qui semblait anodine peut paraître laborieuse par l’utilisateur final.

En conclusion, pour apprendre vite, il faut tester au plus vite en production tous en mesurant : monitoring, analytics, retours d’utilisateurs. La vie d’un projet est faite d’un graphe de micro-décisions qui se dessine dans le temps. Le conseil d’Ismaël pour faire ces choix : « En cas de doute, choisissons le chemin de l’apprentissage maximum ». Il faut créer dans l’équipe « un sain sentiment d’urgence et d’engagement » qui force à garder un rythme soutenu et soutenable plutôt que de compter sur le coup de fouet donné à l’approche de la date de livraison. Urgence qui conduit trop facilement à des échecs.

Une citation d’Ismaël est particulièrement explicite : « Si vous sortez et que vous n’avez pas de bug, c’est que vous êtes sorti trop tard. »

4. Ratez vos revues de code en 5 leçons ! – Par Michel Domenjoud

Michel Domenjoud disposait de 20 minutes pour nous faire part de son expérience sur les revues de code. Tout d’abord, il souligne qu’une équipe utilisant la revue de code sera plus confiante sur la fiabilité de l’application en production, contrairement à une équipe qui n’applique pas de revue de code et qui craindra de modifier certains pans complexes d’une application. Personnellement je tiens le même discours au sujet des tests unitaires.

Puis Michel nous rappelle quelques chiffres sur la revue de code :

  • 65% des bugs sont ainsi détecté au plus tôt
  • un ROI de 4/1 à savoir 4 heures de debug pour une heure de revue de code

Voici quelques conseils :

  • Il faut choisir le format de revue de code approprié à l’équipe et à la situation et l’appliquer à un rythme soutenable. Relire 2000 lignes de code la veille d’une mise en production, ce n’est pas soutenable. Par contre faire en pair-programming un algorithme complexe qui demande autant de ligne de code me parait plus sûr.
  • L’auteur du code doit lui-même appliquer les modifications décidées en code-review. Ça implique de progresser et d’éviter le dictât d’un développeur qui diffuserait la bonne parole…
  • Il faut échanger sur les pratiques, mettre en place des standards commun. Chaque équipe possède ses exigences et affinités, elle doit définir ce qui lui convient.
  • Egoless programming : le code se partage, il évolue avec toute l’équipe et n’est donc pas la propriété d’une personne.
  • Ce n’est pas le moment de « troller », en pause café en revanche…
  • Prendre une décision collective implique que chacun fasse des compromis. Ainsi tout le monde progressera.

Enfin Michel nous invite à utiliser les différents formats de revue de code (pair-programming, revue par un pair, revue collective). Chacune a ses avantages, et toutes sont complémentaires.

Vous trouverez les slides de sa présentation sur :
http://fr.slideshare.net/mdomenjoud/agile-tour-lille-2015-ratez-vos-revues-de-code

Et pour aller plus loin ses articles sur le blog d’Octo : http://blog.octo.com/author/mdo/

Fin de la partie 1 (à suivre…)

Par Matthieu Fernandes