BDX I/O 2019 #1 : Equiper sa voie

J’ai assisté à la conférence BDX I/O le 15 Novembre 2019.

BDX I/O est une conférence organisée à Bordeaux tous les ans depuis 2014. Cette conférence est dédiée aux développeurs et aborde les sujets / problématiques sur l’état de l’art. J’y ai également trouvé d’autres sujets, moins techniques mais tout aussi intéressants.

D’une manière générale, j’ai beaucoup apprécié cette conférence, encore un grand merci aux organisateurs ! Toutes les sessions sont disponibles sur la chaîne YouTube de BDX I/O.

Ce billet est le premier d’une série de trois, qui présente les sessions que j’ai le plus appréciées.

Équiper sa voie (@tpierrain)

Dans cette session, Thomas Pierrain commence par nous raconter son expérience dans l’IT ou pour être plus précis le début de son expérience dans l’IT, car Thomas a plus de 20 ans de pratique dans l’industrie, en tant que développeur, architecte mais aussi chef d’équipe.

De mon expérience, il est rare de rencontrer, une personne qui continue activement de développer avec plus de 10 ans d’expériences, autant donc dire que je suis très friand de ce genre de retour d’expérience.

On note tout de suite que l’on n’est pas dans le cliché mais dans un retour d’expérience construit et direct. Des moments assez personnels sont abordés. Ces moments permettent de mettre en lumière 3 phénomènes, faisant partie de l’aspect humain du métier de développeur à savoir :

• Les conflits au travail,
• Les effets qu’ont les gens toxiques au sein d’une organisation,
• Les conséquences du volontariat à outrance.

Constater que certains événements de son histoire sont également des choses que j’ai vécues ou vues, remet un peu au centre du jeu l’importance des aspects humains de notre métier. Car contrairement aux idées reçues, le métier de développeur possède une composante sociale très forte. Le travail en équipe est la norme et donc la capacité de pouvoir communiquer au moins avec les membres de son équipe est fondamentale, voir essentielle.

De plus dans une industrie ou le « fun » (un certain esprit du jeu tout du moins) et quelque part une certaine euphorie est omniprésente (combien d’industries proposent le babyfoot au travail ou les soirées bière(s) 1 fois par semaine ou mois ?), le fait d’avoir conscience de ces trois phénomènes est je pense important.

Au-delà des anecdotes, Thomas tire les conclusions de son expérience. Après cette courte phase, il termine avec ce rappel très juste :

Nos problèmes en I.T. sont rarement liés à des soucis techniques.

Les raisons de l’échec

Il m’arrive souvent de lire les rapports / billets de blog sur les raisons des échecs de projet dans l’IT, le dernier en date, que j’ai pu lire est celui-ci « Classic Mistakes ».

Sur les 10 raisons données dans le rapport, ci-dessus, seulement 2 peuvent être liées à des soucis techniques. Sans être une autorité en la matière, après tout je ne suis pas chef de projet ou manager, ce type de rapport présente toujours une majorité de soucis de communication ou d’organisation par rapport aux sujets techniques.

Au sein du célèbre « Manifeste Agile« , je pense que 3 des 12 principes sont particulièrement de circonstance ici :

• « Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. »
• « La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face. »
• « À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. »

Rien de technique sur ces trois principes mais une volonté très forte de rendre essentielle la résolution des soucis de communication au sein d’un projet. On peut très souvent, trouver un effet sur le communication avec les autres principes, mais les trois cités sont je pense les plus explicites sur ce point.

D’une manière générale, je pense que tenir un projet Agile ne soit pas une pratique technique, qui n’impose ni outil, ni style d’architecture ou technologie en particulier. En revanche le fait d’aborder plutôt des sujets d’autonomie d’équipe et de communication au sein des équipes est représentatif pour moi du rappel que nous fait Thomas avec le constat qu’il pose.

« Process Communication » : la solution à vos problèmes

Il présente d’ailleurs dans sa dernière partie les différentes solutions qu’il a pu explorer. Il est à ce moment question de « Biais », de « Communication non-violente » mais aussi et surtout de la méthode développée pour la Nasa « Process Communication ».

Si ces sujets ne vous disent rien, je vous invite vivement à regarder la rediffusion du talk de Thomas, il présente ces sujets avec beaucoup plus de détails.

Pour ma part, j’ai beaucoup apprécié la démarche de cette session, qui commence par un retour d’expérience pour ensuite embrayer sur la mise en évidence des problématiques rencontrées et enfin présenter des solutions sur lesquelles on peut tous s’engager. Solutions qui, en plus d’être pertinentes, se trouvent être vertueuses. Bref, j’ai appris des choses !

Retrouvez le deuxième article de cette série qui nous parle des microservices et migroservices !