XP expliqué à un apôtre de la qualité

Beaucoup de sociétés impliquées dans du développement logiciel mettent en avant leur démarche qualité. Rien de très étonnant à cela. Les contraintes du marketing font que si les autres font de la qualité (et le font savoir) et que soi même on n'en fait pas (ou on ne le fait pas assez savoir), les autres seront considérés comme faisant de meilleurs produits ou rendant de meilleurs services.
Il faut cependant remarquer qu'il y a qualité et qualité. La démarche qualité dans l'industrie du logiciel est avant tout une histoire de processus : maîtriser au mieux les étapes qui vont de l'expression des besoins au produit fini. Si on a de la chance, on aura aussi un processus en amont pour aller des attentes du client jusqu'à l'expression des besoins. Faire un produit de qualité, c'est autre chose. C'est faire un produit que le client, l'utilisateur considèrera, avec toute sa subjectivité, comme étant de qualité ! La démarche et les processus qui auront servi à arriver au résultat n'auront, en fin de compte, que bien peu d'importance.

Les méthodes agiles, et tout particulièrement XP, sont réputées pour ne s'intéresser que de loin aux formalisations des démarches qualité mais où se situent-elles vraiment pour ce qui est de réaliser des produits de qualité ?
Il y a quelques années (début 1998 pour être précis), j'avais été confronté, lors d'une revue de process à une responsable qualité qui me demandait où était la matrice de traçabilité entre les fonctionnalités et la décomposition architecturale issue de la conception. Je n'avais pas une telle matrice. Sauf cas particuliers, une architecture logicielle est assez orthogonale à une décomposition fonctionnelle. Le propre des composants réutilisables, c'est d'être réutilisé et faire une telle matrice revenait, pour moi, à noircir une feuille de papier pour cocher la quasi-totalité des cases : rares étaient les composants dédiés à une seule fonctionnalité ou à un faible nombre d'entre elles.
Je n'avais pas une telle matrice mais, pour satisfaire au processus décrit dans le manuel qualité, j'en ai rajouté une. Pensez-donc ! Le projet allait faire partie de l'audit pour le renouvellement de la certification ISO 9001. Ce n'était pas vraiment le moment ni l'endroit pour argumenter sur l'utilité de tel ou tel processus.
Ce n'était pas ma première confrontation avec ce genre de processus mais ce fut, pour le coup, la dernière où j'ai suivi à la lettre les procédures décrites dans le manuel du bon petit soldat.
Est-il utile de préciser que la matrice en question a gentiment été rangée dans un document où elle a certainement pu depuis accumuler une certaine couche de poussière ?

Je suis sûr que de nombreuses personnes ont été, ou sont encore, confrontées à ce genre d'évènement. Le fond du problème, c'est que, par l'instauration d'une démarche, d'un processus, les notions de qualité ont été peu à peu externalisées du processus de développement en tant que tel. Rien d'étonnant à ce que, dans un tel contexte, les développeurs se sentent moins impliqués dans la qualité de ce qu'ils produisent car cette qualité est définie par des critères et des activités complètement étrangers à leurs préoccupations quotidiennes. Le client est-il mieux loti ? Pas vraiment. Même s'il s'intéresse au processus de fabrication du logiciel, processus pouvant être garanti avec une certification quelconque (ISO, CMMi, ...), celui-ci est trop éloigné de sa préoccupation principale : la qualité du produit fini.

Jetons un oeil sur l'historique des définitions de la qualité par l'ISO 9000 :

  • 1982 : Aptitude d'un produit ou d'un service à satisfaire, au moindre coût et dans les moindres délais les besoins des utilisateurs.

  • 1987 : Ensemble des propriétés et caractéristiques d'un produit ou d'un service qui lui confèrent l'aptitude à satisfaire des besoins exprimés ou implicites.

  • 1994 : Ensemble des caractéristiques d'une entité qui lui confère l'aptitude à satisfaire des besoins exprimés et implicites.

  • 2000 : Aptitude d'un ensemble de caractéristiques intrinsèques à satisfaire des exigences.

La définition évolue au fil du temps. De "produit ou service" défini par ses "caractéristiques", on est passé à une "entité" pour finir dans un néant ou seules comptent les "caractéristiques" en tant que telles. Elles sont devenues "intrinsèques". Cela n'a finalement que peu d'importance. Je suppose que l'idée sous-jacente est qu'il n'est pas facile de définir à quoi s'appliquent les notions de qualité : "produit ou service" est probablement une définition trop restrictive.
Ce qui est plus intéressant, c'est comment cette qualité est mesurée. De "besoins des utilisateurs au moindre coût et dans les moindres délais", on passe à "besoins exprimés ou implicites", car, après tout, les coûts et les délais sont des besoins comme les autres. On notera qu'ils peuvent être implicites, c'est à dire que leur expression n'est pas nécessaire pour juger de la bonne ou mauvaise qualité. Cela tranche avec la définition la plus récente où l'on ne parle plus que d'"exigences" qui, elles, par définition, ne peuvent être qu'exprimées.

Tout ça pour dire que si l'on se limite à la réalisation d'un logiciel, donc un "produit", la définition la plus large que l'on puisse trouver de la qualité c'est la concomitance des caractéristiques de ce produit avec des attentes exprimées ou implicites. L'absence de qualité, c'est laisser des attentes insatisfaites ou répondre à des attentes qui n'en sont pas. Rien de plus, rien de moins.

Attentes et réponses

