“Ce que l’on conçoit bien s’énonce clairement”
“… et les mots pour le dire arrivent aisément”
- Nicolas Boileau-Despréaux (1636 – 1711)
En tant que développeur·se·s, il nous arrive souvent de vouloir mettre en place une solution rapidement si bien que l’on fait peu attention au problème d’origine et à son contexte. Et c’est de là que viennent les bugs : on pense avoir compris, on émet des suppositions, on se borne à un ou deux scénarios… et on passe à côté du sujet.
C’est un problème qui me tient particulièrement à coeur ; il me semble important de ne pas sombrer dans le stéréotype du développeur qui accorde plus d’importance à la technique qu’au problème remonté par les utilisateurs. C’est une simple question de professionalisme : que penserions-nous d’un réparateur d’électro-ménager qui changerait tout le bloc moteur d’un frigo sans s’occuper du problème de fuite que nous lui avons signalé ? Ou qui nous conseillerait carrément de changer tout le frigo ?
Une relation saine avec le métier
La base pour fournir un logiciel de qualité est d’avoir une relation cordiale avec les utilisateurs. De mon expérience, s’il y a de la méfiance voire de la défiance entre l’IT et les utilisateurs, alors les points principaux ne seront pas adressés, l’IT sera vue comme un centre de coûts et peu de valeur sera apportée à l’entreprise. Il est donc primordial de prendre le temps d’écouter les demandes ; je ne dis pas qu’il faut tout accepter, il est même vital de savoir challenger les utilisateurs, mais il faut le faire intelligemment et avec la manière.
“Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.”
Des pratiques de développement cohérentes
J’utilise quotidiennement des pratiques telles que le TDD et l’intégration continue afin de bien maîtriser la qualité du code que je livre. Je m’intéresse par ailleurs fortement à la philosophie DevOps, d’une part pour bien comprendre les enjeux de gérer un environnement de production mais aussi tout simplement pour voir comment le logiciel que je livre est déployé et maintenu. Pour cela, je pense que toute livraison en production doit être un non-événement. Notamment en sécurisant toute la chaîne en amont (tests automatisés, connaissance partagée du code et des besoins…) ou en permettant de livrer rapidement et facilement (trunk-based development, livraison voire déploiement continus).
L’amélioration continue comme moyen de progresser
Je suis conscient que certaines pratiques ne peuvent s’effectuer que dans de bonnes conditions. Par exemple, il n’est pas envisageable de faire du déploiement continu si tout le monde dans l’équipe n’est pas convaincu de l’utilité des tests automatisés. Le mob programming, que j’ai découvert récemment, permet à la fois de créer du code de qualité mais aussi que chacun présente à tout le monde des nouvelles façons de faire dans un cadre concret.
Je suis aussi très amateur de sessions régulières de katas sur le temps de travail, idéalement une séance de 2h par semaine, pour permettre à tout le monde de découvrir et tester des choses sur des problèmes simples hors du cadre du code de production, donc de façon plus détendue.
