C’est dans les locaux de Zenika que s’est déroulé ce nouveau meetup Craftsmanship, en fait le premier pour moi ! Cyrille Martraire sera le maître de cérémonie, il introduit le déroulement de la soirée, à savoir : 2 lightning talks, 1 talk moins light et enfin le coeur de cette soirée, l’open-space

Alors, Dev4Fun, qu’est-ce que c’est ?

Xavier Detant est venu nous présenter un nouveau meetup, non pas concurrent, mais complémentaire à Software Craftsmanship : Dev4Fun !

Dev4Fun, c’est un « coding dojo », mais sans le mot « dojo », car ciblant plus les débutants. Pour rendre cela Fun, on s’appuiera, au moins pour la prochaine rencontre planifiée pour le 22 Janvier, sur une plateforme dédie au développement de code sur des jeux : codingame.

Bref cette rencontre a pour but de faire découvrir, comme le dit Xavier « pourquoi on kiffe sur les barres vertes » !

Comment amener les changements techniques dans l’entreprise ?

Cette présentation avait pour but de donner un coup de projecteur sur ce sujet issu du livre de Sandro Mancuso sur le Software Craftsmanship. Plus précisément, il est question ici de classifier les profils d’une équipe afin d’adopter la bonne stratégie en fonction des interlocuteurs !

On trouvera ainsi :

• Le Non-Informé : Il ignore tout du sujet, on peut l’amener à bord en partant de zéro.
• Le mouton : Pas la peine de s’en préoccuper. Si on embarque les autres, il suivra.
• Le cynique : Il va prendre le contre-pied juste pour le plaisir de se montrer plus malin. Attention de ne pas perdre trop de temps avec lui.
• Le désabusé : Il a essayé des choses et s’en est mordu les doigts, il n’a plus le goût à essayer.
• Le surbooqué : Il n’a pas le temps de vous écouter
• Le boss : Ne pas perdre de temps avec lui, car de toute façon, il n’y cmprendra rien.
• L’irrationnel : c’est le cynique mais en pire ! Il va contre-argumenter sans but et va vous faire perdre du temps.
• L’indifférent : Il ne se sent pas impliqué, mais attention ! Il peut être la source de mauvaises implémentations de bonnes idées.
• Le persécuté : Il nuit au projet en attendant sa prime de licenciement. A écarter à tout prix.
• L’inapte : Simplement pas à sa place. A éviter.
• L’architecte « tour d’ivoire » : Il croit tout savoir mais ne touche plus au code. Attention, il peut avoir beaucoup d’influence…
• L’inscure : Il s’est construit son petit confort, mais il est « has been » et a peur que l’on s’en rende compte.
• Le fan boy : Implémente le pattern « golden hammer » avec une technologie qu’il admire et connait très bien. Mais si on peut le convertir…

Dans ce tableau idylique, il manque bien sûr le gars normal ! Comme le souligne l’orateur, identifier les profils, c’est déjà 50% du travail. Sur le fond, je trouve ici une matière un peu intéressante mais pas révolutionnaire. En fait, c’est une vision très simplifiée de ce que l’on peut trouver dans Fearless Change. Quand au livre, vous pouvez en voir un excellent résumé ici.

Does your code speak business ?

Pas un lightning talk ici, mais plutôt une présentation de 30 minutes (avec les petits soucis techniques qui l’ont émaillée). Maxime énonce le problème qu’il veut traiter ainsi : comment ajouter de la valeur si votre code ne parle pas métier. A titre de contre-exemple, il nous assène le syndrome de l’homme fort ! Vous savez, celui qui écrit un code incompréhensible plus vite que son ombre, qu’il ne faut jamais déranger et qui au final livre une usine à gaz à côté de la plaque ?

L’homme fort n’est pas le seul syndrome. De manière générale, on rencontre nombre d’équipe où le business et l’équipe de développement utilisent des vocabulaires différents ! Un problème encore amplifié par les modèles de développement en silos où le besoin initial fait l’objet de traductions successives…

La solution ? Le fameux « ubiquitous language » du DDD. Mais l’orateur nous invite à ne pas en rester là : pour découvrir ce vocabulaire, parlons Event Storming ! Il s’agit d’une approche proposée par Alberto Brandolini, elle prend la forme d’un workshop dans lequel on invite « des personnes avec des questions (les développeurs) et des personnes avec des réponses (le business) ». On part de « l’évènement le plus important dans le système » et on remonte dans le temps. A chaque évènement correspondra une commande et au final on sura comment le système doit se comporter.

Je ne connaissais pas l’Event Storming, un nouvel outil à considérer sérieusement !

Open-space : alors, cette doc ?

Oui, c’est un open-space, vous savez celui où on forme des groupes, on propose des sujets et on vote sur ceux-ci. Le zLocalHost de Zenika a fait le plein et nos 3 cercles sont un peu enchevêtrés…

Donc, on propose des sujets…

Puis on vote ! Je vais m’incruster dans le groupe qui parlera de documentation !

La discussion démarre sur les chapeaux de roues : moi j’utilise Sharepoint, moi un Wiki … Mais un instant : La documentation n’est qu’un moyen, non ? Quelle finalité cherche-t-on à atteindre avec cette documentation dont on pense implicitement qu’elle est indispensable ? Car là, on commence à parler du moyen du moyen !

Visiblement, la finalité, c’est souvent de transmettre de l’information quand quelqu’un part ou qu’un nouveau membre de l’équipe arrive. Un bien pauvre substitut au partage du savoir que l’on obtient en travaillant ensemble. On évoque aussi les tests, plus précisément les acceptance tests en tant que « living documentation ».

Pour en revenir à la documentation sensu-stricto, je relève :

• Que je ne suis pas le seul à avoir des problèmes pour m’y retrouver dans les Wiki. Cyrille semble avoir le même problème que moi. Donc un bon moteur de recherche full-text y est indispensable.
• Coupler la documentation avec la gestion de version, une option importante.
• Les nomenclatures de noms de documents ou de répertoire, ça fait peut-être « old school », mais ça marche !
• Le problème de la divergence de la documentation avec la réalité : un obstacle sur lequel on finit toujours par arriver. Pourtant on reste câblé sur l’idée de la documentation qui sauve de tout…
• Les docs de haut niveau sont finalement celles qui sont le plus souvent demandées et utiles. Outre qu’elles ne sont pas trop volumineuses, elles souffrent moins du phénomène d’obsolescence, donc plus faciles à maintenir.

Cet échange n’a pas révolutionné mais idées, mais il était agréable. Les 2/3 choses que j’ai notées au passage ne feront pas de mal !

Assez bossé, il est temps de migrer vers le buffet pour conclure la soirée !