Ceci étant dit, même si la qualité est jugée, entre autres, sur des attentes implicites, il y a fort peu de chances pour que celles-ci soient prises en compte à un moment ou à un autre si personne ne les exprime. La réalisation du produit étant avant tout une affaire de personnes, un client et un fournisseur, une communication entre ces personnes est nécessaire pour retrouver l'aptitude à satisfaire les attentes dans le produit fini.
Donc une définition un peu plus classique de la qualité prend en compte ce paramètre. La qualité d'un logiciel, c'est la concomitance (1) d'attentes exprimées ou implicites, (2) de leur expression, (3) des caractéristiques du logiciel livré.

Attentes, expression et réalisation

La définition mettant en jeu l'expression des attentes permet donc de dresser une liste un peu plus fine de causes de non-qualité :

  • Les défauts (ou, plus trivialement, les bugs), attentes exprimées mais non réalisées

  • La sur-qualité, caractéristiques exprimées et réalisées mais inattendues

  • La qualité aléatoire, attentes non exprimées mais réalisées

  • L'insatisfaction, attentes non exprimées et non réalisées

  • L'illusion, expression de caractéristiques qui ne sont ni attendues, ni réalisées

  • Le gaspillage, caractéristiques réalisées mais ni attendues, ni exprimées

Attentes, expression et réalisation suite

Il faut maintenant déterminer si un processus de développement tel que XP prévoit des activités, des pratiques, permettant de minimiser les causes de non-qualité.

L'illusion et la sur-qualité ont une chose en commun : elles sont issues de l'expression de caractéristiques non attendues. Qui pourrait vouloir faire cela ? Quelle que soit la méthode utilisée, personne, a priori, ne va s'amuser à spécifier sciemment des caractéristiques, des fonctionnalités tout en sachant pertinemment que le client n'en a pas besoin. Mais inconsciemment ? Pour savoir cela, il faut se demander deux choses : qui va exprimer les attentes et combien d'attentes faudra-t-il exprimer simultanément ?
Dans le pire des cas, les attentes sont exprimées par quelqu'un qui n'a qu'une lointaine relation avec le client réel, celui qui va effectivement utiliser le logiciel réalisé. Dans le plus-que-pire des cas, cette même personne va devoir exprimer en une seule fois un ensemble d'attentes dont la combinatoire des interactions dépasse les capacités du cerveau humain. Le logiciel a ceci de magique que le rajout de fonctionnalités permet de rapidement engendrer une explosion combinatoire de séquences d'utilisation.
XP propose de simplifier les choses selon 2 axes. En mettant le client au coeur de l'équipe, le on-site customer, on s'assure que les attentes exprimées seront les bonnes. En ne gérant que des ensembles volontairement limités de fonctionnalités, les small releases, on limite les besoins de prise en compte simultanée d'un trop grand nombre d'attentes. Ces attentes se retrouvent, dès lors, échelonnées dans le temps.

Le gaspillage et la qualité aléatoire ont aussi une chose en commun : ils sont issus de la réalisation d'attentes non exprimées. Qui pourrait se retrouver dans une telle situation ? Dans la plupart des méthodes de développement, l'expression des attentes est la base du travail de réalisation. De multiples documents de spécification ou de conception peuvent, certes, jouer un rôle intermédiaire entre l'expression des attentes et le produit fini mais ces documents sont censés refléter les attentes initiales. Et c'est d'ailleurs là qu'est le problème : ils ne les reflètent pas forcément. Qui, dans son enfance, n'a jamais joué au téléphone arabe ?
A force de multiplier les artefacts intermédiaires, on en arrive à perdre l'essentiel, ou, du moins, à être obligé de mettre en oeuvre des usines à gaz pour ne pas le perdre.
En XP, les choses sont bien plus claires. Le planning game déroulé en début d'itération permet de déterminer avec précision les attentes à satisfaire dans la courte plage de temps à venir. A un niveau plus proche du code, le test driven development rend le même service : on fait ce qui est attendu et on ne fait que ce qui est attendu à l'instant présent. Cette idée est depuis longtemps un des chevaux de bataille des promoteurs de XP : YAGNI !

L'insatisfaction et les défauts, enfin, ont aussi une chose en commun : ils sont issus d'attentes non réalisées. Les défauts sont un problème que beaucoup de méthodes savent gérer. Quoi de plus systématique que de corriger des bugs ? Pour les insatisfactions, c'est une autre paire de manches. Quand les plans de validation proviennent d'équipes auto-proclamées "d'assurance qualité", on peut légitimement se demander si elles vont être capables d'aller au delà de la simple détection de bugs. Pour ça, il leur faudrait être capable de tester des choses qui n'ont pas été exprimées.
Comme on pouvait s'y attendre, XP adresse aussi ces questions là. En favorisant les customer tests, les tests écrits par le client, on minimise les risques de laisser des attentes non réalisées, et ce, même si elles n'ont pas été exprimées. Seul un vrai client est capable, au moment où il utilise le produit livré, d'imaginer les tests correspondant à des attentes que ni lui, ni personne d'autre n'était capable d'exprimer a priori.

Simplicité, courage, feedback et communication sont les valeurs fondamentales de XP. Comme on vient de le voir, la simplicité dans l'expression des attentes permet d'éviter d'exprimer plus de choses qu'il ne faudrait. Le courage dans la réalisation de ces attentes exprimées permet de ne pas réaliser celles qui ne le sont pas (encore), quitte à revenir dessus quand elles le seront. Le feedback apporté lors de la vérification des attentes permet d'exprimer progressivement celles-ci. La communication, transversale à toutes ces activités, permet de garantir leur bon fonctionnement.
On peut donc reprocher bien des choses à XP. Par exemple, sa trop grande rigueur, son inadaptation à de trop grandes équipes ou son manque de solution vis à vis de dépendances externes. Mais s'il est une chose que l'on peut difficilement lui reprocher c'est son absence de focalisation sur la qualité. A ma connaissance, c'est la méthode de développement la plus en pointe sur cet aspect là.