Zenika était à SoCraTes Canaries 2016 !

L’édition 2016 de la conférence SoCraTes (pour Software Craftsmanship and Testing) Canaries vient de fermer ses portes et il est temps pour moi de faire un bilan de l’événement et de rapporter autant que possible les discussions intéressantes qui ont eu lieu sur place.

SoCraTes, mode d’emploi

SoCraTes est un ensemble de conférences organisées par les communautés du Software Craftsmanship de différents pays d’Europe. Né en Allemagne, le concept s’est rapidement exporté au Royaume-Uni, en Italie, en Suisse, aux Canaries donc, et même en France !
Ces différentes instances partagent néanmoins un même fonctionnement. Partant du constat que les échanges les plus intéressants des conférences ont souvent lieu pendant les pauses, devant la machine à café ou pendant les repas, les SoCraTes sont organisées sous la forme d’un open space : aucun talk ou discussion n’est planifié à l’avance et le programme de chaque journée est décidé le matin. Chacun est libre d’assister aux sessions qui lui plaisent et la participation est fortement encouragée pendant les talks.
Cette édition de SoCraTes Canaries a été une nouvelle occasion d’observer comment ce format facilite les échanges, les retours d’expérience et le partage des connaissances.

Premier jour

Fraîchement débarqués de l’avion et à peine le temps de s’habituer au difficile climat des Canaries, direction la plage de Las Palmas à côté de laquelle aura lieu la conférence cette année.

C’est dans l’après-midi que les choses sérieuses commencent vraiment, avec une série de lightning talks. Chacun a l’occasion de présenter un sujet qui lui tient à cœur en quelques minutes et les sessions sont finalement très variées. Tandis que certains partagent leur expérience sur la bonne tenue de la partie technique des entretiens d’embauche, d’autres présentent la mise en place d’un système de partage ouvert des résultats financiers au sein de leur entreprise. Plusieurs talks ne manquent pas d’humour et tout le monde se souviendra certainement de la présentation de la “technique du canard” pour devenir le roi des réunions tendues : pinailler pendant toute la durée des discussions sur un point technique discutable, puis finir par abandonner sa position cinq minutes avant la fin des échanges. Les adversaires triomphants ne se doutent pas que le sujet réel de la réunion se cache dans la question innocente qui est subtilement glissée à ce moment-là !
Après le dîner, un World Cafe est organisé. C’est l’occasion de discuter des sujets dont chacun aimerait parler ou entendre parler au cours de la conférence. Certains reviennent plus souvent que d’autres dans les discussions, et la fin de la soirée est laissée à la préparation de quelques slides pour appuyer les présentations du lendemain.

Deuxième jour

En guise de petit-déjeuner, notre facilitateur Adrian Perreau nous présente plus en détail le fonctionnement d’un open space.
Les 5 principes

• les personnes présentes sont les bonnes
• ce qui arrive est la seule chose qui pouvait arriver
• ça commence quand ça commence
• quand c’est fini, c’est fini
• quel que soit l’endroit où cela se passe, c’est le bon endroit

La loi des deux pieds : si vous n’êtes ni en train d’apprendre, ni de contribuer, passez à autre chose !
Les deux types de personnes

• Les papillons, qui restent au même endroit, participent, prennent une pause ou réfléchissent
• Les abeilles, qui bougent et font circuler les idées d’atelier en atelier

Vient ensuite le moment de définir le programme de la journée. Armés de marqueurs, on passe à tour de rôle pour proposer une session et l’affecter à un slot sur la timeline géante de la salle. Le choix est parfois difficile car beaucoup de talks ont lieu en parallèle, mais voici quelques mots sur les sessions auxquelles nous avons assisté.

Code reviews

Par Wolfram Kriesing.
De manière très ouverte, on partage d’abord nos expériences sur la tenue des revues de code dans nos équipes respectives. Les idées qui reviennent souvent sont notées dans un coin, puis on essaie d’ordonner tout ça dans une mind map. Parmi les idées les plus importantes :

