Les 3 erreurs à ne pas commettre dans la gestion de la qualité logicielle

La gestion de la qualité logicielle est un enjeu complexe qui s’avère déterminant dans la réussite d’un projet : avoir une faible dette technique, mettre en place des tests automatisés, voilà des pratiques de gestion qui permettront à terme d’obtenir un engagement fort de vos équipes et ainsi d’améliorer la satisfaction de votre client.

Cette complexité se traduit par une certaine fragilité dans la gestion car gérer la qualité est un véritable château de cartes. En effet, toute volonté peut être rapidement annihilée si la démarche n’a pas été rigoureusement planifiée et définie.

Quelles sont les raisons pour expliquer une situation d’échec vis-à-vis de la gestion de la qualité ? Je vous en propose 3 dans cet article. J’irai même jusqu’à dire que ces aspects sont dépendants les uns des autres. Si un des maillons devient défaillant, toute la chaîne est impactée et les chances de succès sont clairement diminuées.

#1 Oublier de définir les responsabilités de gestion de la qualité

Pourquoi est-ce un problème ?

Gérer la qualité implique la mise en place d’outils de pilotage et de suivi de la qualité pour atteindre des objectifs fixés. Mais souvent, on s’aperçoit après le démarrage d’un projet que personne n’en est responsable…

“Je ne suis pas propriétaire du code, je n’ai pas à m’occuper de la qualité”, “Je n’y connais rien en programmation, je fais confiance à mon prestataire”… Mme TrustCoders

Que ce soit par négligence ou par choix assumé, si la question de la qualité n’est pas abordé au début d’un projet, il est peu probable qu’elle ne le soit par la suite. Et dans le cas où elle l’est, sa mise en oeuvre complexe la rendra périlleuse, surtout si aucune ressource n’y a été allouée. En l’absence d’objectifs sur la qualité, les équipes n’y consacreront que très peu de temps, ne sachant pas dans quelle direction aller. Si des objectifs sont fixés mais que personne n’est responsable de contrôler leur suivi, ceux-ci vont petit à petit sombrer dans l’oubli le plus total et leur chance de succès seront clairement amoindries. Lors des rétrospectives de fin de projet, ce sujet sera même certainement passé sous silence.

Pourtant, un des objectifs de la qualité logicielle est de réduire les coûts de maintenance futurs et de réduire le risque de bugs autant que possible. Ne pas gérer la qualité revient donc à ne pas traiter ces enjeux et subir leurs conséquences plus tard.

Comment éviter de reproduire cette erreur ?

D’une manière générale, il faut prendre en considération le contexte du projet. Si vous travaillez sur un projet avec un client, ce dernier peut exiger un certain niveau de transparence sur la qualité des développements produits, surtout s’il est le propriétaire du code (notamment en cas de Tierce Maintenance Application, TMA). Vous aurez de vôtre côté tout intérêt à démontrer votre maîtrise de la gestion de la qualité, rassurant ainsi le client sur des risques de futurs coûts de maintenance imprévus. Vous montrez ainsi que ce dernier paiera le prix juste et que vous déployez des moyens pour respecter cet engagement. Si à l’inverse vous travaillez sur un projet en interne, c’est à vous de prendre en charge cette gestion et de définir quelles personnes dans l’équipe en sont responsables.

Les parties prenantes doivent définir avant le démarrage du projet quels sont les objectifs à atteindre, et quels moyens vont être mis en oeuvre pour y arriver. Il convient de définir des jalons intermédiaires ou encore des tableaux de bords partagés, en convenant des indicateurs qui doivent y figurer. Si votre client n’est pas familier avec les enjeux de la qualité logicielle, ce sera l’occasion pour vous de démontrer votre savoir-faire et votre expertise, en expliquant par exemple l’importance de maintenir un code de qualité. Faire preuve de pédagogie augmentera la confiance que votre client vous accorde, car il y a de fortes chances qu’il apprécie le bien fondé de la démarche. Dans tous les cas, il est vital d’identifier de façon claire les rôles et les implications des parties prenantes afin qu’il y ait une vision claire et partagée de qui fait quoi, quand et comment.

#2 Ne pas intégrer la qualité dans le workflow des équipes

Pourquoi est-ce un problème ?

“Nous avons branché un outil qui calcule la dette technique sur notre code et qui se met à jour chaque nuit. Il est à disposition des équipes, mais le problème c’est que personne ne regarde“. M. ManagerEnDepit.

Cette phrase est symptomatique d’une organisation qui doit encore s’améliorer pour atteindre les objectifs qu’elle s’est fixés en termes de qualité. Une équipe qui n’accorde pas assez de place à la gestion de la qualité dans son organisation subit une baisse d’engagement sur ces questions, puisque les objectifs fixés deviennent de moins en moins prioritaires. 

