La mesure du logiciel

From: Timothy Newsham <newsham@aloha.net>
  To: 0xdeadbeef@substance.blackdown.org
Date: Fri, 14 Jul 1995 20:49:35 -1000 (HST)

Au début il y avait la métrique du logiciel. Avec ça, les développeurs de logiciels et leur hiérarchie pouvait mesurer quelque chose à partir de leurs méthodes de création des programmes. Ces techniques furent florissantes dans les années 80. De drôles de noms émergèrent, comme "McCabe complexity" et "software volume".

Bientôt, il devint clair qu'il y avait besoin d'une façon de mesurer non seulement la qualité du produit logiciel, mais aussi de mesurer la qualité de l'organisation du travail elle-même. Le "Capability Maturity Model" ou CMM fut mis au point dans les années 90. Les organisations sont auditées par des spécialiste et notées sur une échelle de 1 à 5. Un score bas signifie que le processus de production logiciel est chaotique, alors que 5 signifie que tous les aspects du développement logiciel sont pleinement compris et mis en oeuvre avec soin, assurant ainsi un produit de qualité à tous les coups. Triste à dire, aujourd'hui, beaucoup d'entreprises de logiciel valent à peine 1, et il y a un nombre surprenant de 0 qui trainent.

A présent, une technique de mesure révolutionnaire a été créée par une petite statup, une entreprise de consultant à Austin (Texas). Ce nouveau système est connu simplement sous le nom de DCF. La simplicité et l'élégance de cette nouvelle métrique démentent sa capacité à juger de la qualité d'une organisation de développement.

Le créateur de DCF et fondateur de la Fondation DiCoFact, Matt Sejnowski, affirme que le nouveau système de mesure est simple et à l'épreuve des idiots, mais que des modifications sont faites pour le rendre aussi blindé à l'égard du management.

Un Dimanche matin Matt était en train de se livrer au classique rituel de la lecture des rubriques importantes de son journal quand il arriva à sa bande dessinée favorite: "Dilbert" de Scott Adams. Matt et ses collègues de travail adorèrent la bande et furent étonnés de voir à quel point ce scénario fou leur rappelait ce qui se passait dans leur boite. Ils suspèctèrent même Scott Adams de travailler chez eux sous un déguisement, ou qu'il y avait un espion dans la boite qui donnait chaque jour ses idées à Scott. Matt a soudain eu une idée de génie qui promettait de rentrer des millions: Le Dilbert Correllation Factor (DCF).

L'idée de Matt est simple: Prenez au hasard 100 bandes dessinée de Dilbert, et présentez les dans le cadre d'une enquête auprès de votre personnel technique. En incluant les ingénieurs et les cadres. Chaque personne devra alors lire les bandes et marquer celles qui leut rappelle la façon dont fonctionne leur entreprise. Ramasser tous les formulaires, et comptez les marques. Cela vous donnera le facteur corélatif de Dilbert, qui va donc de 0% à 100%. Faites la moyenne des scores des ingénieurs. Bazardez les résultats des cadres, on ne les a questionnés que pour qu'ils se sentent importants; mais si plusieurs d'entre eux vous regardent d'un air menaçant, ajoutez 5 points à votre DCF (en terme technique, on appelle ça le MDFF (Management Dissing Fudge Factor)). Jetez aussi les résultats des ingénieurs morts de rire durant l'enquête et rappelez-vous de leurs noms pour les rencontrer ultérieurement. Et voilà, vous y êtes ! Oups, faites le tour des batiments et comptez le nombre de planches de Dilbert sur les murs, sans oublier la salle café, les panneaux d'affichage, les portes de bureau, et bien sur, les toilettes. Ajoutez donc jusqu'à 10 points pour ce coefficient d'ajustement de la densité Dilbertienne (DDCQ).

L'interprétation des résultats est simple:

0% - 25%:
Vous avez probablement un méthodologie d'assurance qualité du logiciel. Seulement, vos employés devraient être un peu éduqué. Il est probable que quelque réorganisation surprises, ou peut-être mettre en route un Programme d'Amélioration de la Qualité permettra de remonter le DCF de votre entreprise à une valeur plus saine.
26% - 50%
C'est aussi le signe d'une bonne organisation, et est presque idéal. Vous peinez pour sortir un produit d'une qualité correcte, et vous subissez tous les gags auquels seul les amateurs de Dilbert s'identifient. Appartenance obligé à une coterie, des échanges sans fin d'e-mails à propos des bons sigles à utiliser pour les produits de la boite, et bien entendu le rapport hebdomadaire détaillé dans lequel chacun liste le status de ce qu'il a accompli.
51% - 75%
C'est le niveau typique de DCF dans les entreprises informatiques de maintenant. Vos produits logiciels sont souvent en danger à cause du contexte Dilbertien dans lesquels ils sont faits. Vous avez une jolie belle dose de défauts routiniers de gestion, d'inutiles et interminables reunions sans résultat, d'incompréhensions à tout les niveaux de la hiérarchie, et des promesses arbitraires faites aux clients qui font tomber les ingénieurs en catalepsie.
76% - 100%
Le meilleur conseil pour ce genre d'organisation: tirez vous vite hors de l'industrie du logiciel. Embauchez le meilleur dessinateur que vous trouverez, faite-le rejoindre votre équipe pour qu'il documente ce qu'il y rencontre dans ses dessins. Fédérez-le et vous ferez une fortune.

Matt a déposé un brevet sur ce système unique, le DCF. Il espère devenir un consultant très cher, visiter un tas d'entreprises, faire son enquête, prendre l'argent et s'en aller avant que les gestionnaires comprennent qu'ils se sont fait arnaqués et qu'il ne leur reste plus qu'à trouver un autre très onéreux consultant pour remettre les choses d'aplomb. Matt nous a aussi dit "Je pense aussi à une version autonome pour le futur, Les dessins de Dilbert sur de petites cartes qui pouront &ecric;tre passées aux techniciens pour l'enquete. Je l'appellerais probablement Deal-a-Dilbert." Et de rajouter "Je pense aussi à un système simple de mesure de la personnalité qui permettra aux employés de trouver leur type de personnalité et sa place appropriée dans l'organisation. Ce sera le Dilbert/Dogbert Empathy Factor'."

C'est lors d'une de mes visites dans le grand Usenet que je suis tombé sur ce lien, dont le contenu m'a largement interpellé au niveau du vécu. J'ai donc décidé d'en faire la traduction. Honte sur moi, je ne pensais pas que c'était aussi difficile, et j'ai peur d'avoir parfois cassé le sens des choses.