Théorie des contraintes

Qu'est-ce que la théorie des contraintes ?

La théorie des contraintes (TdC) est un paradigme de gestion visant à faciliter les flux. Elle est basée sur le roman "The Goal" [Goldratt 1984] qui expose l'idée qu'"une chaîne n'est pas plus forte que son maillon le plus faible". Goldratt propose 5 étapes pour mettre en œuvre le ToC :

1. Identifier les contraintes du système
2. Décider comment exploiter les contraintes du système
3. Subordonner tout le reste à la décision ci-dessus
4. Renforcer les contraintes du système
5. Si une contrainte a été brisée au cours des étapes précédentes, retournez à l'étape 1.

En termes simples, vous devez supprimer tout goulot d'étranglement, sauf s'il entrave une autre partie de l'organisation, afin de soutenir une vision systémique. Les goulets d'étranglement ne sont pas toujours ce que nous pensons et où nous pensons qu'ils sont, et les marches Gemba vous aideront à repérer les véritables problèmes [Marris 2016].

Il existe quatre types d'organisations nommées VATI [Cox 2010].

• Organisations en forme de V: à partir d'une matière première unique, des composants intermédiaires sont générés à partir de multiples combinaisons et finalement assemblés pour construire différents produits.

‍

• Organisations en forme de A: à partir d'un ensemble de matières premières, l'organisation effectue des combinaisons pour assembler un produit unique.

‍

• Organisations en forme de T: à partir d'un ensemble de matières premières, un pipeline de transformation fournit un modèle du produit qui est décliné à la fin pour répondre à des objectifs multiples.

‍

• Organisations en forme de I: à partir d'un ensemble de matières premières, un pipeline de transformation fournit un produit unique.

‍

À un niveau inférieur, le cahier des charges propose un modèle appelé "DBR" [Cox 2010] pour Drum-Buffer-Rope :

• le tambour fournit une certaine cadence, que l'on retrouve également dans SAFe [SAFe 2021-07].
• le tampon fournit une petite zone de stockage intermédiaire pour éviter l'effet "rien à faire" sur un processus, mais suffisamment petite pour éviter les gaspillages de stocks importants.
• la corde est un déclencheur tiré notamment du processus le plus lent pour informer les producteurs en amont qu'une certaine bande passante peut être disponible en aval pour permettre aux systèmes tirés d'avoir des encours maîtrisés.

‍

Le DBR enseigne que les processus doivent appliquer une cadence basée sur le processus le plus lent pour éviter la congestion [Cox 2010]. Le système cadencé présenté ci-dessus devrait donc être aligné sur le processus n°2.

Impact sur la maturité des tests

La partie DBR du cahier des charges stipule que les étapes du processus en amont d'un goulot d'étranglement doivent être alignées sur la partie la plus lente du processus. Par conséquent, si les tests sont effectués à la fin, le processus d'idéation (développement inclus) doit attendre la fin des tests avec une "corde" pour déclencher l'arrivée de nouveaux besoins dans le sprint. Si la corde n'est pas située après les tests, les activités en amont vont inévitablement congestionner les tests et le WIP. Le diagramme ci-dessous montre la configuration DBR pour une équipe Scrum avec des tests après le développement et des cordes appropriées :

• les tampons au niveau du Backlog de produit (PB), du Backlog de sprint (SB) et des tests.
• cadence fixée au niveau de la planification du sprint - il pourrait également y avoir une sous-cadence au niveau du développement pour le sprint quotidien, mais cela ne cadence pas les processus, à moins que vous ne fassiez du Scrum en saveur #noestimate [Jeffries 2013] [Ageling 2018].
• la corde doit être placée entre : 

           o PB et SB - la quantité de besoins insérés dans le PB ne doit pas dépasser un maximum grâce aux 5S sur le Backlog effectués régulièrement dans le PB.

            o Test et SB - le SB devrait réguler les éléments à lancer une fois que les éléments sont "faits"(Definition of Ready (DoR) peut également être utilisé pour réguler le flux sur le SB)

‍

Pour améliorer votre flux, il convient d'utiliser des techniques de Lean Management telles que la cartographie de la chaîne de valeur (VSM) [Poppendieck 2006] et d'autres techniques agiles/DevOps pour repérer les opportunités d'amélioration. Par exemple, pour rendre les tests plus compatibles avec le flux, nous devons introduire certaines techniques DevOps :

• Le développement et les tests sont fusionnés
• Des options de fonctionnalité sont ajoutées aux histoires d'utilisateurs (US) pour le lancement de la version sombre ou canari.
• Lorsque US fournit une fonctionnalité minimale commercialisable (MMF) qui a été testée de bout en bout dès que possible en mode Shift Left et Shift Right, les drapeaux à bascule sont activés et la version est maintenant visible pour les utilisateurs finaux (ou une partie d'entre eux).
• La surveillance du système livré devrait également être introduite pour obtenir un certain retour d'expérience des ressources, du domaine et de l'entreprise et repérer les problèmes avec des mécanismes d'alerte tels que celui décrit dans le SRE de Google [Beyer 2016].

‍

Le cahier des charges fait en fait partie d'un ensemble de pratiques plus large, appelé PanTesting, qui vise à développer les tests agiles.

Le point de vue d'Agilitest sur cette pratique

Même si le scriptage de scénarios de test avec Agilitest est plutôt léger puisque l'outil est basé sur le #nocode [Forsyth 2021], l'automatisation des scripts est un point à soigner en termes de flux.

Les organisations traditionnelles de type "waterfall" délèguent l'automatisation à la fin du SDLC, ce qui entrave le flux de livraison. L'introduction de techniques Lean/agile/DevOps devrait améliorer votre délai de mise sur le marché et le rendement du premier passage qui l'accompagne.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.