Si on ne sait pas à quelle moment de la semaine on discute de la qualité, ni quand est-ce qu’un suivi est fait et rapporté aux équipes, cela impacte la motivation des développeurs à se consacrer aux tâches liées à la qualité. Si quelques personnes dans l’équipe deviennent de moins en moins vigilantes sur ces aspects, des premiers symptômes peuvent apparaître : une dette technique qui commence à augmenter ou encore une couverture de test qui tend à diminuer.

Comment éviter de reproduire cette erreur ?

Il est bien entendu encore temps de réagir avant que les symptômes s’aggravent. C’est surtout une histoire de changement de comportement qu’il faut accompagner progressivement. Il s’agit dans la majorité des cas de réglages et d’ajustements dans l’organisation de l’équipe. 

Une piste pour démarrer est de s’inspirer des mécanismes inhérents aux méthodologies agiles : fixer des cérémonies dédiés à la qualité (des rétrospectives, des points hebdomadaires), partager les objectifs, itérer régulièrement pour observer leur avancement, fixer des rôles dans les équipes (définir un “Quality Owner” à tour de rôle par exemple)… Le défi est de faire les choix les plus pertinents en fonction des équipes, en prenant en compte leur culture, leurs habitudes et leur état d’esprit. Les équipes étant de plus en plus agiles et autonomes, elles sont même tout à fait en mesure de traiter elles-mêmes ces points.

Une bonne organisation a un impact direct sur l’engagement des équipes. C’est une façon de valoriser leur travail et il sera toujours plus plaisant de travailler sur un code propre. Certes, il est frustrant de passer sa journée en compagnie d’un code qu’on a en permanence envie de restructurer. Mais après tout, pourquoi y passer du temps si derrière personne n’y porte d’attention ? Sur ces problématiques d’engagement, libres à vous d’innover et de trouver la solution la plus adaptée. Un axe que nous avons emprunté chez ProMyze mène à la Gamification que nous avons intégrée dans Themis.

#3 Déployer des outils qui ne couvrent qu’une partie des besoins

Pourquoi est-ce un problème ?

“L’outil qui calcule la dette technique manque de fonctionnalités pour m’aider à prendre des décisions”. Mme AidezMoi.

Lorsqu’on gère la qualité logicielle, plusieurs outils sont déployés dans le but de répondre aux questions suivantes : comment atteindre les objectifs de qualité ? Et comment mesurer leur réussite ? Ainsi, pour reprendre l’exemple ci-dessous, s’il est pertinent d’avoir des outils d’analyse, il est tout aussi important d’avoir des outils d’aide à la décision : que faire avec une dette technique importante ? Comment puis-je définir des tâches à mon équipe ? Comment évaluer le ROI de la démarche ?

Si il vous manque des éléments de réponse, il y a un risque que les objectifs initialement fixés soient difficile à atteindre et à mesurer. Certes, les outils sont généralement utilisés en support d’un autre travail parfois plus manuel qui consiste à rassembler différentes informations. Néanmoins, gérer la qualité ne doit pas devenir trop gourmand en temps pour les personnes qui s’en occupent. Gardez toujours cet impératif d’efficacité : si la qualité permet de réduire les coûts de maintenance, elle ne doit pas représenter une part trop importante de votre budget.

Comment éviter de reproduire cette erreur ?

Une première étape consiste à faire un état de lieux des outils actuellement mis en place. Ces derniers sont-ils limités en termes de fonctionnalités ? Ou peut-être en faites-vous une sous-utilisation ? Quelque soit la raison, l’objectif est de comprendre comment les manques peuvent être comblés, que ce soit grâce à des outils numériques ou par un autre moyen. L’accumulation d’outils étant déconseillée, concentrez-vous sur l’essentiel : de quoi avez-vous réellement besoin ? Qu’est-ce qui est superflu et dont vous pouvez vous passer ?

N’oubliez jamais que chaque outil déployé doit remplir une fonction bien précise (ex : reporting, génération de données, automatisation de tâches…) et s’exécuter dans un périmètre bien défini (ex : analyse statique de code, calcul de la couverture de test, intégration continue). Leur rôle et leur gouvernance au sein du projet doivent être clairs et compris par l’ensemble des équipes. Chaque membre doit avoir assimilé à qui s’adresse tel ou tel outil, à quel moment il doit être utilisé et quelle tâche il remplit.

Encore une fois, il est important d’avoir discuté de la gestion de la qualité en amont du projet. C’est à ce moment-là que seront justement définis les outils utilisés, qui pourront ainsi être aisément pris en compte dans le budget à allouer. Enfin, je vous conseille également de régulièrement discuter en interne des outils actuellement en place et de faire des retours d’expérience partagés, afin d’identifier des manques nouveaux et ainsi anticiper cela pour un projet futur.

Et maintenant ?

En conclusion, si certains de ces aspects ont fait écho à des problématiques que vous rencontrez régulièrement, essayez de comprendre les symptômes et les pistes d’amélioration. Je vous ai présenté 3 points dans cet article, mais il y en a certainement d’autres, que je vous invite d’ailleurs à partager ici.