La théorie des files d’attente est une branche des probabilités modélisant les temps d’arrivée, de traitement, les problèmes de congestion etc dans les files d’attente ou queues.
L’ingénierie réseaux et plus tard la gestion de production industrielle se sont rapidement emparées des principaux résultats de cette discipline pour améliorer leur efficacité. Plus récemment, des activités de services tels que la gestion des guichets de banques ou les urgences hospitalières ont elles aussi bénéficié d’une étude de ce domaine.
Une démarche scientiste consisterait à plaquer aveuglément des équations mathématiques sur l’univers organique et infiniment complexe du SI. Dans notre cas, on étudiera certains résultats de la théorie des files d’attente comme source d’inspiration dans notre démarche d’amélioration continue, en gardant à l’esprit les limites de ces modèles mathématiques.
La loi
Un des principaux résultats de la théorie des files d’attente est la loi de Little qu’on pourrait formuler ainsi : dans un système stable [1] le nombre moyen de » client » du système (N) est égal au taux moyen de traitement (λ) multiplié par le temps moyen passé par le client dans le système (T) [2].
N =
λxT
On parle de » loi » car Little a démontré mathématiquement le résultat dans le cas d’un temps d’observation du système tendant vers l’infini. Mais ce résultat est une tautologie dont nous pouvons avoir une compréhension intuitive avec le schéma suivant :
A l’état stable la loi de Little se vérifie : les » clients » (les colis du schéma) rentrent au rythme de 1 client par seconde (λ = 1c/s), le système contient 2 clients (N = 2 c) et le temps passé par un client dans le système est de 2 secondes (T = 2 s).
Des conséquences en développement logiciel
Une traduction en développement logiciel
Revenons au développement logiciel, en considérant que notre » système » est une équipe de développement et que notre » client » au sens des file d’attente est une fonctionnalité qui rentre sous forme de demande et sort une fois » servie » sous forme de logiciel. La loi s’exprimerait alors ainsi :
L’en cours de fonctionnalités dans l’équipe de développement (N) est égal au taux moyen de demande traitée (λ) multiplié par le temps de cycle [3] moyen.
Optimiser le temps de cycle
Les acheteurs du développement d’un logiciel ont deux motivations à la réduction du temps de cycle (T) :
- Un meilleur time-to-market [4].
- La concrétisation plus rapide de leurs demandes afin de décider sur la base du produit livré de modifier la demande initiale ou de rectifier des erreurs de production.
La loi de Little nous invite à creuser deux pistes pour diminuer le temps de cycle (T) : soit diminuer le nombre de fonctionnalités en cours de développement, soit augmenter le débit de demande de fonctionnalités.
Diminuer le nombre de fonctionnalités en cours de développement
Le lotissement projet ou la prise en compte d’un ensemble modeste de fonctionnalité par itération courte sont autant de moyen bien connus de diminuer le nombre de fonctionnalités en cours de développement.
Ces pistes restent de l’ordre du truisme puisque qu’on pourrait les reformuler ainsi : pour avoir moins d’en cours…je mets moins d’en cours. La vraie difficulté consiste alors à remplir son backlog d’itération en maintenant un encours limité, quantitativement stable. Une priorisation forcenée s’impose comme la solution privilégiée pour maintenir cet encours réduit.
Augmenter le débit de demande
La tentation d’augmenter le débit de demande pour réduire le temps de cycle est grande au regard de la loi de Little. Dans le cas du développement logiciel une première limite à cette augmentation est la limite de capacité de travail de l’équipe de développement ; limite qu’on est tenté de dépasser en augmentant les effectifs.
Malheureusement cette possibilité se heurte aux limites de la loi de Little puisque celle-ci ne traite que de valeurs moyennes pour un système stable. Dans le cas du développement logiciel, les problématiques de communication, d’alignement, d’attente et plus généralement de » mouvements » d’informations se traduisent en théorie des files d’attente par un temps de cycle (T) dépendant du débit de demande…et qui augmente dangereusement sous certaines conditions.
Nous reviendrons dans un autres post sur ces questions en nous basant sur d’autres résultats de la théorie des files d’attente. Disons pour l’instant qu’un débit élevé amplifiera des phénomènes dits de variations, de congestion et augmentera par là même T.
Conclusion
La loi de Little propose donc une voie possible d’amélioration du temps de cycle en diminuant le nombre d’éléments en cours de développement par la priorisation de l’en cours.
Un exercice intéressant consiste à analyser d’autres » systèmes » du SI avec la Loi de Little. Par exemple :
- Une équipe projet au sens large (MOA + MOE + exploitation) ;
- Une équipe d’infrastructure/exploitation ;
- Un développeur seul ;
- Une Direction des Systèmes d’Information ;
- Vous-même !
Attention, avant d’analyser ces systèmes à la lumière de la loi de Little, il faut identifier avec soin le » client » de ces systèmes ainsi que les entrées/sorties de ces systèmes. C’est à ce moment que la le défi de la difficulté d’application à nos métiers apparaît. A vous de jouer.
Comme évoqué dans ce post, la théorie des file d’attente permet d’envisager des problématiques dépassant l’échelle macroscopique de loi de Little, notamment la variabilité, la congestion, les taux d’utilisation des ressources… Nous y reviendrons plus tard.
[1] Stable au sens ou le temps de traitement d’un client est constant dans le temps et le débit d’entrée est constant.
[2] Une des forces de la loi de Little c’est qu’elle peut aussi s’appliquer à la file d’attente en amont du système. Dans ce cas ? est le taux d’arrivée dans la file d’attente, N le nombre de client dans la fil et T le temps passé dans la file.
[3] Si notre système est l’équipe de développement le temps de cycle correspond au temps entre la réception par l’équipe de développement d’une demande de fonctionnalité et la livraison par l’équipe de la fonctionnalité.
[4] Les acteurs d’un marché concurrentiel ont des offres de service comparables sur le long terme. Le vainqueur est celui qui innove en proposant le service avant les autres. En définitive la compétition ne porte plus sur le produit mais sur le temps.