• Les revues de code ne servent pas uniquement à contrôler la qualité du code, mais avant tout à diffuser la connaissance du code, partager la responsabilité des modifications et encourager la transparence entre les membres d’une même équipe.
• Il n’y a pas de meilleur moment pour une code review. Plus elle est effectuée tard, plus l’intégration est difficile (conflits possible si on utilise un système de pull requests) et plus la correction d’éventuels problèmes est complexe (comment et quand corriger un code qui est déjà mergé et déployé ?). Inversement, des code reviews fréquentes peuvent mener à d’incessantes interruptions, surtout dans les grandes équipes.
• Certains outils peuvent faciliter une revue de code : regarder les diffs dans Git, utiliser un système de Pull Requests, calculer automatiquement des métriques sur la qualité du code avec Sonar, mais il n’existe pas de solution parfaite pour toutes les équipes et tous les projets.

Programmes de formation pour les nouvelles recrues

Par Daniel Irvine et Sandro Mancuso.
Daniel et Sandro nous présentent les programmes de formation et de mentorat qui existent dans leurs entreprises respectives. Malgré certaines divergences d’opinion, on retiendra surtout de nombreux points en commun.

• Il est de plus en plus difficile de trouver des développeurs qualifiés et motivés. Les systèmes éducatifs et les méthodes de recrutement traditionnels ne suffisent plus.
• A la place, on recrute des personnes motivées et qui ont envie d’apprendre. Pendant une période de 3 mois à 1 an, la recrue ne travaille pas, mais se forme en interne, auprès d’un mentor qu’elle choisit dans l’équipe ou qui lui est associé.
• La seule métrique importante est la progression de l’apprenti. Celle-ci doit atteindre un niveau technique minimal prédéfini avant de pouvoir travailler.
• Le contenu de la formation est adapté au candidat. Souvent, il s’agit d’exercices de développement dans une grande variété de langages, en perfectionnant la technique et les process, mais la lecture de billets de blogs techniques, la préparation de talks ou encore les séances de pair programming prennent aussi une place importante.
• Chaque recrue doit développer et maintenir un projet personnel pendant toute la durée de sa formation.

Ce genre de programme représente un investissement considérable pour l’entreprise (employé non facturé mais rémunéré pendant une longue période), mais d’après les divers témoignages dans la salle, les résultats sont au rendez-vous et les clients remarquent eux-même la qualité des développeurs qui sortent d’un tel système de formation.

Pair interviews

Suit une session d’entraînement aux interviews techniques. Chacun est à tour de rôle candidat et examinateur au cours de petits entretiens d’une dizaine de minutes. Les domaines des questions sont souvent assez classiques :

• Formation
• Expériences passées (technologies, agilité)
• Outils de développements maitrisés
• Projets personnels / contribution à des projets open-source

Mais certains parlent aussi d’éthique du développeur ou de la manière de responsabiliser une équipe. D’autres s’essaient carrément à une séance de ping-pong programming.
D’une manière générale, on s’accorde à dire que le format proposé ne fonctionne pas trop. Les sessions sont trop courtes pour développer en profondeur un sujet. Mais le concept pourrait bien s’adapter à l’entreprise, par exemple pour peaufiner le process des interviews techniques ou harmoniser les critères de sélection entre les différents examinateurs.

Comment insuffler la passion et inculquer les pratiques XP chez un client

Par Carlos Blé et Mateu Adsuara.
En tant que consultant en mission chez un client, il est assez fréquent de rencontrer des équipes démotivées ou aux méthodes de travail peu efficaces. On doit alors cumuler les casquettes de développeur et d’évangéliste des méthodes Agile et XP. Carlos et Mateu nous expliquent comment ils abordent ce genre de situations.

