The Goal, appliqué au code : occupé n'est pas productif

J'ai lu The Goal, roman de 1984 consacré à l'amélioration d'une usine industrielle. Plutôt que d'en faire un résumé de la théorie des contraintes, j'ai essayé de voir comment les idées du livre pourraient se transposer à l'ingénierie logicielle.

Voici les quelques fils conducteurs que j'en retiens.

1. Partir du but

Pour une équipe logicielle, je retiens comme but :

«Apporter de la valeur aux utilisateurs.»

Cette valeur doit pouvoir se constater : temps de traitement réduit, moins d'erreurs, meilleure satisfaction, usage simplifié, etc.

Cela oblige à se méfier des indicateurs locaux : nombre de fonctionnalités développées, occupation des développeurs, tickets traités... Un bon indicateur est celui qui renseigne sur le progrès du système dans son ensemble.

2. Regarder le flux

Le logiciel est un système :

demande → analyse → conception → développement → tests → validation → déploiement → utilisation

Une équipe peut être très occupée et pourtant livrer lentement. Il faut donc regarder où le travail s'accumule, où il attend et ce qui limite réellement le flux. Optimiser chaque étape ne garantit pas d'améliorer le système.

3. Chercher la contrainte

Plutôt que de chercher partout ce que l'on pourrait améliorer, il faut chercher :

«Qu'est-ce qui empêche actuellement le système d'avancer ?»

Et avant d'ajouter des ressources, essayer d'exploiter au mieux celles qui existent déjà.

Si les tests sont la contrainte, produire encore plus de code ne fait qu'augmenter l'en-cours. Un développeur peut alors avoir davantage d'intérêt à aider aux tests qu'à commencer une nouvelle fonctionnalité.

4. Limiter l'en-cours

Une idée que je trouve particulièrement transposable au logiciel :

«Commencer par terminer avant de commencer.»

Accumuler des fonctionnalités « presque terminées » ne crée pas de valeur. Réduire l'en-cours permet de concentrer l'effort sur la sortie réelle des fonctionnalités.

Et lorsqu'une personne a du temps disponible, il n'est pas nécessaire de chercher artificiellement à l'occuper : elle peut se former, faire de la veille, comprendre les autres étapes du flux ou proposer des améliorations.

5. Prioriser réellement

Tout ne peut pas être urgent. La priorité doit reposer sur des éléments concrets : valeur, urgence réelle, échéance, engagement, risque...

Un ticket "urgent" qui n'a d'urgent que le mot employé par celui qui le demande n'est pas une priorité — c'est une interruption. Le laisser passer avant le reste, c'est engorger la contrainte qu'on vient d'identifier au §3.

Et parfois, la réponse saine est simplement : « Nous n'avons pas les moyens de la prioriser. » Le but n'est pas de faire entrer toujours plus de travail dans le système, mais de préserver son flux.

6. Améliorer, mesurer, recommencer

Une amélioration n'est intéressante que si elle améliore réellement le système. Après chaque changement, il faut donc regarder :

• le temps de sortie s'est-il amélioré ?
• l'en-cours a-t-il diminué ?
• avons-nous simplement déplacé le problème ?
• une nouvelle contrainte est-elle apparue ?

On retrouve finalement une logique très proche du PDCA (Plan-Do-Check-Act) : observer → améliorer → mesurer → apprendre → décider → recommencer.

C'est probablement ma principale lecture de The Goal :

«Ne pas chercher à rendre chaque élément du système performant, mais chercher continuellement à rendre le système meilleur.»