Une approche de la qualité logicielle...

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:

• fortement liée à un contexte et l'article de Kathy Iberle l'illustre merveilleusement bien
• complètement subjective!

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:

• Les clients finaux ou une population représentative
• Les gens du marketing qui travailleront sur le rayonnement de l'application
• Les gens du métier. Eux définiront ce que l'application doit faire, le service rendu
• Les "techos" où je regroupe pêle-mêle architectes techniques, développeurs, exploitants...Ces personnes auront en charge de concrétiser les envies des populations précédentes.

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

• "time-to-market": une application de souscription de contrat d'assurance qui ne serait pas en production lors de la période annuelle de renouvellement pourrait rester inutilisée l'année suivante et finalement manquer son but: promouvoir et vendre les nouveaux produits.
• la satisfaction client aussi bien dans le cadre de relation B2B que B2C
• l'innovation métier et des outils mis à disposition
• l'absence de problèmes juridiques liés à l'utilisation des outils (donc de l'application) mise à disposition (mécanismes de non répudiation des opérations financières, de répression des fraudes...)

Du point de vue du client, la notion de valeur pourrait être vue comme:

• L'ergonomie de l'application, son intuitivité voire l'estime de soi qu'elle renvoie
• La performance, la fluidité de l'application dans son utilisation
• Le gain de temps que permet l'application cible dans la réalisation des procédures ("La nouvelle application permet de réaliser tel process métier avec un gain de temps de 13% par rapport à l'ancien logiciel"...)

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

• "La peur de..." est purement contextuelle au métier mais surtout aux hommes. L'article est éloquent: un critère "time to market" qui peut être prépondérant dans un contexte donné devient anecdotique dans un autre au regard d'un risque juridique qui prendrait le dessus...

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

• La "peur de..." permet de tirer les points essentiels, ce qui "a de la valeur" pour le groupe et surtout, sur cette base, d'arbitrer de justifier des remises en causes, des replanifications...bref de piloter. La peur du problème juridique sera peut-être plus importante que le "time-to-market", justifiant ainsi d'une replanification de la date de mise en production. A l'inverse, un "time-to-market" prépondérant permettra d'arbitrer sur la fonctionnalité dont il faudra se passer pour respecter cette date.

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!

• de plus, la "peur de..." permettra de mettre en oeuvre des pratiques pour se prémunir de la "sanction". Certaines de ces pratiques sont propres aux contextes, aux projets mais la plupart sont issues de la mémoire de notre industrie, sur la base de nos échecs (et en se posant la question "comment faire pour que la prochaine fois, cela ne se reproduise pas....?)

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?