• Développer soi-même et modifier les méthodes de travail de toute une équipe simultanément n’est pas facile. Mieux vaut partager son temps et de ne faire que l’un des deux à la fois.
• Le plus important est d’acquérir la confiance de l’équipe et de montrer l’exemple. Il est toujours plus facile d’accepter de modifier ses méthodes de travail quand on est certain que la nouvelle méthode fonctionne vraiment.
• Il est totalement inefficace de forcer les récalcitrants. Il est en revanche possible de les laisser expérimenter leur méthode (et les encourager à le faire) jusqu’à l’apparition d’obstacles insurmontables, et de présenter alors une alternative qui fonctionne mieux.
• Il n’est pas nécessaire de prononcer les mots “pair programming” et “TDD” devants des managers ou des développeurs frileux. Il suffit de parler de “coup de main” ou de “tests automatisés”.
• Organiser des katas, des coding dojos et des brown-bag lunch ludiques peut aider à entretenir la passion dans une équipe.
• La passion est comme un feu, il peut suffir d’une petite étincelle chez un des développeurs pour faire repartir le groupe entier sur une bonne dynamique. Il ne faut pas se frustrer de ne pas réussir à changer tout le monde dès la première semaine.

La suite de la session consiste en une discussion animée avec le public et un partage d’anecdotes amusantes autour du sujet.

Apprendre à des enfants à coder avec Minecraft et JavaScript

Par Johan S. Cortes.
Johan nous présente son projet communautaire d’enseignement de la programmation en JavaScript à des enfants de 7 à 14 ans. L’idée est de sensibiliser les jeunes aux problématiques du développement avec une approche ludique dans un univers qu’ils apprécient.
Il utilise pour cela l’API Bukkit pour automatiser des opérations sur un serveur Minecraft depuis un environnement JavaScript. Le programme est décomposé en trois sessions de trois heures :

• Lors de la première, les participants sont familiarisés avec Minecraft lui-même. On leur demande de construire un grand cube de 8x8x8 cubes unité, ce qui prend plus de temps qu’il n’y parait, et on leur présente alors “JS” comme un robot qui peut automatiser ce genre de tâches. Certaines commandes sont déjà accessibles dans le terminal de Minecraft et chacun peut les essayer. Les enfants demandent rapidement s’ils peuvent faire la même chose à la maison, mais il faut pour cela installer et configurer un serveur Minecraft dédié. Ils repartent donc la plupart avec l’envie d’apprendre à configurer un serveur !
• Pendant la deuxième, les participants apprennent à configurer un serveur Minecraft. Certains jeux sont mis en place, comme essayer de deviner l’impact d’un flag de configuration à partir de son nom. Une fois les serveurs configurés en local, chacun est libre de rejoindre le serveur d’un autre. On se rend alors compte que l’on peut détruire les constructions des autres (par exemple avec la TNT ou la lave), et c’est l’occasion de parler de restrictions et de droits administrateur.
• La troisième session est consacrée au développement de fonctions supplémentaires en JavaScript. Après une introduction rapide à la syntaxe (principalement du copier-coller), les élèves doivent par exemple automatiser la construction d’un escalier de 3 marches. Puis de 4 marches, puis 5… Et la notion de paramètre est alors présentée.

A la fin de sa présentation, Johan nous montre les créations étonnantes de certains des participants et l’on se souvient par exemple de cet Iron Man construit avec des blocs rouge et jaunes qui apparait à l’invocation de la commande ironman() !

Comment atteindre le consensus sur des sujets techniques ?

Les sessions du jour se terminent par une discussions lancée par une chef de projet inquiète des débats sans fin sur les technologies et outils à utiliser au sein de sa nouvelle équipe.
Le sujet est évidemment très large et la session s’organise rapidement comme une discussion ouverte ou chacun donne son avis. On retiendra par exemples les idées suivantes :

• Réaliser des petits prototypes en temps limité pour essayer les différentes approches.
• Ne pas forcément commencer avec une solution générale à tous les problèmes que l’on peut imaginer, mais avec la solution technique la plus simple qui permet d’atteindre les premiers buts identifiés.
• Essayer de se concentrer sur le besoin et non les solutions : souvent un développeur va pousser pour telle ou telle solution car il imagine qu’un besoin sous-jacent, dont personne n’a encore parlé clairement, est très important.
• Bien sûr, toujours entretenir l’empathie entre les membres de l’équipe et respecter les avis de chacun.

Soirée

