Crise et renouveau des méthodes. Acte II : la découverte du peopleware

Suite de l'Acte I : l'échec du modèle Mac Donald's

Pourquoi les méthodes classiques ont-elles apporté si peu ? Explication possible : on a été trop ambitieux. Comme toujours dans les approches théoriques qui plaisent en informatique, on a voulu faire un grand bond en avant alors qu'un progrès plus réduit mais bien concret aurait été le bienvenu. Deux exemples pour illustrer le fait qu'on a sans doute visé la mauvaise cible : la génération de code et la prévention des bugs. La mode des outils CASE était l'expression d'un fol espoir : faisons écrire le code des applications par des méta-compilateurs qui se baseraient sur nos schémas conceptuels plutôt que par les développeurs qui sont lents et qui font une erreur par ligne !

Parlez-en sur le Forum (rubrique Solutions e-business)

Une quête du Graal inutile
Evidemment, cela n'a rien donné d'utilisable. Il a d'abord fallu affiner le contenu des documents conceptuels afin de disposer d'une base utilisable. Ensuite, il a fallu améliorer les générateurs afin qu'ils puissent produire un code qui aille au-delà des en-têtes de sous-programmes. Enfin, il a bien fallu admettre que ni l'un ni l'autre de ces objectifs n'était atteignable… Améliorer sans fin le contenu des documents conceptuels consommait plus de temps que les projets résultants ne le méritaient. Par ailleurs, on passait beaucoup de temps à sophistiquer les générateurs de code pour une technologie qu'aussitôt une autre apparaissait et annulait le bénéfice. Cette quête du Graal s'est poursuivie quelques années avant d'être abandonnée alors qu'elle n'aurait jamais dû être entreprise. En effet, ce qu'il nous fallait, ce n'était pas des générateurs automatiques de toute l'application à partir des modèles de conception mais plutôt des générateurs semi-automatiques pour certaines parties délicates du projet (interface utilisateur, accès à la base de données, gestion des transactions, etc.).

Incompréhension du problème de base
Dans le cas de la prévention des bugs, l'incompréhension du problème de base est encore plus accentuée. On a d'abord tenté de définir des langages qui rendaient impossibles les erreurs d'écritures en se bloquant lors de la compilation, genre Ada. Grand progrès ! Comme cela, au lieu de passer du temps à debugger le fonctionnement de l'application, on passait un temps fou à debugger la compilation du programme et on ne savait pas si l'ensemble de l'application fonctionnait de façon cohérente (oui mais sur le plan académique, elle était parfaite, on pouvait être content !). Ensuite, on a truffé les modèles de conceptions de règles qui, normalement, effectuaient un contrôle de l'erreur (mais tellement difficile à comprendre et à appliquer que tout le monde les contournait…). Enfin, on a définit tout un tas de recommandations inapplicables mais qui faisaient bien dans le tableau, satisfaisaient les gourous et rassuraient le client. En vérité les bugs sont inévitables, c'est comme de vouloir écrire sans faute d'orthographe ou sans faute de frappe. C'est dans la nature même de l'écriture, le premier jet n'est jamais le bon et corriger est plus facile que créer !

Démarche corrective versus démarche préventive
Donc, il faut reconnaître cet état de fait et se pencher sur des démarches adaptées comme de mettre en place un système qui va identifier, traquer et permettre la correction des bugs (ce sujet de la détection, de l'enregistrement/ archivage et de la correction des bugs sera traité plus loin dans cet essai). Oui mais, sur le plan doctrinaire, reconnaître qu'il valait mieux s'appliquer à améliorer les démarches correctives plutôt que de mettre au point des démarches préventives n'était pas " politiquement correct " et cet entêtement a débouché sur toutes ces impasses.

Un exemple réussit d'approche concrète
Pour en finir avec ce trop plein d'ambition et cette tendance à vouloir toujours viser le système parfait (deux tendances qui ont fait tant de mal à l'informatique), remarquons un fait intéressant : que retrouve-t-on souvent dans les projets qui, à l'origine, ne promettaient pas la lune ? Une conception très modulaire. On sort quelque chose sans prétention au début, et on améliore par la suite en rajoutant des modules, plutôt que d'essayer de tout prévoir dés le début. C'est par exemple le cas de Linux. Sorti au début sans interface X-Window, et avec sans doute des outils et drivers très limités, Linux s'est petit à petit amélioré. Des personnes ont porté les commandes Unix, d'autres ont créé des drivers, d'autres ont porté X11. Linux étant très modulaire, Torsvald n'a eu qu'à superviser le noyau. Ce qui compte vraiment : le peopleware!

Finalement, il aura fallu ces années d'égarement pour que l'on admette enfin la vérité toute simple : dans un projet, ce qui compte le plus, c'est l'entente entre les membres et les conditions de travail. Voici un exemple qui illustre bien cette loi d'Airain : pendant des années, Fred Brooks fit faire et refaire le même projet à ses étudiants de l'Université de Caroline du Nord. Certaines conditions du projet restaient constantes telles que les délais, les livrables et la taille de l'équipe qui y était affectée alors qu'il faisait varier les méthodes et techniques utilisées semestre après semestre.

Les facteurs humains dominent
Les conclusions de cette expérience menée pendant une dizaine d'années sont que les paramètres sur lesquels on se focalise habituellement (méthodes et techniques) semblent ne pas avoir autant d'importance qu'on le suppose. En revanche, des facteurs comme l'harmonie au sein de l'équipe et une répartition intelligente des rôles ont eu une influence déterminante sur le résultat des projets presque identiques supervisés par Fred Brooks. Point n'est besoin d'une observation aussi systématique pour comprendre l'importance du facteur humain dans la réussite d'un projet. Il suffit de penser à votre réaction si votre patron pose un cahier des charges sur votre bureau en vous demandant " combien vous faut-il pour faire ça avec l'aide d'une autre personne ? ". La première question que vous allez poser ne sera pas d'ordre technique (comme " quel environnement système ? " ou " est-ce que je peux utiliser l'outil de mon choix ? ") mais plutôt " qui sera l'autre personne ? "… En réaction à l'échec des méthodes traditionnelles-monumentales, un nouvel ensemble de démarches sont apparues ces dernières années. Pour un temps, on les appelait les méthodes légères mais maintenant le terme le plus largement accepté est " agiles ", les méthodologies agiles. Que nous découvrerons dès demain soir.

"Crise et renouveau des méthodes, dernier acte:
les principes de l'eXtreme Programming"