|
05/03/2001
Crise
et renouveau des méthodes. Acte I : l'échec
du modèle Mac Donald's
Tout
au long de ma carrière (plus de vingt ans de métier,
ça commence à compter !) j'ai pu constater et analyser
de nombreuses situations sur le terrain. De même, j'ai
observé l'évolution de notre secteur vis-à-vis de l'approche
méthodologique tout au long de ces vingt dernières années
au gré de ses modes et de ses tournants. J'ai même été
un auditeur assidu des " journées internationales du
Génie Logiciel " (Génie Logiciel, on appelait ainsi
les tentatives visant à améliorer la production du logiciel,
même cette appellation est tombée en désuétude
) qui
se tenaient à Toulouse à la fin des années 80. Aujourd'hui,
il est clair que les méthodes traditionnelles sont en
crise et c'est normal. Comment les méthodes sont apparues,
pourquoi elles sont passées du succès au désaveu en
quelques années et que reste-t-il de tout cela, c'est
ce que nous allons voir ensemble maintenant
La
démarche de développement chaotique
L'apparition
des méthodologies de développement et de suivi de projet
peut être vue comme une réaction à la démarche "chaotique"
qui prévalait dans les premiers temps de l'informatique.
La plupart des activités de développement logiciel suivaient
un cours chaotique souvent caractérisé par la phrase
"coder et corriger". Le logiciel était écrit sans vraiment
de plan d'ensemble et la conception des systèmes était
le fruit de nombreuses décisions basées sur le court
terme (tout cela est encore vrai dans bien des cas
).
Ce type de pratique peut convenir pour des petits programmes
mais si on veut mettre en place des applications plus
importantes, il devient de plus en plus difficile d'ajouter
des fonctions aux systèmes au fur et à mesure de sa
" construction ". De plus en plus de défauts deviennent
proéminents et il devient de plus en plus difficile
de les corriger.
Un longue période de tests après que le logiciel soit
considéré comme terminé sur le plan fonctionnel est
un signe typique de ce type de démarche. Une longue
période de test vient remettre en cause le calendrier
du projet puisque la durée des tests et du debug sont
presque impossibles à évaluer.
L'alternative
au chaos : les méthodes
Nous
avons vécu avec ce style de développement pendant longtemps
mais il existe aussi une alternative depuis longtemps
: les méthodologies de développement et de suivi de
projet. Les méthodologies imposent une discipline sur
les processus de développement logiciel avec pour but
de rendre le développement plus prévisible et plus efficace.
Ce but est théoriquement atteint en suivant un enchaînement
rigoureux de tâches et en respectant à la lettre un
planning détaillé. Ces méthodologies informatiques sont
inspirées ou même dérivées des pratiques connues dans
d'autres disciplines faisant appel à l'ingénierie.
La critique
la plus fréquente qui est faite à l'encontre de ces
démarches c'est qu'elles sont bureaucratiques. Il y
a tant à faire pour simplement suivre la démarche que
le rythme des projets s'en trouve ralenti. Du coup,
on les appelle souvent les méthodologies lourdes voire
"monumentales"
Les méthodes monumentales sont basées
sur un gros classeur où tout est décrit et où tout doit
être consigné. Ces méthodologies sont connues et utilisées
depuis le tout début des années 80. Le moins que l'on
puisse dire, c'est qu'elles n'ont pas donné de résultats
spectaculaires et, conséquence logique, elles deviennent
de moins en moins populaires. Ces approches sont surtout
conçues pour que les intervenants de base sachent au
moins où il faut poser les pieds pour avancer et ainsi
donnent l'illusion de savoir ce qu'ils font
L'approche
classique : le modèle Mac Donald's
L'approche
classique : le modèle Mac Donald's
Le désaveu qui a frappé les méthodes traditionnelles
s'explique facilement : ces démarches strictes sont
sans doute adaptées aux domaines de la fabrication en
série mais pas pour le développement logiciel qui est
très éloigné du systématisme qui y a cours. Prenons
l'exemple de Mac Donald's et de ses Big Macs et vous
allez me comprendre
Qu'on le veuille ou non, qu'on y croit ou pas, Mac Donald's
ne doit pas son succès au seul marketing mais bien à
son approche de la qualité dans la gestion de ses processus
de fabrication. Oui, j'ai bien écrit qualité mais ici
ce terme doit se comprendre dans le sens de " constance
de résultat " et non comme " goût délicieux ". Un manuel
épais pour les cerveaux plats Pour garantir la constance
du résultat, Mac Donald's remet un épais manuel à chaque
franchisé où tout est consigné, depuis le temps de cuisson
jusqu'aux gestes à faire (et l'ordre de ces gestes,
la position des opérateurs, leur tenue vestimentaire,
les moyens mnémotechniques de contrôle de l'erreur,
etc., etc.) pour obtenir le fameux Big Mac. Cette assistance
hyper-rigide et hyper-codifiée a été conçue, par des
gens raisonnablement intelligents, pour que d'autres
gens, même stupides, gardent une bonne chance d'aboutir
avec succès dans la réalisation systématique du même
produit n'importe où dans le monde et que ce résultat
ait le même goût partout et tout le temps. Hamburgers,
logiciels, même recette ? Et ça marche. En tout cas,
ça marche pour les hamburgers dans des boîtes en plastique.
 |