Après le dîner et avant de profiter de l’ambiance nocturne de Las Palmas, nous avons pu participer à plusieurs sessions plus détente, avec notamment un PowerPoint Karaoké et une session de Mob Programming en TDD très instructive et dynamique. Et quand la machine qui note les consommations au bar de l’hôtel est en panne et que les bières sont gratuites, c’est encore mieux !

Troisième jour

Nous organisons aussi le programme de la journée le matin-même. Certaines sessions sont répétées pour ceux qui n’ont pas pu y assister la première fois et de nouvelles sont proposées suite aux discussions de la veille. La timeline se remplit vite.

A quoi ressemblerait votre entreprise de Software Craftsmen?

Par Sandro Mancuso.
Sous la forme d’une table ronde, Sandro nous demande comment nous organiserions notre propre entreprise de Software Craftsmen. La discussion gravite autour de plusieurs sujets principaux
Processus de recrutement

• Mettre en avant les valeurs de l’entreprise et son équipe avant tout.
• Etre certain que le candidat se reconnait dans ces valeurs et les porte lui-même.
• Faire du pair programming avec le candidat, seule manière efficace d’évaluer ses compétences techniques.
• Faire interviewer le candidat par les employés avec qui il va effectivement travailler.
• La décision de recruter ou non un candidat devrait être une décision de groupe, prise par l’ensemble des employés.
• Organiser un événement de team building/intégration dès l’arrivée de la nouvelle recrue.

Transparence

• Open financials : être totalement transparent sur les résultats de l’entreprise avec tous les employés. Mettre à leur disposition un outil qu’ils peuvent utiliser et comprendre pour accéder à ces informations d’eux-même (et non pas limiter ces discussions à quelques slides lors de réunions trimestrielles).
• Open-salary : être également transparent sur le salaire de tous les employés. Mettre à disposition de tous les employés la liste des salaires de chacun.
• On peut même aller plus loin et proposer aux employés de décider ensemble de leurs salaires respectifs en fonction de la situation de l’entreprise et des besoins immédiats de chaque employé.
• Etre transparent sur la stratégie de l’entreprise et les moyens qui vont être utilisés pour les atteindre.

Récompenser ses salariés

• Mettre en avant les réussites personnelles des employés.
• Mettre en avant les réussites des équipes.
• Faire en sorte que le travail lui-même soit valorisant et motivant, que ce soit un plaisir d’aller au bureau le matin. Pour cela, on insiste sur trois points : avoir de l’autonomie, développer une expertise et participer à un projet qui a une raison d’être, un but.
• L’argent ne marche pas comme un motivateur sur le long terme. Un salaire insuffisant ou des désaccords sur la rémunération peuvent en revanche être de puissants démotivateurs.

Conception d’un parcours d’introduction pour les nouveaux Software Craftsmen

Par Bradford Hovinen.
Nous discutons des éléments qui nous semblent essentiels à une bonne introduction au Software Craftsmanship. Chacun raconte ses premiers pas dans le domaine, ce qui l’a aidé à aller plus loin et ce qu’il aurait aimé connaître plus tôt. On retiendra par exemples les idées suivantes.

• Lire des billets de blogs et de chapitres de livres parlant de l’histoire du Software Craftsmanship.
• Visionner des vidéos sur le sujet, comme celles de Uncle Bob.
• Pratiquer le Pair Programming pour introduire le TDD.
• S’entraîner sur des katas de refactoring et de legacy code.
• Mettre en place des revues de code pour partager les connaissances.
• S’entraîner régulièrement à donner des présentations.
• S’imposer des objectifs à atteindre dans l’année.
• Noter les choses que l’on a apprises pour se forcer à organiser ses pensées et prendre du recul.

Culture, jeux de pouvoir et géographie

