"Responding to change over following a plan" : une idée neuve ?
15 nov. 2008 Olivier Azeau En français 5
Les adeptes de méthodes agiles utilisateurs de la version française de wikipédia auront peut être remarqué un assez curieux historique sur les entrées concernant les méthodes agiles et Scrum en particulier : la méthode "RAD" de James Martin serait à l'origine des méthodes agiles !
Claude Aubry explique comment cette information a induit en erreur un très sérieux journal d'informatique.
J'ai pris l'initiative de supprimer la plupart des références abusives sur la fiche de Scrum. L'auteur de ces références n'a visiblement pas aimé la manoeuvre.
Sur ma page personnelle wikipédia, il tente d'affirmer, une énième fois, que l'antériorité de la publication de J.Martin (1991) sur la notion de méthode "itérative, incrémental et adaptative" induit la filiation entre RAD et Scrum, pour ne pas dire avec l'ensemble des méthodes agiles.
RAD peut éventuellement être qualifié de méthode agile (je ne suis pas compétent pour confirmer ou infirmer une telle affirmation) mais de là à en faire la source d'inspiration des autres méthodes, il y a un fossé à franchir.
Le plus drôle, c'est que ce lien de parenté est limité au monde francophone : si on va sur le wikipédia anglophone, on ne trouve aucune trace d'une telle filiation !
Alors, Schwaber et Sutherland ont-ils pompé sur Martin sans le citer ? La réponse n'a que peu d'importance. Tous ces travaux datent de la même période et leurs influences sont forcément multiples.
La vérité, c'est que cette idée de prise en compte active du changement dans un projet logiciel est loin d'être neuve. Voici un texte dont je laisse aux lecteurs le soin de découvrir le nom de l'auteur et la date de publication. Après, on pourra reparler de la paternité des processus incrémentaux et adaptatifs...
La première étape est d'accepter le changement en tant que phénomène normal et habituel, au lieu de le voir comme un désagrément facheux et exceptionnel. [...] ce que le programmeur livre à un client est la satisfaction d'un besoin plutôt qu'un produit concret. Et ce besoin, ainsi que la façon dont il est perçu par l'utilisateur, changeront pendant que les programmes seront construits, testés et utilisés. [...] certains changements d'objectifs demandés par le client sont inévitables, et mieux vaut s'y préparer que de supposer qu'il ne s'en produira aucun.
Ce qui détermine le changement de paradigme en conduite de projet c'est le passage du "cascade" à l'itératif,incrémental et adaptatif. La première méthode basée sur cette rupture est la méthode RAD de James Martin publiée en 1991. Ensuite DSDM pour le coté anglophone, à pris la relève de cette évolution en termes de techniques. De 1991 à 1996 (pour Scrum) et à 1999 (pour XP), les chefs de projets du monde entier ont utilisé RAD (5 livres en 1996 rien qu'en France). Obligatoirement les contributeurs à l'évolution des méthodes ont eu connaissance de ces travaux. Ce n'est pas la méconnaissance des recherche de Pierre et Marie Curie qui doit me donner le droit de revendiquer la découverte de la radioactivité.
Il n'y a aucune rupture méthodologique dans XP ou Scrum , juste une amélioration de l'usage des techniques de qualité et de conduite de projet adaptative.
Dernier point : tous ces travaux ne datent PAS DU TOUT de la même époque.
- James Martin publication méthode RAD complète en 1991 (officiellement , mais j'avais lu ses premières communications au Canada vers 1989 / 1991)
- SCrum ébauche en 1995 publication 1996.
- XP publication 1999.
En informatique 4 ou 8 ans c'est une éternité de projets.
Je serais vraiment curieux de savoir qui avait vraiment entendu parler de Scrum ou de XP en France avant 2000 et avant que Monsieur Jean-louis Bénard n'en fasse une étude comparative.
Je peux aussi rajouter qu'en 2001 lorsque j'ai publié lapremière version de PUMA, basée sur l'étude comparative de ces méthodes (points communs et divergences) je n'avait strictement rien trouvé de novateur pour Scrum sauf les réunions quotidiennes.
ftp://ftp2.adeli.org/adeli/lalettre...
Ce n'est que récemment, devant la montée commerciale de cette approche (une certification donnée en 2 jours ca aide)que je me suis repencher sur la question pour trouver quelque chose. Finalement j'ai opté pour la formalisation et la systématisation des rétrospectives.
Et puis (jamais 2 sans 3) pour conclure.
L'important, à part pour l'éthique et le coté historique, c'est pas l'antériorité de la rupture par RAD.
L'important c'est le futur et l'urbanisation des méthodes Agiles trop incomplètes pour appréhender les grands problèmes de SI Agile (BPM, SOA) et, au delà, d'entreprise globalement Agile.
Le futur c'est PUMA et encore une fois je pense avoir quelques longeurs d'avance malgré ma pauvre condition de francophone du mauvais côté de l'atlantique.
Alors les Agiles, vous allez quand même pas arrêter d'évoluer par sectarisme ?
Comme tout ca n'a pas l'air de passionner les foules ici. Je viens de poster un lien à partir de www.Entreprise-Agile.com vers votre blog.
Pour le futur des méthodes agiles, je ne sais pas ce qu'il en sera. Mais je fais plus confiance à la capacité d'adaptation qu'à quelques prévisions qui ont une forte probabilité d'être erronées ! (agile jusqu'au bout...)
Pour ce qui est du passé et de la notion d'époque, le texte que je cite a été publié en 1975. Je n'avais alors que 4 ans. Je ne peux donc qu'imaginer ce que faisaient les "chefs de projets du monde entier" à ce moment là et dans les 10 ou 15 ans qui ont suivi : probablement de la cascade, du V et autres choses sympathiques du même acabit.
Ce n'est pas parce qu'une idée est émise qu'elle bouleverse immédiatement une profession et ses pratiques. Je suis d'ailleurs prêt à parier que Martin, Sutherland, Schwaber et tous les autres ont lu ce texte publié plus d'une dizaine d'années avant leurs propres ouvrages.
Lors de l'étape toulousaine de l'agile tour, j'ai introduit les méthodes agiles avec un bref historique. C'est sans hésitation que j'ai cité le livre dont est issu ce texte comme un des points de départ de l'ensemble des réflexions qui ont donné les méthodes agiles que l'on connait aujourd'hui.
"Back to basics" comme on dit de l'autre côté de l'atlantique.