- Description
- Ancien établi de menuisier en bois, avec ses étaux à vis et ses outils posés dessus.
- Source
- Лапоть · page d’origine
- Licence
- CC0 Domaine public
Expérience développeur et flux
Ce thème mesure la fluidité du travail d'un développeur et du flux de changements dans l'équipe : temps d'attente, boucles de retour courtes, charges cognitives maîtrisées, travail en cours…
En bref
Ce thème mesure la fluidité du travail d'un développeur et du flux de changements dans l'équipe : temps d'attente, boucles de retour courtes, charges cognitives maîtrisées, travail en cours limité. Il se lit comme l'effet cumulé des autres thèmes sur l'humain : un développeur productif est celui qui attend peu, comprend vite et peut agir seul.
Niveau : 🟢→🔴 · Code thème : DXF (matrice DL)
Pourquoi ce thème#
On mesure souvent la productivité par l'activité (lignes, tickets, heures), qui est un mauvais indicateur : on peut s'agiter beaucoup en livrant peu. Le cadre SPACE (satisfaction, performance, activité, communication et collaboration, efficacité et flux, 2021) invite à mesurer plusieurs dimensions plutôt qu'une seule. La recherche sur l'expérience développeur (DevEx) met en avant trois leviers : les boucles de retour (rapidité des tests, des revues, des builds), la charge cognitive (complexité à comprendre pour agir) et l'état de flux (interruptions, temps de concentration).
Côté flux, le travail en cours (WIP) est le principal ennemi : plus on commence de choses simultanément, plus chacune met de temps à finir (loi de Little). Limiter le WIP raccourcit le délai de bout en bout, révèle les goulots (en général : la revue, la recette, l'attente d'un environnement) et réduit le changement de contexte. L'équipe type de plateforme (Team Topologies) vise à rendre ces services internes (environnements, pipelines) « en libre-service ».
Remarque de prudence : ce thème est celui où la loi de Goodhart frappe le plus fort. Toute mesure individuelle de productivité se détourne ; les mesures sont ici des diagnostics d'équipe et de système, jamais des évaluations de personnes.
Ce que mesure le thème#
- Axe : de « on se bat contre l'outillage » à « l'outillage s'efface ; le temps va à la résolution de problèmes ».
- Indicateurs clés : durée de la boucle locale (modifier → voir le résultat) ; temps d'attente d'une revue ; flow efficiency (part du délai passée en travail effectif, non en attente) ; WIP par personne ; satisfaction déclarée (enquête courte).
- Unité : secondes/minutes ; heures ; % ; nombre ; score de 1 à 5.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Subi | Le développeur compose avec les outils tels qu'ils sont, souvent à son détriment. | Installation du poste en jours ; boucle locale en dizaines de minutes |
| 2 | Équipé | Un poste neuf est opérationnel en une journée et les outils de base sont maintenus. | Poste en < 1 j ; boucle locale < 5 min |
| 3 | Rapide | Le retour sur un changement (test, revue, build) arrive en quelques minutes, pas en heures. | Boucle locale < 1 min ; revue < 1 j ; CI < 15 min |
| 4 | Fluide | Le travail s'écoule : peu d'attente, peu d'interruptions, peu de travail en cours. | WIP limité ; flow efficiency > 30-40 % ; environnements en libre-service |
| 5 | Optimisé | Les obstacles sont repérés et supprimés en continu ; l'équipe passe l'essentiel de son temps sur la valeur. | Enquête DevEx suivie ; obstacles résolus en < 2 sem. |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-DXF-1.1 | Les outils nécessaires sont fournis à chaque développeur | Liste d'outils standard |
| DL-DXF-1.2 | Les accès (dépôt, environnements, outil de suivi) sont accordés en < 1 semaine | Délai mesuré à la dernière arrivée |
| DL-DXF-1.3 | Les irritants majeurs sont connus (liste de problèmes d'outillage) | Liste commentée |
| DL-DXF-2.1 | Le poste est opérationnel en moins d'un jour (script ou procédure) | Mesure sur une arrivée |
| DL-DXF-2.2 | La construction et l'exécution locales ne demandent pas de connaissance cachée | Test par un tiers |
| DL-DXF-2.3 | Les environnements de développement sont reconstructibles (base locale, données de test) | Reconstruction en < 1 h |
| DL-DXF-2.4 | Un canal d'aide existe, avec réponse en < 1 demi-journée | Délai mesuré |
| DL-DXF-3.1 | La boucle « modifier → voir le résultat » en local prend < 1 minute pour le cas courant | Chronomètre sur 5 cas |
| DL-DXF-3.2 | Le délai d'attente d'une revue est < 1 jour ouvré | Médiane sur 3 mois |
| DL-DXF-3.3 | Le pipeline donne son retour en < 15 minutes, et les erreurs sont lisibles | Durée et enquête |
| DL-DXF-3.4 | Les tâches répétitives sont automatisées (scripts d'équipe partagés) | Dépôt d'outils d'équipe |
| DL-DXF-3.5 | Une enquête courte de satisfaction est menée au moins deux fois par an | Résultats et actions |
| DL-DXF-4.1 | Le travail en cours est limité (règle explicite de WIP) | Limite visible et respectée |
| DL-DXF-4.2 | La part d'attente dans le délai de bout en bout est mesurée (flow efficiency) | Tableau de flux |
| DL-DXF-4.3 | Les environnements et pipelines sont en libre-service (pas de ticket pour en obtenir un) | Délai d'obtention < 1 h |
| DL-DXF-4.4 | Les interruptions et réunions sont régulées (plages protégées) | Calendrier équipe |
| DL-DXF-4.5 | La charge cognitive est traitée : modèles de départ, conventions, composants partagés | Modèles utilisés par ≥ 80 % des nouveaux composants |
| DL-DXF-5.1 | Les obstacles remontés sont classés et résolus en < 2 semaines (ou arbitrés explicitement) | Suivi des obstacles |
| DL-DXF-5.2 | La satisfaction et le flux sont suivis dans le temps ; les tendances guident des investissements | Courbes sur 4 trimestres |
| DL-DXF-5.3 | Une équipe ou un rôle de plateforme gère l'outillage comme un produit, avec ses utilisateurs internes | Feuille de route et retours |
| DL-DXF-5.4 | Aucun indicateur n'est utilisé pour évaluer individuellement les personnes | Charte d'usage des mesures |
Lecture détaillée par niveau#
🟢 Niveau 1 — Subi#
- Signes : installation d'un poste = deux jours de chasse aux accès ; build qui ne marche « que chez Paul ».
- Gain : aucun.
- Ne garantit pas : rien — le coût est caché dans le temps perdu.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Équipé#
- Signes : poste prêt en un jour, procédure testée, environnements reconstructibles, aide disponible.
- Gain : intégration rapide ; moins de frustration de base.
- Ne garantit pas : la rapidité des retours.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Rapide#
- Signes : retour en minutes ; revue sous un jour ; scripts partagés. Chaque seconde gagnée sur la boucle locale est multipliée par des centaines d'itérations quotidiennes.
- Gain : plus d'essais, plus d'apprentissage, moins de découragement.
- Ne garantit pas : l'écoulement du travail entre les mains.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Fluide#
- Signes : limite de WIP, mesure de l'attente (la plupart des tickets passent la majorité de leur délai à attendre, pas à être travaillés), environnements en libre-service, interruptions régulées.
- Gain : délais de bout en bout courts et prévisibles ; moins de changement de contexte.
- Ne garantit pas : la satisfaction durable — elle se mesure et se travaille.
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Optimisé#
- Signes : l'équipe traite ses obstacles comme un carnet de produit ; un rôle de plateforme sert les équipes ; aucune mesure ne sert à noter les individus.
- Gain : amélioration continue de la capacité de livraison et de la rétention.
- Ne garantit pas : la qualité du produit — la fluidité d'un flux de travaux inutiles reste inutile.
- Difficulté : 5/5 · Effort : 4/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-DXF-3.2 : revue médiane à 1,5 jour, avec forte dispersion.
- 0,5 sur DL-DXF-4.1 : limite de WIP affichée mais dépassée régulièrement.
- Un 5 partiel : obstacles résolus rapidement, mais pas de suivi de tendance de satisfaction.
Outil de surveillance déguisé. Symptôme : les développeurs trichent avec les indicateurs ou les craignent. Cause : usage individuel (classement, primes). Remède : charte explicite (jalon 5.4), mesures d'équipe uniquement, enquêtes qualitatives en complément.
Optimiser un goulot qui n'en est pas un. Symptôme : on accélère le build, le délai ne change pas. Cause : le vrai goulot est l'attente de recette. Remède : cartographier le flux (carte de valeur) avant d'investir.
Chronométrez vous-même, une fois par trimestre, le parcours complet d'un changement trivial (une ligne modifiée → en production). Le chiffre et les attentes révélées valent mieux qu'un rapport.
Une équipe de 6 personnes porte 14 tickets en cours ; le délai moyen est de 19 jours dont 14 en attente de revue ou de recette. Limiter le WIP à 8 et convenir d'une revue sous 24 h ramène le délai à 9 jours sans accélérer personne.
Un objectif de « réduction du délai de revue » incite à approuver sans lire. Contrôlez en parallèle la qualité (défauts échappés, 02).
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : script d'installation de poste, procédure testée par le dernier arrivé.
- 2 → 3 : accélérer la boucle locale (tests ciblés, rechargement à chaud), règle de revue sous un jour, enquête.
- 3 → 4 : limiter le WIP, cartographier le flux, libre-service.
- 4 → 5 : carnet d'obstacles, rôle de plateforme, charte d'usage des mesures.
Voir aussi#
- Voisins : 02 Qualité du code · 03 Tests · 04 Gestion de version · 05 CI · 10 Documentation.
- Autres matrices : Projet — équipe et collaboration · Projet — amélioration continue · Projet — planification et estimation.
- Pratique : méthodes agiles et lean · métriques et reporting de projet · CI/CD · IA et outils.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
