La méthode R.A.C.H.E : Rapid Application Conception and Heuristic Extreme-programming
Il existe une méthode de génie logiciel qui décrit mieux la vraie vie que la moitié des référentiels que je vois passer en comité. Cette méthode a un acronyme, un institut, une F.A.Q et une licence domaine public: elle s’appelle la méthode R.A.C.H.E. Je la découvre vers 2009-2010, à une époque où je prends encore les roadmaps au sérieux.
R.A.C.H.E signifie Rapid Application Conception and Heuristic Extreme-programming. Le site de l’International Institute de La RACHE existe depuis 2007, mais le concept circulait déjà sous forme de PDF auparavant. La métempsychose récurrente du concept semble, selon ses propres promoteurs, intrinsèquement axiomale chez certains grands éditeurs. la-rache.com
L’I.I.LaR
L’International Institute de La RACHE ou I.I.LaR, a pour mission de promouvoir la méthode, dont la définition est d’une précision remarquable:
La RACHE, solution globale de génie logiciel, est un ensemble de techniques, de méthodes et de bonnes pratiques décrivant - des spécifications à la maintenance - comment produire du logiciel dans des conditions à peu près satisfaisantes et approximativement optimales.
Ce niveau de rigueur est exactement celui de la plupart des plans projets que j’ai pu lire. Le corpus est paraît-il certifié ISO-1664.
Rapid Application Conception
Le cadrage tient sur un post-it: résumez le besoin en huit mots maximum. La durée du projet se calcule ensuite en multipliant le nombre de mots par un coefficient compris entre vingt et deux cents jours-homme. On ne planifie rien de plus (le post-it perd de son adhérence au fil des semaines, ce qui est un rappel physique de l’état réel du projet).
L’extrême programming heuristique
L’heuristique, rappelle la méthode, est l’art de faire faire par d’autres ce qu’on ne sait pas faire soi-même; appliquée au génie logiciel, cela donne l’extrême programming heuristique, où l’on commence à écrire le code le plus tard possible, parce que tout ce qui est écrit trop tôt est à réécrire. Je ne connais pas de méthode agile qui dise mieux les choses en aussi peu de mots.
Le lexique
Le lexique est le morceau de bravoure. On y trouve le R.A.T.P, Régulateur Asynchrone Temporel Pifométrique, qui remplace avantageusement l’estimation classique en jours-homme, ainsi que l’U.R.M.L, Unified Random Modeling Language, variante stochastique d’UML dont les diagrammes changent à chaque lecture. Le R.A.T.P a l’avantage d’être honnête: il annonce qu’il ne sait pas, là où le planning classique fait semblant.
[edit: 2014] Le lexique s’enrichit depuis d’une entrée D.O.C.K.E.R, Deployment Of Containers with Known Errors and Restarts, empiler des conteneurs sans trop savoir ce qu’il y a dedans et redémarrer quand ça tombe.
La F.A.Q
La F.A.Q apporte les précisions que les roadmaps oublient: un système développé à La RACHE est en état de fonctionnement quand il n’a pas encore planté. Il est alors urgent de ne plus y toucher. Quant à la question de savoir qui est responsable en cas d’incident, la réponse est la suivante: personne, la méthode produit du logiciel dans des conditions à peu près satisfaisantes, pas des coupables.
C’est le passage que je cite le plus en revue d’architecture.
Pourquoi la satire dit vrai
Une blague qui tient depuis quelques années finit toujours par dire vrai. Chaque principe de La RACHE est le négatif net d’une bonne pratique: la configuration sortie du code répond au fameux “ça marche chez moi”, la disposabilité répond au système qu’on n’ose plus redémarrer. La panne qu’on répète exprès répond à l’incident qu’on découvre en pleine nuit, quand personne n’est là pour le regarder venir.
La différence tient au contrat: la RACHE annonce d’emblée que tout va approximativement bien se passer, là où les bonnes pratiques écrivent noir sur blanc ce qu’elles garantissent et ce qu’elles ne garantissent pas.
Je relis le site une fois par an. Il tient toujours.