Par Adrian Perreau.
Adrian nous raconte quelques anecdotes du temps qu’il a passé à Critéo (Paris), une entreprise qui a grandi très vite tout en voulant garder un esprit startup. Il s’est amusé à comparer la position physique des employés dans l’open space avec leur position hiérarchique et à analyser la dynamique générale au sein du groupe, et le constat est sans appel !
Il nous explique ainsi que l’espace était séparé en grands lobes assignés à différentes équipes. Les plus importantes (par exemple, celle du développement du moteur de recommandation) ont les places près des fenêtres, avec les meilleures vues, tandis que l’équipe IT ne voit pas l’extérieur et que l’équipe QA est simplement coincée dans un coin sombre.
Suite à une réorganisation de l’espace, personne n’avait de bureau sauf le CEO et le CFO, et le CTO s’est immédiatement senti obligé de se placer dos à un mur, avec des cartons ou des étagères sur les côtés de son bureau. Les managers, eux, se plaçaient dans les coins, près des fenêtres. Et les promotions entrainent des déplacements de bureau à bureau qui suivent parfaitement ce schéma !
Pour tenter de briser le phénomène, des coding dojos et autres événements de team building sont organisés. Les employés ont été invités à se déplacer et changer de voisin de bureau tous les mois. Mais les résultats sont restés imparfaits. Les vieilles habitudes ont la vie dure !
Adrian conclut en notant que les managers assis dans les coins s’attendent à ce qu’on leur rapporte des informations, tandis que les chefs plus “modernes” s’assoient plutôt dans les lieux centraux et de passage, afin de capter passivement un maximum d’information.
Les slides sont disponibles en ligne.

Comment ne pas faire avancer un projet

Par Mashooq Badar.
Mash décrit en quelques mots les situations récurrentes qu’il a vécues en tant que consultant et qui mênent la plupart du temps à des échecs cuisants. Chacune est bien entendu accompagnée de multiples anecdotes croustillantes sur certains de ses clients !
Trop à faire–il faut grossir vite
Le management a souvent l’impression qu’une plus grosse équipe ferait avancer le projet plus vite. Faire grossir l’équipe alors que le projet n’a pas encore de ligne directrice est en fait contre-productif : chacun veut proposer ses idées et sa vision du système et on se marche sur les pieds. Il est plus sage d’attendre que les décisions principales soient prises et que tout le monde soit d’accord sur les fondations avant d’intégrer un grand nombre de développeurs.
J’ai besoin d’un gros cluster
Dans les projets avec de fortes attentes sur les performances, il n’est pas rare de voir des équipes partir directement sur des systèmes distribués de grande envergure, alors que le volume et le type de données ne sont pas encore entièrement identifiés. S’engager trop tôt dans des choix technologiques si restrictifs peut être catastrophique. Il faut en général préférer les itérations courtes et les systèmes simples qui grossissent au fil des évolutions et de la meilleure identification des besoins.
Partons directement sur des micro-services !
Les micro-services peuvent répondre à certains besoins précis, mais ils apportent aussi beaucoup de complexité avec eux. Mash explique que même en utilisant des outils avancées comme Mesos ou Marathon, ses équipes passent toujours beaucoup de temps à s’occuper de problèmes dont personne n’avait imaginé l’existence jusqu’alors. Développer, maintenir et faire grossir une architecture micro-services nécessite de solides compétences DevOps. Une alternative simple pour déployer rapidement les premiers prototypes sans avoir à se soucier des détails compliqués consiste à utiliser des écosystèmes micro-services existants (par exemple, Azure, Amazon Web Services ou Google Cloud).
Je veux les développeurs les plus talentueux dans mon équipe
C’est comme dans le sport, les rassemblements de stars forment rarement des équipes qui fonctionnent bien. Les egos et les forts caractères sont parfois difficiles à gérer, surtout quand tout le monde veut essayer sa dernière idée ou proposer des changements dans le projet. Il est plus facile de maintenir l’intégrité d’une équipe avec des profils variés et de tous les niveaux, qui sait travailler ensemble.
Il faut déployer dans le cloud, mais rester cloud-agnostic
Certains clients, ne voulant pas mettre tous leurs oeufs dans le même panier, demandent une compatibilité du projet avec plusieurs écosystèmes Cloud (par exemple, AWS et Azure). On finit alors par utiliser des composants puissants d’un écosystème cloud sans jamais en exploiter la capacité et les possibilités. Difficile par exemple de mettre en place de l’auto-scaling dans ce contexte. On se force à utiliser un grand nombre de frameworks open-source pour faire le même travail, et à la fin le système obtenu n’est jamais vraiment agnostique.
Innovation à tout-va
Les équipes de développement poussent souvent pour introduire une technologie qu’ils affectionnent dans le projet ou essayer leurs idées. En général, c’est bénéfique, mais il faut mettre en place des règles de base pour éviter les dérives et la dispersion des ressources. Par exemple, on peut décider qu’il ne peut pas y avoir plus de deux modules qui font le même travail : celui qui est utilisé, et un nouvel essai. Pour essayer une troisième approche, il faut d’abord se décider pour ne garder qu’une seule des deux solutions précédentes.
Automatisation des tests d’interface graphique
Tester une interface graphique reste compliqué. Même en utilisant des outils comme Selenium, ces tests restent lourds et difficiles à développer. C’est un investissement continu qui ne doit pas être pris à la légère. Beaucoup de projets peuvent retarder la mise en place de tels tests et mettre l’accent sur le test manuel de l’interface lors de code reviews, par exemple.

