La Rache : la méthode la plus utilisée au monde
Un peu d'histoire sur La Rache et de mise en contexte
Pour comprendre ce qu’est la Rache, il faut remettre un peu de contexte.
Toute le monde connait les méthodes de Gestion de Projet classiques, dites « en cascade ».
C’est simple : on spécifie tout, on réalise ce qui est spécifié, et au final on teste.
Il y a aussi leur pendant du « Cycle en V », mise en lumière par MERISE, qui n’est pas très différent, sauf qu’on éclate les niveaux (Spécification Fonctionnelles Générales, Spécification Techniques Générales, Spécification Fonctionnelles Détaillées, Spécification Techniques Détaillées, Réalisation) et qu’on va ensuite remonter le cycle avec un niveau de tests à chaque niveau de spécification.
Dans les 2 cas, on a un « effet tunnel’, entre la fin des spécifications générales et le début de la recette utilisateur, le client final ne voit rien. Si la conception est erronée, on s’en rend compte trop tard.
C’est pour cela que sont nées les méthodes agiles.
Alors, elles ne sont pas toutes récentes. Contrairement à la croyance générales, l’agilité n’est pas née dans les années 2000 avec le manifest Agile. Dans les années 1980 (et probablement un peu avant) on parlait déjà xTrem Programming, qui contenait déjà les bases de l’agilité.
Pourtant, de nombreux gestionnaires continuent à privilégier une méthode moins documentée et moins décriée : La Rache.
Nous allons en parler ici.
La Rache : la méthode des méthodes méthodiques
Définition : (extrait du site officiel)
La Rache s’appuie sur deux concepts aussi important l’un que l’autre.
D’une part la « Rapid Application Conception » correspond conceptuellement à une accélération importante dans la phase de conception de l’application par rapport aux méthodes classiques. Pour bien débuter avec La RACHE il faut soigner la phase d’étude et la rédaction du cahier des charges. Il faut ici produire un travail de synthèse important en résumant le cahier de charges en un post-it de 8 mots maximum. Puis la mission est d’extrapoler de ce post-it un sujet de développement vaseux, mais pas trop. À partir de là, en règle générale, la multiplication du nombre de mots sur le post-it par un chiffre tiré au sort entre 20 et 200 donne la durée du projet en jours/homme. On prendra soin de ne rien planifier dans cette phase.
D’autre part « L’extrême programming heuristique » est un concept assez prometteur. En effet l’heuristique est une technique consistant à apprendre petit à petit, en tenant compte de ce que l’on a fait précédemment pour tendre vers la solution d’un problème. Opposé à l’algorithmique, l’heuristique ne garantit pas du tout qu’on arrive à une solution quelconque en un temps fini. Ceci sous-entend d’une part une démarche pédagogique globale d’apprentissage et de capitalisation des acquis, mais aussi que les échéances annoncées le sont dans une pure optique de déconnade symbolique. Et c’est précisément le plus « produit » de la méthode RACHE.
Un des exemples typique est l’empilement de containers Dockers anarchiques, non documentés, et redémarrés jusqu’à ce que ça tombe en marche (une notion majeure de La Rache).
Les notions essentielles de La Rache :
- Le format de spécification = le post-it (à défaut, un ticket de métro ou un bout de nappe en papier peut faire l’affaire)
- Méthode de mesure de la durée = [Nombre de mots sur le post-it] x [Un nombre aléatoire entre 20 et 200]
- L’unité de mesure de la charge de travail communiquée au client = le pipotron
- Système de mesure général = le système pifométrique
- La fin du processus = c’est quand ça tombe en marche,
et à partir de là il est important d’appliquer l’adage majeur de La Rache : « si ça marche n’y touche pas » - Certification = Le Rache est conforme à l’ISO-1664
- RGPD = La Rache est totalement conforme à la RGPD. En ce sens elle encourage à ne produire aucun document et si possible ne stocker aucune données.
- Synonyme | Eponyme | Pote à Nymes : La Méthodes à Gilles regroupe un ensemble de spécialisations avancées de La Rache.
Mise en garde
- Sans que ce soit formellement interdit par la méthode, il est fortement déconseillé d’écrire quelque forme de documentation que ce soit. La documentation c’est pour les faibles. Cela fait perdre inutilement du temps et pourrait permettre à une personne mal intentionnée de comprendre pourquoi le projet s’est planté et trouver un responsable. La non documentation permet de garantir la confidentialité des données personnelles de tous les membres de l’équipe et de ceux qui ont pu tremper de près ou de loin dans l’affaire.
- La Rache n’est en théorie pas compatible avec ITIL et SCRUM. Mais en y mettant un peu du sien, on y arrive quand même. C’est un des avantages de La Rache : en n’appliquant pas plus de 10% des processus qu’on a compris de travers dans une méthode, on redevient 100% conforme à La Rache. D’ailleurs, on constate qu’un grande partie des projets dits « Agiles » sont en fait exécutés conformément à La Rache, de la plus rigoureuse des manières.
- Bien entendu, toute sauvegarde est proscrite par La Rache, sous quelque forme que ce soit.
- Attention, bien que souvent utilisée par les adeptes de La Rache, la chiée (souvent utilisée sous le terme une chiée + 15) n’est pas une unité pifométrique et ne devrait donc par être utilisée formellement dans le cadre de La Rache. En effet, La Chiée a une valeur bien déterminée et est égale à 11. Pour preuve, on dit généralement « 11 fait Chiée ».
Quel avenir pour La Rache ?
La Rache n’est pas prête d’être détrônée. Elle est l’une des méthodes les plus utilisées de part le monde et son utilisation est croissante. La popularité des méthodes Agiles (comme Scrum) appliquées par des personnes qui n’ont pas lu une ligne sur le sujet permet à La Rache d’être déployée sans même que ses utilisateurs n’en soient pleinement conscient.
LONGUE VIE A LA RACHE
Pour en savoir plus
Pour plus d’informations sur cette méthode injustement méconnue mais tellement appliquée, consultez le site officiel de La Rache.
Surveillez notre blog sur la gestion de projet et notre page linkedIn. Vous y retrouverez des articles pragmatiques et des partages d’expériences sur la gestion de projet et l’open source.
Note de l’auteur
Je suis Pascal BERNARD, le Président de la société PROJEQTOR. J’ai passé 24 ans en société de services, où j’ai été Chef de Projet pendant 10 ans et Architecte de Systèmes d’Information pendant 8 ans.
J’ai conçu le logiciel ProjeQtOr à partir de 2009 et je m’y consacre à temps plein depuis 2015.
Je partage sur ce blog quelques idées issues de mon expérience personnelle.
Retrouver mon histoire et celle de ProjeQtOr sur la page « A propos », ou sur mon profil linkedIn.