Nul besoin d’avoir un passé de développeur, ou de savoir coder. Mon intention ici est de faire découvrir des pratiques tech reconnues dans l’industrie. C’est un sujet que je souhaite rendre accessible à tous, que l’on soit tech ou non, pour améliorer le quotidien des équipes, devenir meilleur dans la technique et dans le business. J’ai été invité par Fleur Saillofest à speaker dans le meetup Beyond Scrum Mastering. Très rapidement, une trame intéressante a émergé lors de nos échanges : celle de reconnaître des problèmes au sein de l’équipe et y associer certaines pratiques tech qui pourraient aider.

Un développeur a-t-il besoin d’une permission pour écrire des tests ? Pratiquer le Test-Driven Development ? Faire du refactoring ? Travailler en Pair Programming ? Faut-il un permis à l’image de la légendaire licence to kill de James Bond ? Ma réponse est NON (sans surprise, comme la plupart des articles qui commencent avec une grande question fermée). Un développeur doit être autonome et décider de lui-même pour ce genre de pratiques.

J’entends et lis parfois que ça prend du temps d’écrire des tests unitaires et de pratiquer le Test-Driven Development. Que c’est bien plus long que de ne pas en faire. Je ne suis pas en phase. J’ai la conviction que ça ne prend pas forcément plus de temps de travailler en TDD. On est sensiblement sur la même longueur, parfois même plus rapide parce que ça nous guide. On est très loin du laïus “c’est une perte de temps”, surtout lorsque l’on regarde sur différents horizons de temps.

Le Forum Ouvert, ou Open Space en anglais, propose un espace d’échanges et de partages aux participants. C’est une méthode pour structurer les discussions avec un cadre simple qui apporte beaucoup de liberté. À ne pas confondre avec ce lieu bruyant où certaines entreprises réunissent un maximum de personnes en un minimum d’espace ;) Chez BENEXT, le Forum Ouvert est ancré dans notre ADN. On en faisait il y a plus de six ans quand j’ai rejoint l’aventure et on en fait encore aujourd’hui - jeudi prochain, j’anime la journée de la communauté tech et la matinée sera structurée en Forum Ouvert.

Suite à mon introduction sur l’Event Storming, j’ai envie de compléter un peu en revenant sur les différents ingrédients à notre disposition pour composer un Event Storming. Je trouve qu’on a une grande richesse. On a une large boîte à outils pour modéliser notre système et harmoniser les modèles mentaux, tout en restant simple d’usage. J’ai présenté certains éléments dans mon précédent article, ici je ferais une liste plus complète afin d’avoir une vision globale et rapide de ce qu’on peut utiliser.

L’Event Storming est un moyen d’harmoniser les modèles mentaux de différents acteurs en modélisant un métier, un processus, un existant. On veut cartographier de la connaissance. On veut mettre en lumière des zones d’ombre, des points de douleurs, des problèmes. Et on veut le faire tous ensemble pour s’aligner. On va créer des discussions et confronter des visions avec toutes les personnes impliquées. C’est un atelier qui peut s’utiliser dans n’importe quel domaine et pas seulement dans le monde du logiciel (même si son créateur, Alberto Brandolini, est un développeur).

L’indépendance n’existe pas uniquement dans certaines régions de France ou dans un film avec Will Smith. Il se trouve aussi dans les tests unitaires. Lorsque vous écrivez des tests, il y a un moment qui arrive où vous souhaitez être indépendant de quelque chose. Vous allez naturellement casser cette dépendance et injecter autre chose pour remplacer ce qui gêne. Ce n’est cependant pas une décision à prendre à la légère. Certaines raisons sont parfaitement justifiées, alors que d’autres peuvent nuire au projet.

Lorsque j’ai appris à faire du vélo, j’ai commencé à en faire dans mon jardin, dans la Drôme. Mon vélo avait deux petites roulettes sur la roue arrière, ça m’aidait beaucoup. On peut dire que j’étais dans un cadre sécurisant : à l’intérieur de mon jardin, avec peu de risque de chute et sans circulation de véhicules. J’ai pédalé des heures et des heures pour améliorer ma maîtrise. J’ai appris par la pratique, en répétant, en essayant, en m’améliorant.

Vous avez déjà assemblé des Lego ou monté un meuble Ikea ? Quand j’étais petit, j’adorais les Lego. Je laissais libre cours à mon imagination en créant des tas de lieux, de véhicules et d’histoires. J’ai aussi eu des boîtes de Lego avec quelque chose de précis à assembler (un château par exemple). Dans ces boîtes, il y a toujours un plan. On y voit le résultat final (le château) et toutes les étapes à suivre pour le construire.

La machine à café, c’est un peu un objet magique pour les développeurs. On peut y voir deux principales capacités. Elle provoque des résolutions de problèmes spontanées suite à des discussions proche de la machine. Et elle produit le café qui, une fois assimilé par le développeur, se transforme en d’innombrables lignes de code. Alors quand on possède un tel objet, on n’a pas envie de le casser. On voudra certainement l’améliorer, mais en le gardant fonctionnel.