Note : Je n’ai absolument pas participé à la construction de ce questionnaire. 

C’est terrible d’avoir toujours 10 ans d’avance !

Au début des années 90,  j’ai du me battre contre la modélisation lourde et la conduite de projet  « cascade » dont la représentation en France s’appelait Merise. A l’époque la méthode RAD (1991) semblait anarchique car elle proposait un périmètre variable, un cycle itératif incrémental, l’adaptation permanente par la validation de l’utilisateur,  la présence recommandée d’un animateur-facilitateur, une War Room, une équipe relativement autonome (SWAT), l’affichage mural et quelques autres folies pour l’époque. Enfin, tout ce qui fait une bonne méthode Agile aujourd’hui.

Les merisiens me tombèrent dessus.

Les méthodes Agiles apparurent, soit en directe émanation du RAD comme DSDM (1995) ou FDD, ASD, soit en “pompant” la totalité de ses techniques sans le référencer comme Scrum (1996), soit en apportant un plus d’usage comme XP (1999).

Dix ans après RAD, en 2002, en réponse au Manifeste Agile, je proposais PUMA pour l’Unification des méthodes Agiles sur la base de leur complémentarité. On trouve toujours ce document  en anglais à partir du wiki de  Ward Cunningham (http://c2.com/cgi/wiki?PumaProposal) et en français sur le site d’ADELI (ftp://ftp2.adeli.org/adeli/lalettre/l48p19.pdf). Cette proposition “pour le plaisir”, que je savais commercialement impossible, se transforma en simple principe d’urbanisation, puis récemment en méthode publiée.  

Nous ne sommes pas encore 10 ans après, mais déjà les méthodes Agiles commencent à mettre en œuvre les principes de PUMA en regroupant informellement  leurs approches incomplètes sur la base du choix de la technique utile au contexte.

Et évidemment les scrumistes me tombent dessus.

A chaque décennie je me fait crucifier ! 
Ah décidemment, c’est terrible d’avoir toujours 10 ans d’avance!

Les XP Days 2009 ressemble  à la caverne d’Ali Baba

XP (eXtrem Programming), la plus sérieuses et techniques des méthodes Agile  semble avoir perdu la partie face à l’envahissement de Scrum dont les certifications de complaisance sont la cause des controverses actuelles aux USA sur l’Agilité et de la totalité des échecs de projets Agiles rapportés.

Après avoir été incomplet, controversé, le message Agile devient relativement illisible et hétérogène observé de l’extérieur.

En tous cas, cette évolution confirme la justesse de ma vision et son aboutissement concret dans PUMA Essentiel.

En effet, la fusion des pratiques, qui devient évidente, n’est rien d’autre que le principe basique de PUMA Essentiel sans malheureusement sa simplicité et son homogénéité.

L’avantage de PUMA, c’est l’urbanisation et la formalisation existante de cette évolution.

La couverture méthodologique de PUMA règle une grande partie des problèmes actuels mis en évidence.  De plus, les nouvelles techniques qu’il propose sont porteuses d’une capacité d’élargissement de l’Agilité aux grands projets et aux couches supérieures de l’organisation.

____________________________________________________________________________
Petit rappel d’anciens messages techniques ayant disparu de la première page :

Comparatif Scrum, XP, PUMA  http://agiles.blog.com/2952126/
Le Mythe du périmètre variable  http://agiles.blog.com/2501821/
Le mythe de l’itératif sans concession  http://agiles.blog.com/2854726/

Le moteur de Solution, par exemple, n’est pas une phase mais un modèle itératif de structuration des exigences. Il est mis en œuvre (si nécessaire) dans le cadre du moteur de Communication, lequel n’est pas non plus une phase mais lui aussi un modèle itératif de facilitation de la communication en environnement sensible.

Le moteur de Pilotage spécialisé dans la conduite itérative incrémentale du projet est le seul élément pouvant être apparenté à une phase. Imbriqué dans cette phase, un moteur de Réalisation pouvant, dans le cas d’un développement spécifique, être basée sur XP ou sur une structure moins extrême, n’est en fait qu’une simple boite à outils composée des meilleures techniques actuelles de développement.

Entre les statistiques publiées, une solide base de projets ayant permis de calibrer Evaluateur en son temps http://www.rad.fr/eval2000.htm (à Hydro Québec j’ai supervisé jusqu’à plus de 60 projets simultanément) et mes expériences de consultant méthode de ces dernières années, j’en arrive à la conclusion qu’en termes de besoins :
- seuls 18% des applicatifs auraient été en mesure d’être définis précisément en début de projet;
- environ 22% des applicatifs étaient en mesure d’être abordés sans structuration des exigences en début de projet.

En clair, vouloir fixer un périmètre complet et détaillé  pendant une phase d’exploration est une erreur aussi sérieuse que de vouloir se passer de l’indispensable réflexion qui doit précéder l’action. Les échecs de projets itératifs liés à cette faute d’appréciation font courir le risque de voir cantonner les méthodes Agiles actuelles à des petits développements avec un nombre très limité d’utilisateurs.  Dans ce cas, il est d’ailleurs intéressant de se demander à quel moment, comment et sur quelles bases, se ferait l’arbitrage budgétaire conduisant à lancer le projet.