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

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

Derniers articles
Showing 5 comments
  • christophe Grosjean
    Répondre

    En ce qui concerne la dette technique – et pire – cet article de Léon Tranter pourrait en intéresser certains.

    https://www.extremeuncertainty.com/technical-debt-technical-bankruptcy/

    J’avoue que le présent blog me laisse sur une impression de demi mesure reposant sur des outils indicateurs – qui ne détectent que le plus facile – et du micro-management – quand il y a un problème on prévoit une réunion et on désigne un responsable. C’est sans doute une impression fausse?

    • Cédric Teyton
      Cédric Teyton
      Répondre

      Merci pour votre commentaire et pour votre lien. Nous sommes ravis de voir que la qualité du code est un sujet qui prend de plus en plus d’importance.

      Pour vous répondre, le message que l’on fait passer à travers ce blog est que la volonté de maintenir un haut qualité de code doit se traduire par une démarche à tous les niveaux du département IT d’une entreprise, voire même de la direction. Cette démarche doit être concertée et validée par tous les acteurs pour être efficiente.

      En ce qui concerne les outils, il faut toujours être prudent avec les indicateurs remontés par des outils. De plus, un outil est rarement la solution miracle à tout problème, c’est bien pour cela que nous insistons sur les workflows des équipes et la démarche globale de qualité, accompagnés d’un support outillé. Il faut donc avoir une vision plus large des objectifs de qualité et de l’impact de ces outils.
      Il faut tout même reconnaître que ces outils sont de plus en plus performants notamment dans la détection de défauts dans le code, ce qu’on appelle des « code smells ». Un code smell n’est pas nécessairement la source d’un bug futur, mais on sait grâce notamment à plusieurs études que plus il y a de code smells dans une base de code, plus le risque d’y voir apparaître des bugs est important. Les données identifiées par ces outils constituent donc un support pertinent pour les équipes de développement.

      Concernant le management, nous soulignons surtout l’importance d’établir des responsabilités (et non des responsables) pour mener à bien une démarche. De plus, le management n’a pas à désigner tel ou telle personne responsable de la dette technique d’un logiciel. En fait, si on cherche une responsabilité, elle viendra souvent du management : si ce sont effectivement les développeurs qui écrivent le code, ce ne sont pas toujours eux qui décident des différentes deadlines et des moyens et outils mis à disposition pour leur travail. Ils s’adaptent en fonction des directives données et de la culture d’entreprise.
      Comme le mentionne par exemple votre lien, le fait que tout le monde accepte et comprenne que les développeurs consacrent du temps à des opérations de refactoring, sans que cela soit retranscris dans une quelconque user story, est déjà une première avancée.

      En tout cas, n’hésitez pas à réagir et à nous redonner de très bon pointeurs, car comme nous vous semblez convaincu que les développeurs ont un rôle central à jouer dans ce domaine.

  • Zoé Thivet
    Répondre

    Je découvre aujourd’hui la solution Themis. La piste de la gamification est très intéressante ; combien de fois voit-on des instances SonarQube qui tournent dans le vide, des règles de code qui sont assouplie pour que le build passe, bref des « projets de qualité de code » qui en réalité s’arrêtent juste à la fin de l’implémentation de l’outil…

    Une question cependant : comment réagissent les personnes initialement peu engagées dans la qualité de code ? J’ai l’impression que la gamification est capable de créer davantage d’émulation auprès de ceux qui étaient déjà sensibles au sujet auparavant, mais qu’elle laisserait de marbre ceux qui se contentaient de dire « tant que le code fonctionne ! »

    Qu’en est-il en pratique ?

    • Cédric Teyton
      Cédric Teyton
      Répondre

      Merci pour votre message Zoé, je vous rejoins sur votre constat.
      Pour répondre à votre question, la gamification constitue un vecteur d’engagement qui complète les retours personnalisés que proposent Themis.
      De ce qu’on a pu observer sur le terrain, la gamification amène une émulation collective qui finalement consolide l’adhésion des personnes déjà sensibles, et s’avère être un déclic pour celles qui le sont un peu moins. Si la gamification est conçu dans un esprit sain et amical (c’est comme ça que nous avons essayé de le faire dans Themis), tout le monde est récompensé et chaque type de « joueur » y trouve son compte. A partir du moment où la volonté de veiller à la qualité du code est de plus en plus présente au sein d’une équipe, les personnes qui se contentaient de dire « tant que le code fonctionne » finissent progressivement par rejoindre le mouvement, pour le bien collectif.

      • Zoé Thivet
        Répondre

        Merci pour votre réponse. Cela donne envie de tester !
        Je garde un oeil sur votre blog, les articles sont vraiment intéressants.
        Bonne continuation

Laisser un commentaire