|
|
Beaucoup
de méthodes, peu de progrès...
Pour ce
qui est de la réalisation de logiciels, c'est déjà plus
discutable. Ceci dit, cette approche permet de donner
l'illusion au client (celui qui paye pour qu'on lui
développe ses applications et ses sites, pas celui qui
est d'accord pour manger des Big Macs après avoir fait
la queue dans un univers en plastique aux couleurs criardes)
que son prestataire se préoccupe de la qualité des prestations
puisque ses représentants (de jeunes diplômés faiblement
compétents en matière de développement mais maîtrisant
bien la langue de bois obligatoire préconisée par la
" Méthodologie maison "
) produisent des tonnes de papiers,
documents d'analyse, rapports d'avancement, graphes
de conception, etc. Le problème avec cette débauche
d'énergie et de documents, c'est qu'on ne parle pas
d'applications ou de logiciels mais seulement de respecter
la démarche
Chez Mac Donald's au moins, les hamburgers sont cuits
et livrés ! Bref, l'approche Mac Do, c'est un peu "méthodologie
pour les nuls" et ce n'est pas vraiment que l'on cherche,
n'est-ce pas ?
Pendant
des années, le domaine des méthodes informatiques a
été agité par une activité soutenue : les modes s'y
succédaient, les gourous pullulaient et les débats faisaient
rage. Les clients y croyaient et n'hésitaient pas à
dépenser des sommes importantes en outils et en séminaires.
Au temps des premiers pas du génie logiciel, l'idée
était simple et élégante : créons des logiciels qui
nous aident à écrire des logiciels. Mais, rapidement,
les choses sont devenus incontrolables : les outils
sont devenus trop lourds et trop contraignants pour
apporter une aide réelle dans les projets de développements.
Ces outils qui ont été créés à l'origine pour nous aider
à suivre les règles sont devenus trop difficiles à utiliser
par eux-mêmes. Les développeurs d'applications trouvèrent
nécessaires de pratiquer des raccourcis et même " d'oublier
" des pratiques importantes simplement pour respecter
les délais des projets où ils étaient engagés.
La
nostalgie de l'âge d'Or des méthodes
On ne
peut pas se souvenir sans une certaine nostalgie de
ces vagues successives : d'abord l'approche conceptuelle
(avec Merise côté français mais les autres ont aussi
eu droit à la dictature des méthodes basées sur le couple
" entités-relations "), la mode du CASE l'acronyme CASE
était censé signifier Computer Aided Software Engenering)
ou l'espoir mis dans le développement articulé autour
d'un " référentiel " (ah, AD Cycle et le Repository,
qu'êtes-vous donc devenus ?). Aujourd'hui, toute l'effervescence
autour des méthodes et des outils accompagnant ces méthodes
est bien retombée faute de bénéfice. Un bilan désastreux
Sous bien des aspects, le bilan des développements associés
à ces pratiques est terrible. Ces mauvais résultats
découlent, entres autres, d'une approche planificatrice
(démarche inspirée par la doctrine des méthodes classiques)
symbolisée par la mode du " schéma directeur " qui sévissait
au début des années 80.
Les directions informatiques payaient alors très cher
quelques consultants issus de cabinets réputés afin
de rédiger un " plan d'orientation général des développements
" (une définition approximative de la notion de " schéma
directeur "). Souvent, ce plan d'ensemble était composé
de deux parties : un volet fonctionnelle (analyse des
besoins et des demandes afin de déterminer les applications
qu'il fallait développer) et un volet technique (définition
d'une architecture informatique et réseau capable de
supporter les applications envisagées et choix des outils
pour les développer). Il fallait des mois pour établir
ce plan qui, à peine publié, était déjà dépassé par
l'évolution de la technique et par l'évolution des demandes
des utilisateurs. Lorsqu'enfin on tenait le précieux
document, on pouvait passer à l'examen des demandes
et à la mise en uvre des projets. Et là, une fois encore,
on repartait pour un nouvel " effet tunnel " : rien
ne voit le jour pendant un certain temps et quand l'équipe
émerge avec son application, le contexte a encore changé
!
Bref, cette approche planificatrice à outrance n'a rien
donné de bon et a contribué au désaveu général qui a
frappé les méthodes classiques. Questions légitimes
· Comment se fait-il que l'apport des méthodes soit
aussi maigre ? Comment est-il possible que des années
d'efforts, des armées de consultants et d'experts n'aient
donné aucun résultat ou presque ? · Pourquoi les évolutions
successives des différentes approches ont-elles produit
des progrès aussi minces (voire pas de progrès du tout)
?
Réponses dans notre édition de demain :
"Crise
et renouveau des méthodes, acte II :
la découverte du peopleware"
|
