03. Les contraintes gouvernent le système
Quand la livraison ou la stabilité glissent, ce n'est pas l'effort: c'est une contrainte révélée.
Travailler plus fort ne suffit plus
Quand les organisations arrivent chez JPSoftWorks, les équipes sont déjà engagées à fond.
Des backlogs pleins.
Des incidents fréquents.
Les contextes changent trop fréquemment
Des objectifs manqués.
À ce stade, l'effort n'est plus la variable. Le système l'est.
Et chaque système a une, ou même des contraintes.
Une vérité systémique incontournable
Un système ne peut jamais dépasser sa contrainte principale.
Peu importe la performance ailleurs.
Le problème n'est pas d'avoir des contraintes.
Le problème, c'est de les ignorer.
L'usine, encore et toujours
Dans une chaîne de production, on n'accélère pas partout. On agit au goulot:
- Plus de capacité
- Plus d'automatisation
- Moins d'entrée
- Meilleur design
Le logiciel fonctionne exactement pareil.
Les contraintes se révèlent par les signaux
Souvent, elles apparaissent via:
- Des SLOs (Service Level Objectives) manqués
- Des SLAs (Service Level Agreements) fragiles
- Une MTTR (Mean Time to Recovery) qui grimpe
- Une fatigue opérationnelle accrue
Ces signaux ne sont pas des échecs. Ce sont des alertes systémiques.
SLOs et SLAs: des détecteurs de contraintes
Chez JPSoftWorks, un SLO manqué n'est pas un blâme. C'est une information.
La fréquence des écarts révèle:
- Un manque de capacité
- Une dépendance humaine
- Une automatisation absente
- Un flux déséquilibré
La vélocité fonctionnelle sans santé des SLOs est un mirage.
Gouvernance et réalisme
Les objectifs rendent la gouvernance concrète.
Quand les SLOs se dégradent, la question n'est pas qui a fauté, mais quelle contrainte vient d'apparaître.
Sécurité mesurée, pas supposée
Quand les SLAs de sécurité sont visibles:
- Les problèmes deviennent discutables
- Les améliorations deviennent ciblées
- La sécurité s'intègre naturellement au flux
Automatiser là où ça fait mal
Automatiser hors contrainte ne change rien.
Automatiser au goulot change tout.
WIP et contraintes
Une contrainte ignorée entraîne:
- Accumulation de travail
- Multitâche (et latences de changement de contexte fréquents)
- Dégradation des SLOs
Limiter le WIP protège le système, comme nous l'avons vu récemment.
Mise en pratique
- Définir des SLOs clairs
- Observer leur dérive
- Lier SLOs et flux
- Améliorer au bon endroit (concept du "low hanging fruit")
Mot de la fin
Les contraintes parlent. Les SLOs traduisent.
Si vos équipes sont épuisées et vos objectifs instables, le système vous envoie un message.
Chez JPSoftWorks, c'est là que commence le vrai travail DevOps. Si vous voulez que ça change, on peut vous aider.
Références
| Sujet | Lien |
|---|---|
| Theory of Constraints | https://en.wikipedia.org/wiki/Theory_of_constraints |
| The Phoenix Project | https://itrevolution.com/the-phoenix-project/ |
| SRE & SLOs | https://sre.google/sre-book/service-level-objectives/ |
| Kanban | https://kanban.university/ |
| Team Topologies | https://www.teamtopologies.com/ |