« La théorie des contraintes dans l'Agilité » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 26 : | Ligne 26 : | ||
* '''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. | * '''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/> | 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/> | <br/> | ||
