On est entouré de principes, de lois, de modèles, de méthodes et d’un tas d’autres concepts. C’est utile pour construire des choses complexes comme des logiciels - on a besoin d’être aidé. Pour autant, je conseille de garder un minimum de recul et de questionnement face à ces grands écrits - ce ne sont pas des vérités absolues en toutes circonstances. Notre cerveau est plus que jamais important. J’aime considérer les principes (& co) comme des guides.

Hier soir me vient une idée sous la douche (ma source intarissable pour l’inspiration). Une idée et une envie : écrire des articles courts. Je divague. Je visualise des tips que je pourrais publier, concis et efficace. Pour partager des trouvailles utiles. Je visualise des petites histoires également. Avec l’envie de raconter des choses courtes, de partager une pensée qui me traverse l’esprit, une réflexion. Le mot brève me vient.

Pour mon premier article de 2023, j’ai envie de parler d’un changement survenu l’année dernière : mon passage d’iOS à Flutter. Mon intention ? Partager mon REX et au passage démystifier quelques légendes. Je trouve intéressant de partager cette expérience parce que je vois qu’il y a encore beaucoup de réticences à passer d’une technologie mobile native (un développeur écrit directement du « code iOS » ou du « code Android ») à une technologie cross-plateform (un développeur écrit « un seul code » qui permettra d’avoir à la fois une application Android et iOS).

Je n’ai pas publié depuis quelques mois. Je pourrais me dire “je n’ai pas eu le temps”. Mais, est-ce vraiment un manque de temps ? Je l’ai ce temps. D’ailleurs, on a tous le même temps - 7 jours dans la semaine, 24 heures dans la journée, 60 minutes dans l’heure. C’est invariable¹. Pourtant, on entend et utilise souvent cette excuse, “je n’ai pas le temps”. Une affirmation incorrecte, qui ne veut pas dire grand-chose.

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).