La qualité logicielle, une affaire de code ?

Un peu, mais pas tant que ça. Le code vient quasiment en dernier.

Si le mot "qualité" vous fait penser à "clean code", "test" ou "refactoring", loin de moi l'idée de vous blâmer pour cela. Toutefois, cela pourrait donner à penser que la qualité logicielle n'est qu'un sujet de compétences, ce qui est faux. La qualité logicielle est la résultante de toutes vos actions en tant que leader, technique (CTO) ou non technique (CEO). Non technique, en fait : en tant que coach, je tiens mon mandat du CEO.

• C'est une affaire de Produit : quel serait le sens de réaliser parfaitement un produit mal conçu ou, pire, qui ne répond pas au bon problème ? Aucun, bien sûr. Cette dimension concerne directement les développeurs, qui ne sont pas là pour "pisser du code" : ils doivent et souhaitent généralement s'impliquer dans la conception fonctionnelle, parce qu'on ne développe bien que ce qu'on comprend bien. Si le "pourquoi" n'est pas clair pour eux, le "quoi" et le "comment" ont peu de chances de l'être. D'où l'importance de pratiques telles que l'Example Mapping.

• C'est bien sûr une affaire d'Agilité. L'Agilité, que je suis de plus en plus tenté de définir comme "la lutte contre l'effet tunnel" : vous avez besoin de feedback pour déterminer le cap à tenir. Vous avez besoin de découper et prioriser votre travail pour parer à toute éventualité. La notion de User Story, si mal comprise et galvaudée, est centrale. L'Agilité est un sujet de qualité logicielle, parce que c'est ce qui fait que vous avez du logiciel en production, aujourd'hui, pas dans 6 mois ou jamais, et du logiciel qui sert ses utilisateurs.

• C'est aussi une affaire d'organisation. Par une mauvaise organisation, vous sapez tous les efforts de vos équipes et conduisez à l'épuisement les meilleures volontés. Une équipe "Front" et une équipe "Back", ça ne marche pas, dans aucun monde. La loi de Conway nous le dit : "les organisations créent des systèmes à l'image de leurs propres structures de communication". Dit autrement, un logiciel est correctement modularisé parce que les équipes sont correctement définies. Mieux vaudrait également éviter la fameuse équipe Support qui gère les externalités négatives des autres équipes : internalisez les externalités en appliquant le motto d'Amazon : "you build it, you run it".

• C'est naturellement une affaire de personnes : produire du logiciel de bonne qualité demande du courage, un courage qui suppose l'amour du travail bien fait. C'est donc un socle de valeurs auxquelles vous souhaitez que les membres de votre organisation adhèrent : rigueur, humilité, solidarité, pragmatisme… Faire vivre ces valeurs commence par le recrutement, puis il faut les perpétuer par un management adéquat et des actes concrets. Cela signifie par exemple libérer du temps à vos équipes pour l'échange et la formation, au travers de guildes.

• Et en parlant de personnes, c'est parfois une affaire de montée en puissance individuelle. Outre l'accompagnement que je propose aux organisations, le coaching des individus aide ces derniers à prendre l'ampleur que l'organisation attend d'eux. Il est particulièrement utile pour les primo-managers – a fortiori quand ceux-ci ont été promus pour leur compétence technique. Par le questionnement et l'expérimentation, le coaching leur permet de prendre de la hauteur, comprendre les attentes, de mieux appréhender des cas concrets et de se sentir in fine plus légitimes dans la fonction qu'ils occupent.

• Et c'est bien sûr une affaire de pratiques de développement et de savoir-faire technique.

Traiter la qualité logicielle par la seule dimension du code serait ainsi inefficient et inefficace. Il faut l'appréhender comme un sujet à plusieurs dimensions. C'est ainsi que j'accompagne mes clients et que j'obtiens les meilleurs résultats.