L’Usine à Gaz, le tout dynamique qui ne marchait pas.

Cette semaine, je vous propose le rêve du psycho-geek, la Mecque du dynamique outrancier, le temple du Shadock : l’Usine à Gaz.

Dans toute conception de système informatique, il y a la volonté de schématiser la chose à concevoir, de couvrir tous les cas possibles et de tous les schématiser pour concevoir l’omni-système.

Ca part généralement d’un bon sentiment, ou d’un sentiment du devoir, de l’amour du travail bien fait.

Évidemment la réalisation sans une dose de bon sens devient vite un désastre. Comment identifier l’Usine à Gaz, quel est le danger, comment l’éviter. Certains diront que c’est du bon sens. Vraiment ?

La genèse de l’Usine à Gaz

Entre le développeur informatique et le client tout s’oppose. Et c’est bien là qu’est l’origine de l’Usine à gaz : un manque de communication, d’information, d’explication voir d’écoute entre les parties. Et c’est pour cette raison que le chef de projet est censé se positionner entre ces deux protagonistes qui ne peuvent pas se comprendre pour trouver le bon compromis.

Cependant, le chef de projet lui-même peut se faire engluer, soit par un client sourd et borné (je veux telle chose, sous telle forme, je n’y comprend rien mais c’est facile parce que je paye), soit par un développeur muet et procédurier (…), soit parce que lui-même ne saisis pas l’ampleur des dégâts potentiels ou parce qu’il perd son indépendance face aux deux antagonistes (Le client est roi, c’est le boss qui a dit, je fais entière confiance à bidule, c’est une star…).

Comment détecter l’apparition d’une usine à gaz ?

- Le schéma fonctionnel est illisible, il ne tient pas sur une page, il y a autant de tables ou de processus que de fonctionnalités, le développeur s’arrête pour se remémorer à quoi sert une partie,
- Le budget développement explose, de 30 jours on passe à 150 jours au bout de la 3ème réunion,
- Le détail est devenu plus important que la finalité dans les discussions, on entend des phrases du style “oui mais que fait-on si le client est portugais, passe une commande en dollars et se fait livrer à Monaco”,
- Des gens s’évanouissent en réunion technique.

Les danger d’une usine à gaz.

- Budget explosé, on l’a déjà dit mais c’est un des leviers principaux pour la suite donc on va le redire,
- Système impossible à maintenir, voir à faire fonctionner convenablement (temps de réponse du système, mises à jour, développements futurs),
- Donc dépression du chef de projet, projet raté, projet abandonné, projet à refaire.

Pareto, KISS, le développement itératif, et la coupe franche

> Pareto
C’est la règle d’or, à inscrire en lettre d’or et à encadrer au dessus de la table de réunion : 20% des efforts couvrent 80% des cas. Pour couvrir les 20% restants on va déployer 80% des efforts.

Alors oui, il existe des cas et des business ou il faut aller les chercher, mais tout le monde ne travaille pas dans le nucléaire où on ne peux à priori pas se permettre n’importe quoi (…cui cui cui cui…).

Entre 20 et 100, on multiplie par 5 les efforts, donc le budget et les délais. C’est la partie la plus importante à transmettre au client : quels sont les 20% qui vont multiplier par 5 le budget et les délais. Ça parle tout de suite, ça retient l’attention, c’est très vendeur, on se comprend et on décide très très vite.

> KISS
KISS, ce n’est pas qu’une bande de rockeurs psychopathes à la face barbouillé, c’est aussi l’acronyme de “Keep It Simple, Stupid”. Comment faire cette fonctionnalité le plus simplement possible, le plus léger possible, le plus facile pour tout le monde. Comment faire en sorte que quelqu’un puisse se dire “mais bien sur, c’est complètement idiot, pourquoi n’y ai-je pas pensé avant” en regardant votre solution. Plusieurs solutions sont opposables à un même problème, il en existe une qui va vous faire gagner énormément de temps et qui est probalement tout aussi valable que celle qui couvre la moitié du schéma fonctionnel.

> Le développement itératif
Avançons pas à pas, en faisant simplement les fonctionnalités principales avant de les perfectionner. Plutôt que de se faire chier passer un temps conséquent à programmer directement quelque chose de complexe ou d’incertain, juste une question : est-ce-que ça marche ? Le développement itératif c’est faire une fonctionnalité au plus simple par itérations : concevoir, programmer, tester, présenter, concevoir, programmer, tester, présenter…

…jusqu’à ce que le temps alloué à l’origine pour cette fonctionnalité soit révolu. On pourra toujours revenir ensuite sur les fonctionnalités qui demandent une finition plus avancée. Ceci permet d’orienter les fonctionnalités en cours de route et de rester dans le temps alloué à chaque fonctionnalité.

L’eXtreme programming est une technique qui fonctionne par itération et qui “permet de réconcillier l’humain avec la productivité” d’après Kent Beck mais surtout “puisque la simplicité permet d’avancer plus vite, nous choisirons toujours la solution la plus simple”… L’anti Usine à Gaz en quelque sorte.

> La coupe franche

La coupe franche c’est l’abandon pur et simple d’une fonctionnalité car elle est secondaire, c’est du “nice to have” (c’est bien si on l’a mais c’est du bonus), redondante, voir inutile.  C’est le résultat de l’analyse Pareto. Le client est déjà d’accord, il ne le sait pas encore, c’est tout. Au chef de projet de bien présenter les raisons et la finalité de l’abandon de telle ou telle partie.

Conclusion :

Une Usine à Gaz est vite arrivée, c’est toujours tentant pour un concepteur de se dire qu’il va engendrer du système couteau-suisse universel qui fait la vaisselle, tond la pelouse et règle la faim dans le monde.

Cependant c’est évitable avec quelque concepts très simples.

Au delà de la technique qui tombe globalement sous le sens pour notre époque, c’est surtout une histoire de communication entre le décideur, le donneur d’ordre et le concepteur, le réalisateur du projet.

Certains diront que cette communication n’est pas possible et je ne vais pas argumenter, c’est souvent le cas.
C’est donc le chef de projet qui doit vendre l’analyse de Pareto, vendre du simple et stupide, vendre un développement itératif, et vendre des coupes franches au client et le faire appliquer par le développeur pour pouvoir partir en vacances à temps le bien du projet.

Pour cela il doit garder la plus grande indépendance entre le donneur d’ordre et le développement afin de pouvoir garder sa ligne de conduite sans se faire engluer par les travers de l’un ou l’autre.