L’entretien d’embauche de Sandro Mancuso

Par Adrian Perreau, Sandro Mancuso et Romain Vernoux.
Après les nombreuses discussions des deux jours précédents, il nous est venu cette idée de session pour finir la journée sur un ton léger : avec Adrian, nous cuisinons Sandro Mancuso, fondateur de la London Software Craftsmanship Community (LSCC) et auteur de The Software Craftsman: Professionalism, Pragmatism, Pride, à travers une interview technique caricaturale. Tout le monde connait la nature de l’emploi (un poste de développeur pour un obscur site de streaming vidéo) sauf Sandro, qui doit jouer le jeu face à nos questions évidemment chargées en sous-entendus.
Après une première moitié de sessions chargée en rires, le reste du temps est utilisé pour discuter de tout ce qui n’allait pas dans le processus de l’interview et des manières de mettre en place des entretiens techniques efficaces :

• Partager un wiki entre examinateurs avec une liste de questions qui permettent effectivement d’en apprendre plus sur le candidat.
• Se rencontrer régulièrement pour échanger sur les critères de notations, afin que différents examinateurs émettent des jugements uniformes sur les candidats.
• Se poser les questions entre examinateurs (sans préparation) pour déterminer quel genre de réponse il est effectivement raisonnable d’attendre.
• Envoyer des exercices simples (katas) aux candidats avant même de les rencontrer. Pas de limite de temps, il s’agit simplement d’évaluer grossièrement leur niveau technique. Il est possible d’utiliser les mêmes exercices pour tous les candidats, mais de placer la barre plus haute pour les profils avec plus d’expérience.
• Une fois en tête-à-tête, passer un maximum de temps à faire du pair programming.
• Partager les notes prises pendant la session avec tous les examinateurs, sans noter son avis personnel. Discuter ensemble d’une réponse finale.

Soirée

Juste avant le dîner et pour clore ces deux journées de discussions, notre facilitateur nous rassemble pour partager nos impressions sur la conférence elle-même, et en particulier son organisation. Le tout se fait avec des post-its que l’on place dans les catégories “à arrêter”, “moins de”, “à continuer”, “plus de” et “à commencer”. L’occasion de critiquer la stabilité du réseau WiFi, bien entendu, et de se donner des conseils pour progresser ensemble, avec en vue l’édition de l’année prochaine !

Conclusion

Ce SoCraTes s’est déroulé dans une ambiance extrêmement positive et motivante, et je garderai un très bon souvenir de mes premiers pas dans une conférence au format open space. Les échanges y ont été nombreux, constructifs et inspirants, et j’espère que ce résumé aura su attirer votre attention sur l’univers du Software Craftsmanship. Quelle que soit votre familiarité avec ce sujet, je ne peux d’ailleurs que vous recommander de tenter l’expérience SoCraTes.
Prochain stop : SoCraTes UK du 2 au 5 juin 2016, et Zenika y sera aussi !