Délai de livraison vs. temps de cycle - Développement logiciel Lean

1Définitions qui comptent

Ces termes sont fréquemment confondus mais crucialement différents :

Délai de livraison : Le temps total écoulé depuis qu'un client fait une demande jusqu'à ce qu'il reçoive la valeur. C'est ce que le client vit. Cela inclut toute l'attente, tout le traitement, tout.

Temps de cycle : Le temps que le travail passe à être activement travaillé. C'est ce que les travailleurs vivent pendant leur portion du flux.

Exemple : Un client demande une fonctionnalité le lundi. Elle est priorisée et intégrée au développement le mercredi. Un développeur y travaille pendant 2 jours. Elle reste en révision de PR pendant 3 jours. Les tests prennent 1 jour. Elle est déployée le vendredi de la semaine suivante.

Délai de livraison : 12 jours (du lundi au vendredi de la semaine 2)
Temps de cycle (Développement) : 2 jours
Temps de cycle (Révision) : Quelques heures
Temps de cycle (Tests) : 1 jour

Remarquez : le travail actif était peut-être de 4 jours au total. Le délai de livraison était de 12 jours. Huit jours étaient de l'attente.

La métrique que vous suivez est probablement la mauvaise

La plupart des équipes suivent le temps de cycle ou la vélocité — ce que les travailleurs produisent. Mais les clients ne se soucient pas de votre vélocité. Ils se soucient du délai de livraison — combien de temps ils attendent. Optimisez pour ce que les clients ressentent, pas pour ce qui a l'air bien à l'interne.

2D'où vient l'écart

L'écart entre le délai de livraison et le temps de cycle est le temps d'attente. Et le temps d'attente domine généralement.

Temps de file d'attente : Travail qui reste dans les backlogs, en attente d'être priorisé, en attente que quelqu'un le prenne.

Délais de transfert : Travail terminé à une étape, en attente que l'étape suivante ait de la capacité.

Délais de regroupement : Travail qui est terminé mais en attente d'être déployé avec d'autres travaux.

Dépendances externes : Attente d'autres équipes, fournisseurs ou approbations.

Délais de calendrier : Travail qui est prêt mais « nous déployons seulement les mardis ».

Dans la plupart des organisations logicielles, le temps d'attente représente 80 à 95 % du délai de livraison. Cela signifie que seulement 5 à 20 % du temps, le travail est réellement en cours.

L'implication : améliorer la vitesse à laquelle vous travaillez a un impact minimal. Si vous travaillez deux fois plus vite mais que les attentes restent les mêmes, le délai de livraison change à peine. Le levier est dans les attentes.

2 heures de travail, 2 semaines de délai de livraison

Une simple correction de bogue : 2 heures de temps de développeur. Mais : 3 jours d'attente pour l'assignation, 2 jours d'attente pour la révision de PR, 1 jour d'attente pour l'AQ, 3 jours d'attente pour le déploiement hebdomadaire, 2 jours de surveillance en production. Délai de livraison : 11 jours.

Même travail, système différent

Même correction de bogue, équipe différente : PR révisée en quelques heures (petites PR, priorité d'équipe sur la révision). Pas de file d'attente AQ (les développeurs testent leur propre code). Déploiement continu (pas de fenêtres de déploiement). Délai de livraison : 3 heures.

3Temps de contact et temps d'attente

Une autre répartition utile :

Temps de contact : Temps où le travail est activement progressé par un humain. Mains sur le clavier. Cerveau engagé sur ce problème.

Temps d'attente : Tout le temps entre les deux. Dans les files d'attente. En attente de révision. En attente de déploiement. En attente d'information.

Temps de traitement : Temps de contact plus temps machine (builds, tests, déploiements). C'est le temps de cycle.

Quand vous comprenez cette répartition, vous pouvez cibler les améliorations correctement :

Temps de contact long mais valeur ajoutée élevée ? Probablement pas du gaspillage — c'est du travail qualifié.
Temps de contact long mais valeur ajoutée faible ? Gaspillage potentiel — automatisez ou éliminez.
Temps d'attente long ? Presque certainement du gaspillage — réduisez les lots, limitez le travail en cours, éliminez les files d'attente.

La plupart des équipes essaient de rendre le temps de contact plus rapide (meilleurs outils, plus de développeurs) quand le problème est le temps d'attente (trop de travail en cours, regroupement, files d'attente). C'est comme essayer de faire aller les voitures plus vite quand elles sont coincées dans le trafic.

Si vous avez un problème de délai de livraison, vous avez probablement un problème de temps d'attente. Si vous avez un problème de temps d'attente, vous avez probablement un problème de travail en cours. Réduire le travail en cours est généralement le chemin le plus rapide vers des délais de livraison plus courts.