Pourquoi les équipes occupées sont lentes.
Garder tout le monde occupé semble efficace, mais les files d’attente disent l’inverse. Voici pourquoi, et ce que je changerais dans la planification.
Par Nizar Oukhchi, Architecte solution
Publié le · 7 min de lecture
Votre équipe est en retard. Alors vous faites la chose évidente : vous vous assurez que tout le monde est occupé.
Vous remplissez chaque sprint. Vous lancez le projet suivant avant la fin du précédent. Vous gardez la liste de tâches de chaque développeur bien pleine. Ça semble efficace.
Alors pourquoi tout ralentit ?
Ce n’est pas une question de motivation, ni de compétence. Ce sont des mathématiques. L’industrie et les télécoms les ont apprises il y a des décennies, et je crois que la plupart des équipes logicielles (moi compris, pendant longtemps) planifient encore comme si elles n’existaient pas.
Je vous montre.
Le travail passe sa vie à attendre
Pensez à ce qui arrive à une demande quand elle atteint une équipe.
Elle est rarement traitée tout de suite. D’abord, elle attend qu’une personne se libère. Puis elle attend une revue. Puis un environnement de test, une décision ou un créneau de mise en production.
Dans la plupart des équipes, le temps qu’un travail passe à attendre est bien plus long que le temps que quiconque passe vraiment à le faire.
Il existe toute une discipline qui étudie ces attentes : la théorie des files d’attente. Son résultat central s’énonce simplement :
Quand une ressource approche de son occupation maximale, l’attente devant elle ne croît pas régulièrement. Elle explose.
Voici à quoi ça ressemble :
| Taux d'occupation de l'équipe | Attente |
|---|---|
| 5 % | 0 × |
| 10 % | 0 × |
| 15 % | 0 × |
| 20 % | 0 × |
| 25 % | 0 × |
| 30 % | 0 × |
| 35 % | 1 × |
| 40 % | 1 × |
| 45 % | 1 × |
| 50 % | 1 × |
| 55 % | 1 × |
| 60 % | 1 × |
| 65 % | 2 × |
| 70 % | 2 × |
| 75 % | 3 × |
| 80 % | 4 × |
| 85 % | 6 × |
| 90 % | 9 × |
| 95 % | 19 × |
Lisons la courbe dans le modèle le plus simple.
À 50 % d’occupation, le travail attend, en moyenne, à peu près aussi longtemps qu’il dure. Rien de grave.
À 80 %, l’attente représente quatre fois le travail.
À 90 %, neuf fois.
À 95 %, dix-neuf fois.
Relisez ça. Ces derniers points « d’efficacité » se paient en semaines de retard.
Ça explique quelque chose qui m’a longtemps intrigué. Comment une équipe peut-elle paraître pleinement productive tout en semblant lente à tout son entourage ?
Parce que les deux sont vrais. Chaque personne est occupée. Et chaque travail passe l’essentiel de son temps à l’arrêt.
Un travail irrégulier aggrave les choses
C’est tout ? Pas tout à fait.
Cette courbe suppose un niveau d’aléa modéré. Le travail logiciel est souvent plus chaotique. Certaines tâches prennent une heure, d’autres deux semaines. Des demandes urgentes tombent sans prévenir.
La formule de Kingman, une approximation classique de la théorie des files d’attente, montre que l’attente augmente avec cette variabilité, et pas seulement avec la charge.
Voici la même occupation de 85 %, avec trois types de travail :
Une équipe au travail régulier, avec des tâches de taille homogène, attend environ deux fois moins que le cas de référence. Une équipe submergée d’urgences et de tâches très inégales attend environ deux fois plus.
Même charge. Attente très différente.
Et les deux leviers se multiplient. Une forte charge combinée à une forte variabilité, c’est là que les livraisons se bloquent.
Moins de travail en cours, des livraisons plus rapides
Passons à la bonne nouvelle.
La loi de Little est un résultat valable pour presque tout système stable. Elle relie trois grandeurs :
délai moyen = travail en cours ÷ débit
Disons que votre équipe termine dix éléments par semaine et en a quarante ouverts. Chaque élément met alors, en moyenne, quatre semaines du début à la fin.
Regardez maintenant ce qui se passe si on ne change qu’un seul chiffre :
L’équipe est-elle devenue plus rapide ? Non. Le débit est exactement le même.
Et pourtant, le délai baisse.
On peut raccourcir les délais sans travailler plus vite. Il suffit de lancer moins de travail à la fois.
Chaque élément passe moins de temps à attendre derrière les autres, et les retours arrivent plus tôt.
Il y a aussi des bénéfices que la formule ne montre pas. On change moins souvent de contexte. Les problèmes apparaissent pendant que le travail est encore frais dans les têtes. Les fonctionnalités terminées commencent à produire de la valeur plus tôt.
Ce que je changerais dans la planification
Soyons clairs sur un point. Rien de tout ça ne plaide pour des équipes inoccupées.
Ça plaide pour une planification qui tient compte de la courbe. Concrètement :
- Planifier à 70 à 80 % de la capacité. Le reste absorbe les correctifs urgents, les revues et l’imprévu sans bloquer tout le reste. Une équipe planifiée à 100 % est en retard dès le premier jour.
- Limiter le travail en cours. Fixez un plafond au nombre d’éléments en cours, par équipe ou par étape. Terminez avant de commencer autre chose. Un tableau avec moins de cartes en cours avance généralement plus vite.
- Réduire la variabilité quand c’est possible. Découpez les gros éléments en petits éléments de taille comparable. Faites passer les urgences par un canal dédié et limité plutôt que de les laisser tout interrompre.
- Observer les files, pas les personnes. Mesurez combien de temps le travail attend une revue, un test ou une mise en production. L’attente la plus longue est en général l’endroit où gagner du temps coûte le moins.
Pour ce dernier point, l’automatisation aide beaucoup. L’intégration continue et le déploiement en un clic suppriment plusieurs files d’un coup.
Pardonnez-moi cette métaphore culinaire : une cuisine débordée ne va pas plus vite en demandant à chaque cuisinier de jongler avec plus d’assiettes. Elle va plus vite quand les assiettes cessent de s’empiler au passe.
Une remarque sur les modèles
Je dois être honnête sur l’origine de ces chiffres.
Ils proviennent de modèles classiques reposant sur des hypothèses simplificatrices. Ce ne sont pas des mesures sur une équipe donnée, et les vraies équipes sont plus désordonnées.
La forme, elle, est robuste. L’attente croît fortement avec la charge. Elle croît avec la variabilité. Et elle baisse quand il y a moins de travail en cours.
Les équipes qui mesurent leurs propres délais retrouvent presque toujours ce schéma.
Par où commencer
Voici une petite expérience.
Pendant un mois, mesurez deux chiffres : combien d’éléments votre équipe termine par semaine, et combien sont en cours un jour ordinaire.
Divisez le second par le premier. Puis comparez le résultat avec le temps qu’il faut réellement pour que le travail arrive à vos utilisateurs.
Je parie que l’écart vous apprendra quelque chose.
Si les chiffres vous surprennent, nous serons ravis de vous aider à trouver où votre travail attend. Nos services d’ingénierie logicielle incluent la mise en place des chaînes de livraison qui font disparaître ces files.
Bonnes mesures !