Dans un papier pas tout récent puisqu'il date de 2003, they don't care about quality, Kathy Iberle expose un sentiment communément (en tout cas déjà par moi) ressenti: "Ils se foutent de la qualité!", "Ils" étant bien entendu les autres...
Kathy illustre ce jugement à l'emporte-pièce en comparant une définition de la qualité dans un cadre médico-légal et une autre définition de la qualité chez un fabriquant de cartouche d'encre...Deux univers, deux définitions qui lui permettent de proposer quelques clés permettant de sortir de ce concours de mauvaise foi.
Alors qu'en est-il? Weinberg définit la qualité comme (désolé pour la traduction) "ce qui apporte de la valeur à quelqu'un"...Reste que, la notion de "valeur apportée" est:
Rajoutons à cela le fait qu'un logiciel, une application se constitue - enfin normalement...- en groupe, cela en devient complètement obscur. Et si on se dit que ce groupe de personnes vient d'horizons différents, ne parlent donc pas le même "langage", n'ont pas les mêmes priorités...alors là! Tout cela sans intégrer à l'équation le nerf de la guerre: l'ego et les problématiques de territoire (celles-là même qui font des entreprises de potentiels grands champs de bataille...)
Dans mon monde de grand rêveur, j'ai (au moins) envie de voir les populations suivantes participer à la création d'une application:
Avec autant d'"ethnies", comment définir la valeur apportée à quelqu'un? Compliqué. Des points de vue métier et marketing, ce qui pourrait avoir de la valeur
Du point de vue du client, la notion de valeur pourrait être vue comme:
Du point de vue technique, les classiques éléments de valeurs seraient la productivité des développements, les aspects maintenabilité du code, les aspects architectures applicatives et logicielles
Bref, sans dresser une liste à la Prévert, l'alignement sur les notions de valeurs apportées ne semble franchement pas évident.
Alors comment trouver une définition commune de la qualité? Comment aligner ces acteurs sur une cible qualité?
Sur ce point, je trouve la réponse apportée par Kathy d'une pertinence rare: "définir en commun les 10 plus grandes peurs concernant l'application"! et donc, indirectement, définir ce contre quoi on souhaite se protéger...
Sur les aspects humains, les "peurs de..." sont fortement liées aux équipes en place, à leurs compétences, au niveau de confiance établi entre les individualités qui la composent: la notion de cordée, le binôme, la capacité à oser "ensemble", la capacité à sortir des zones de confort pour en appréhender d'autres plus inconfortables, plus délicates jusqu'à ce qu'elles deviennent à leur tour naturelles et donc confortables.
A titre d'exemple, imaginez une équipe formée uniquement d'individus n'ayant aucune expérience du développement d'applications JEE, il y a des chances que les craintes soient liées à l'utilisation de tel ou tel framework open source par eux inconnu. A l'inverse, prenez une équipe d'experts, peut etre que leurs craintes seront plus centrées sur la complexité métier de tel ou tel service, ou la mise en place d'un ws-reliability ou autres stacks technologiques improbables. Et si vous prenez cette même équipe d'experts et que vous imaginez un fort niveau de confiance entre les individus - c'est à dire qu'il n'y aura pas de jugements en cas d'échec, que l'investissement de chacun est acquis - alors, peut etre que la mise en place de ws-reliability deviendra une crainte que l'on osera affronter.
Les critères "peurs de..." sont ainsi adaptés à l'équipe en place, à ses "capacités".
Si en une ligne, on évoque les aspects méthodologiques, les méthodologies "effets tunnel" ne permettent pas ce type de remise en cause. Les méthodologies itératives, incrémentales si!
La peur de ne pas être capable de maintenir du code facilitera la mise en place de harnais de test. La peur d'avoir "mauvaise réputation" justifiera un effort très important sur les phases d'homologation. La peur de perdre xx millions d'euros sur un cas fonctionnel limite justifiera l'effort de test important qui mène à xxx% de couverture de test
Reste ensuite (notez que tout est dans le "ensuite"...) à acter collégialement du fait que le logiciel n'ira pas en production tant que la qualité telle que définit précédemment ne sera pas au rendez-vous! et réussir à parler de façon collégial et ouverte de ces "peurs de...".
Alors pour les sceptiques, observons nos propres comportements afin de voir ce qui oriente voire contraint nos choix professionnels et surtout personnels dans des situations critiques: l'absence d'envie ou la peur d'une sanction?