Voir la source de La théorie des contraintes dans l'Agilité

[[Category: Théorie des Contraintes]]
[[Category: Eli Goldratt]]
Auteur : Leon Tranter (Extreme Uncertainty )<br />
Source : [https://www.extremeuncertainty.com/theory-constraints-agile/ Theory of constraints in Agile]<br />
Date : 16/03/2021<br/>
----
Traducteur : Fabrice Aimetti<br />
Date : 28/04/2011<br />
----
Traduction :<br />
<br />
[[Fichier:Constraints.jpg|left|border|150px]][[Fichier:Theory-of-constraints.jpg|border|right|150px]]Un concept de la théorie du management intitulé [https://fr.wikipedia.org/wiki/Th%C3%A9orie_des_contraintes La théorie des contraintes] est devenu populaire dans les cercles Agile et Lean. La théorie est assez simple, et se rapporte aux contraintes ou goulots d'étranglement présents dans tout processus (que ce soit dans le domaine de la fabrication ou de l'ingénierie des connaissances). Cet article vise à expliquer la théorie des contraintes et comment elle se relie au développement logiciel agile, dans un contexte micro et macro.<br/>
==Qu'est-ce que la Théorie des Contraintes ?==
Les principes de la Théorie des Contraintes ont été établis par un chercheur israélien nommé Eli Goldratt, dans les années 1980. Ces principes ont été popularisés par son excellent livre [https://www.amazon.com/gp/product/B00IFGGDA2 Le But] (que je recommande vivement et qui est considéré comme un ouvrage de référence dans le domaine de la Pensée Lean), et ont eu une forte influence sur le célèbre ouvrage récemment publié [https://www.amazon.com/gp/product/1942788290 Le Projet Phoenix], un livre classique dans la communauté Agile et DevOps.<br/>
<br/>
La théorie elle-même est la suivante. Dans tout système considéré, il y a un composant qui constitue la contrainte ou le goulot d'étranglement du système, en termes de limitation de la production de ce système. Toute tentative d'optimisation d'une partie du système autre que la contrainte est un gaspillage d'efforts, car elle n'améliorera pas le débit du système.<br/>
<br/>
Tous les efforts de l'organisation doivent viser à améliorer cette contrainte. Ce processus doit se poursuivre jusqu'à ce que la contrainte disparaisse. À ce stade, le prochain maillon le plus faible de la chaîne devient la contrainte, et doit être optimisé.<br/>
<br/>
===Les cinq étapes dites de "focalisation" de la théorie des contraintes===
Ces étapes sont plus formellement décrites comme les cinq étapes de focalisation :
* '''Identifier''' : chercher à identifier la contrainte actuelle du système, c'est-à-dire l'élément du processus qui limite le rythme pour lequel l'objectif d'optimisation du système est satisfait.
* '''Exploiter''' : aller améliorer rapidement le débit de cette contrainte, en utilisant toutes les ressources disponibles (même si ces ressources sont déjà utilisées).
* '''Subordonner''' : examiner toutes les autres parties du processus pour s'assurer qu'elles sont alignées sur les besoins de la contrainte et qu'elles y répondent véritablement.
* '''Élever''' : si la contrainte existe toujours (c'est-à-dire qu'elle constitue toujours le goulot d'étranglement global pour l'amélioration de l'objectif d'optimisation du système), examiner quelles autres actions peuvent être entreprises pour éliminer la contrainte. Les actions ci-dessus sont poursuivies jusqu'à ce que la contrainte ait été "levée", c'est-à-dire qu'elle n'est plus la contrainte, et qu'une autre partie du système soit devenue la contrainte. Dans certains cas, un investissement en capital peut être nécessaire.
* '''Répéter''' : les cinq étapes de focalisation sont un processus d'amélioration continue.  Par conséquent, une fois qu'une contrainte est résolue et qu'elle n'est plus une contrainte, la prochaine partie du système qui est devenue une contrainte doit être traitée, en suivant les étapes précédentes.
Cette dernière étape est un petit encouragement à ne jamais se laisser aller à la satisfaction. Chaque système a une contrainte, sinon le système produirait un résultat infini. Donc, continuez à vous occuper des contraintes !<br/>
<br/>
==Les applications de la Théorie des Contraintes==
Cette idée pleine de bon sens est devenue populaire dans les cercles de management avec la publication du livre [https://www.amazon.com/gp/product/0884271951 Le But] d'Eli Goldratt sur la Théorie des Contraintes en 1984. Ses applications dans les cercles Lean et Agile se situent généralement à un niveau que je considère comme "micro". Je veux dire en faisant des choses comme la mise en place de limites de WIP (Work In Progress) sur un tableau de management visuel / Kanban. Les limites d'encours sont en fait un vieux concept Kanban qui a été développé indépendamment de la Théorie des Contraintes.<br/>
<br/>
Il existe cependant d'autres utilisations de la Théorie des Contraintes.<br/>
<br/>
L'une d'entre elles est le risque lié à la personne-clé (NdT : Key Man Risk). Une contrainte n'est pas nécessairement un système, un composant ou un processus. Il peut s'agir d'une personne. Si une personne particulière joue un rôle crucial dans un processus, le travail ne peut pas avancer dans le système plus rapidement que cette personne ne peut traiter le travail. Il y a aussi la menace d'une interruption complète du système si cette personne part ou déménage. Soyez très vigilant à l'égard de la "personne unique qui sait tout et à qui nous nous adressons toujours lorsque nous avons vraiment besoin de faire quelque chose". Cette personne n'est pas un héros, elle constitue un handicap.<br/>
<br/>
Une autre contrainte peut être une équipe ou un processus qui peut bloquer le travail. Par exemple, une équipe qui doit vérifier ou autoriser le travail : la gestion des versions, la vérification des activités ou les tests de sécurité en sont des exemples courants. Ces équipes et processus peuvent limiter le flux de travail.<br/>
<br/>
La meilleure solution consiste à faire des équipes des "équipes produit" ou des "équipes features" totalement pluridisciplinaires, capables d'effectuer tout le travail nécessaire à la mise en production du logiciel.<br/>
<br/>
J'en ai parlé beaucoup plus longuement dans mon article sur les [https://www.extremeuncertainty.com/what-does-cross-functional-agile-team-look-like/ équipes pluridisciplinaires en Agilité].<br/>
<br/>
==La Théorie des Contraintes en Agilité à un niveau macro==
Une autre conséquence de la Théorie des Contraintes se situe à un niveau beaucoup plus large. De nombreuses organisations adoptant la méthode Agile constatent que l'Informatique évolue rapidement, mais que "le Métier" est beaucoup plus lent à suivre. Étrangement, la plupart des activités de coaching et de soutien au cours d'une adoption Agile sont axées sur l'amélioration et l'optimisation de l'Agilité pour le domaine Informatique, plutôt que sur les capacités du Métier.<br/>
<br/>
Ceci est en contradiction avec la théorie des contraintes. Améliorez la partie de votre organisation qui a le plus besoin d'être améliorée. Cela peut être votre processus de planification de votre portefeuille, votre processus de gestion du changement, votre processus de marketing et de communication, ou autre chose encore.<br/>
<br/>
Il est évidemment inutile d'améliorer de 10 % l'efficacité de votre capacité de production informatique s'il faut six mois pour faire approuver une étude de faisabilité et réaliser le travail. Améliorez d'abord la contrainte la plus forte !<br/>
<br/>
==La théorie des contraintes au niveau de l'entreprise==
Il existe un niveau encore plus élevé auquel vous pouvez appliquer la Théorie des Contraintes. Il s'agit des indicateurs d'entreprise. Le langage de schémas XSCALE recommande d'analyser en permanence votre activité à travers le prisme des "mesures pirates" : Acquisition, Activation, Rétention, Revenu, Recommandation. À tout moment, l'une de ces mesures sera le goulot d'étranglement de votre organisation. Vous n'avez peut-être pas activé de clients. Peut-être que personne n'a entendu parler de vous. Vous avez peut-être un million de prospects mais aucune vente. Peut-être que vous vendez mais que tout le monde se lasse de votre produit et l'abandonne au bout d'un mois. La mesure qui constitue votre goulot d'étranglement peut et va changer au fil du temps. Vous devez la mesurer non pas une fois, mais constamment.<br/>
<br/>
Vous devez vous concentrer sur la mesure qui constitue votre goulot d'étranglement et la corriger. Jusqu'à ce qu'elle ne le soit plus et qu'une autre mesure le soit. Puis le processus recommence. Le fait d'identifier, d'exploiter et de s'attaquer continuellement aux goulets d'étranglement maximisera le débit au fil du temps et constitue le moyen le plus rapide d'atteindre une croissance exponentielle.