POTTA — Plan One To Throw Away

18-01-2024 15:20:08

Einstein repeatedly argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer.

Frederick P. Brooks in The Mythical Man-Month: Essays on Software Engineering

Cette question de deuxième système est largement sous-estimée car dérangeante et souvent inacceptable. Elle ne fait donc que très rarement surface. Je ne recommande pas de la mettre trop ostensiblement en avant car elle pourrait vous disqualifier d'entrée de jeu en tant qu'aveu de faiblesse. Il s'agit donc d'en tenir compte dans votre for intérieur et de vous y préparer secrètement.

De quoi s'agit-il ? Il s'agit de la reconnaissance d'un principe de réalité. Ce principe est issu de l'observation, et plus particulièrement celle qui se manifeste lors de la mise au point de systèmes nouveaux de moyenne ou de grande envergure.

En soi, ce principe épouse en creux les vues de l'Agilité et des processus d'innovation tels que propulsés sur le devant de la scène par une méthode comme Lean Startup.

Plus souvent qu'attendu, on pense savoir ce qu'il faut faire mais nous n'arrivons qu'à couvrir très partiellement le besoin de ceux à qui on destine le produit ou service envisagé, et ce malgré tout le sérieux de la démarche. C'est toute la question du JTBD — Job To Be Done. Une fois l'objectif bien dégagé, et validé heuristiquement et empiriquement, se pose la question du "comment faire". Le plus souvent, et il en coûte de reconnaître notre ignorance, on n'en sait rien. On pratique alors par petites étapes comme le démineur y va petit pas par petit pas pour dégager un terrain dangereux.

Cette démarche est parfaitement normale; elle est empreinte d'un luxe de prudence et s'effectue avec retenue. L'architecte expérimenté utilisera l'heuristique tout comme le lead-designer d'ailleurs.

Heuristique : technique empirique de résolution de problèmes ne passant pas par l'analyse détaillée du problème mais par son appartenance à une classe de problèmes déjà identifiés […] Ce système empirique inclut notamment la méthode essai—erreur.

La plupart du temps, lorsque le système à construire est nouveau, sa première version n'a qu'une seule vertu : elle fonctionne, enfin sommes-nous en droit de l'espérer du moins. Tout au long de sa construction, on se rend compte d'erreurs, de limitations, d'optimisation possible, etc. Quand on commence, l'architecte avisé est comme Jean Gabin : il sait qu'il ne sait pas.

Agissant avec sagesse, on prend toutes notes utiles sur ce qui serait approprié de concevoir autrement, d'embellir ici et là, de généraliser, etc. On fera tout cela plus tard, après que la première version soit livrée. Le carnet se remplit de notes diverses embrouillées.

Tôt ou tard, on livre la première version et on commence à être exposé à la réalité de l'utilisation qui en est faite. On découvre alors des manières inattendues de se servir du produit/service, on se rend compte de sa piètre performance dans divers contextes, on se rend compte qu'on éprouve des difficultés à reproduire certaines conditions problématiques, etc. etc. L'idée s'installe qu'il n'y a pas d'autre alternative que de recommencer, de manière plus intelligente, et de construire une version remaniée dans laquelle les problèmes observés seront résolus.

L'envie de faire mieux est forte et si l'on n'y prend pas garde on peut tomber dans le piège du second système qui, tel un glouton, embarque une série de fonctionnalités supplémentaires, d'améliorations hétéroclites, de paramétrisation additionnelle ou plus fine, d'options diverses et variées, etc.

Frederick Brooks nous dit que le second système est dangereux à cause de cette inflation de nouvelles choses qu'on adjoint à la première version. La prudence et la retenue dont l'équipe faisait montre lors de la mise au point de la première version sont oubliées, rejetées même. L'équipe a pris confiance dans sa capacité à résoudre le JTBD et s'estime expérimentée. Cet excès de confiance touche beaucoup d'activités humaines : le jeune conducteur qui néglige le danger de la route, l'équipe de foot qui sous-estime un adversaire moins prestigieux, l'équipe agile qui devient soudainement trop ambitieuse, etc.

Un refactoring régulier permet de vider lentement le carnet de notes. Cela diminue considérablement la tentation d'en faire trop pour la seconde version. Cette activité de refactoring est comme la soupape qui diminue la pression de surjouer le match.

Lorsque l'équipe en sera à sa troisième ou quatrième version, ayant passé l'écueil des première et deuxième, une forme de routine positive s'installe qui trouve ses racines dans une réelle expérience du terrain. Cela correspond souvent au sortir de la phase de Storming du modèle de Tuckman. Le chef d'équipe y sera attentif et ce sera pour lui le signal de commencer à lâcher la bride de l'autonomie.

Frederick Brooks nous dit :

