Nous avons vu dans l’article ‘comment gérer la qualité logicielle’ la nécessité de mettre en place des bonnes pratiques pour créer un terreau fertile et favorable.

Toutes ces pratiques, pour être correctement appliquées, doivent être comprises et assimilées, mais aussi et surtout, avoir l’adhésion des membres des équipes de développement ainsi que de l’encadrement.

C’est d’abord à la direction d’être convaincue de l’investissement nécessaire pour atteindre les objectifs de qualité et du retour sur investissement qu’il génère.

Il est donc primordial que l’ensemble des personnes impactant les projets soient sensibilisées aux problématiques de qualité, convaincues par leur intérêt afin de trouver les pratiques qui seront comprises et acceptées par tous.

Il faut avoir la capacité non seulement de bien expliquer ce qui doit être fait et ce qu’on attend mais aussi de laisser les personnes s’autogérer.

Si les personnes ne sont pas convaincues par les méthodes à mettre en place, elles ne les utiliseront pas, ou de manière inefficace ou encore, elles seront un frein à leur fonctionnement. Subir un processus amène à le contourner, à le transgresser voire même à tout mettre en œuvre pour prouver son inutilité.

Il est facile d’écrire des tests pour se donner bonne conscience mais s’ils ne sont pas pertinents et qu’ils ne vérifient rien, mieux vaut ne pas les écrire.

Impliquer les équipes

Plus vous impliquerez les équipes plus elles s’investiront et auront à cœur de progresser et se mobiliser dans un but commun, accomplir la mission.

Lorsque les règles sont définies, partagées et acceptées par tous, il faut se donner les moyens de les mettre en œuvre.

Pair Programming

Même avec la meilleure volonté du monde, un débutant non cadré à qui l’on met la pression a peu de chance de livrer un code conçu dans les règles de l’art quand bien même il a toutes les règles de bonnes pratiques en main. Le tutorat, la revue de code ou l’accompagnement par des personnes expérimentées permettent de démarrer dans de bonnes conditions et de la bonne façon sur des technologies nouvelles ou mal maîtrisées par l’ensemble de l’équipe. De plus, une équipe de développement est souvent hétérogène en termes de connaissance ou d’expérience. Le partage au sein de l’équipe est alors primordial.

Sur le même sujet | Pair Programming : Principes et retours terrain

Partager la connaissance

De la même manière, un seul développeur star certes brillant qui est le seul à maîtriser le sujet et qui se rend indispensable est dangereux. S’il quitte le projet, il emmène avec lui toute la connaissance. Le partage continu de connaissances est source d’enrichissements mutuels. Il n’est d’ailleurs par rare que le spécialiste en question ait une vision erronée sur un sujet par manque de recul et qu’un regard neuf, un échange productif permettent d’améliorer l’application. Former des équipes par projet, les plus petites possibles, mais rassemblant toutes les compétences permet de fluidifier la circulation de l’information.

Se méfier de l’euphorie

Un aspect important pour la productivité d’une équipe est sa motivation, son enthousiasme, son envie de voir avancer le projet. Mais attention, il ne faut pas confondre enthousiasme et précipitation. C’est humain, les tâches qui ne se voient pas ou ne font pas avancer le projet fonctionnellement peuvent être considérées comme trop chronophages et être passées aux oubliettes. Chacun veut se rassurer sur sa capacité à réaliser la tâche à laquelle il est affectée et il veut voir le résultat au plus vite. Cette volonté d’avancer vite peut s’accompagner d’un manque de réflexion, de conception, et surtout de tests.

La prise de conscience de l’importance des pratiques qualité par l’ensemble de l’équipe permettra d’accroître l’intérêt des membres sur celles-ci, elles ne seront plus reléguées aux tâches secondaires mais feront partie intégrante du développement jusqu’à devenir naturelles.

La documentation

Evidemment, cela va sans dire, mais on le redit quand même, il faut documenter « suffisamment » le code et les besoins fonctionnels auxquels il répond afin de comprendre et pouvoir intervenir sans trop de difficulté dans l’application. La documentation doit être utile et utilisable. Notre deuxième article sur la qualité logicielle est essentiellement consacré à la documentation.

Méthodologies agiles et démarche DevOps

Replacer l’humain au cœur du dispositif et privilégier la mise en place d’une organisation basée sur la collaboration agile et sur la recherche permanente de l’amélioration afin d’être en mesure de réajuster le cas échéant. D’un point de vue humain, les méthodes agiles permettent une collaboration permanente tout comme la démarche DevOps. Cette collaboration entre les experts fonctionnels et les développeurs est, selon nous, le secret d’une mobilisation dans un but commun : mener à bien la mission !

Le fonctionnement dit « en silo » qu’on dénonce désormais lorsque l’on cherche à appliquer les méthodes agiles au développement de solutions logicielles vaut également pour la constitution des équipes. Une équipe est souvent prête à changer d’outils ou de méthodes de travail, mais modifier son environnement de travail, être prêt à échanger avec d’autres collègues, accepter une nouvelle organisation des équipes, … est souvent sujet à de nombreuses résistances. D’où l’importance de communiquer, d’expliquer, d’impliquer. En encourageant les idées créatives, et en décentralisant les prises de décision, les équipes peuvent gagner en indépendance et tenter de nouvelles approches de travail.