La question Management n'est donc pas de savoir s'il faut construire un système pilote et le jeter. C'est ce que vous allez faire de toute façon. La seule question est de savoir s'il faut planifier à l'avance la construction d'un système à jeter, ou s'il faut promettre de livrer le système à jeter aux clients.

Si Brooks a évidemment raison, il est quand même contredit — et fort heureusement — par les mesures que l'Agilité propose. C'est un des apports du nouveau paradigme !

Il n'est pas le seul à nous mettre en garde : Winston Royce ne dit pas autre chose …

Si le programme […] est développé pour la première fois, il faut prévoir que la version finalement livrée au client pour le déploiement opérationnel est en fait la deuxième […]

On retiendra donc qu'il est nécessaire d'anticiper une possible deuxième version (ce que j'ai pu constater dans nombre de situations personnelles). On retiendra encore que, parlant du développement de cette fameuse deuxième version, il faille exercer notre sens critique le plus aiguisé afin d'empêcher tout enflement téméraire et incontrôlé qui s'apparenterait au muda Overproduction de Lean, considéré comme la source la plus importante de gâchis. On se tournera vers quelques principes de l'Agilité qui ont la vertu de nous protéger de tels pièges.

Quelles contre-mesures ?

L'Agilité offre une série d'outils/principes qui permettent de déjouer les pièges contre lesquels Brooks nous met en garde. Je ne ferai que les aborder succinctement.

Le MVP

Découvrir le produit / service à mettre au point lors d'un processus d'idéation permet de réduire l'incertitude de la paire What et How à un singleton : le How.

Resserrant l'incertitude au How, on peut se servir du cycle de première construction pour aborder la question des notes techniques et opérationnelles qui encombrent probablement le parking lot. Ce n'est pas rien cette orientation car elle peut sembler s'éloigner des préoccupations traditionnelles de l'Agilité. Se détourner temporairement des soucis fonctionnels pour s'inquiéter davantage de tourments techniques et opérationnels, à l'exclusion des notes fonctionnelles, voilà qui nous rapproche dangereusement de l'hérésie. Rien n'est moins vrai.

Ce qu'on effectue à ce moment est plus une modification d'angle que l'adoration du dieu Technique. On est comme une tourelle de défense qui pivote pour s'intéresser à d'autres stakeholders : il faut rendre le produit / service le plus facile possible à modifier et opérer. Sur un terme plus long l'utilisateur en est indirectement l'ultime bénéficiaire.

Orientation DevOps

Saisissant ce qui vient d'être exposé ci-avant, on comprend d'emblée que l'orientation DevOps nous aide puissamment.

Le bon Product Owner

Pour être capable de se détourner des soins purement fonctionnels, temporairement et avec mesure, il est nécessaire d'avoir des représentants Business éclairés et expérimentés. Se tournant vers le Product Owner, proxy du business, s'engagent alors de multples discussions où l'architecte et les Ops sont investis d'une immense responsabilité : expliquer en quoi leurs soucis peuvent entraver les développements futurs et la flexibilité naturelle du logiciel. Il est nécessaire de parler, de communiquer, de comprendre, parfois même de négocier.

Nature intrinsèque du travail itératif

L'itération rapide, le sprint en Scrum, permet de reconsidérer à chaque instance le travail à réaliser. Les AMIS détectés précédemment peuvent alors être pris en compte pour l'itération qui se présente.

Livraison rapide et fréquente

Livrer le produit rapidement, même incomplet, permet d'être confronté aux réalités du terrain plus tôt que ce qu'ont connu Brooks et/ou Royce. Me limitant aux pures questions techniques et opérationnelles, l'architecte et le lead-designer peuvent réorienter la solution plus rapidement et s'emparer déjà de certaines préoccupations qui leur sont propres. On prend conscience des manques et inadéquations qui s'imposent à nous de manière naturelle sans analyse car révélés par les faits et observations du terrain. Les constats s'imposent avec immédiateté (remembrance vs. recognition).

Lorsque les boucles de feedback sont les plus directes possibles il est possible de collecter quantité de renseignements que je range sous l'acronyme AMIS : Anomalies, manques, inadéquations, suggestions.

Refactoring

Le rituel du refactoring donne l'occasion de réorienter le code en respectant des principes économiques (rapport entre l'importance des bénéfices générés et les coûts engendrés). Le refactoring n'apporte généralement aucune fonctionnalité supplémentaire (aucun bénéfice fonctionnel adjoint) pour se concentrer sur l'optimisation et la simplification de ce qui a déjà été construit (diminution du coût de développement et maintenance).

Au contraire de ce qu'ont connu Brooks et Royce, on élimine la dette technique le plus rapidement possible pour s'assurer qu'on puisse demeurer leste et agile. On est néanmoins conscient que tout est affaire de bon équilibre entre la capacité à délivrer de nouvelles fonctionnalités avec un rythme soutenu et la prise en compte d'éléments purement techniques.