2. Il y a peut-être un million de méthodes et
même un peu plus, mais quant aux principes,
ils sont en nombre limité.
L’homme qui maîtrise les principes pourra
avec succès choisir ses propres méthodes.
L’homme qui essaye des méthodes, ignorant
les principes, est condamné à avoir des
problèmes.
- RALPH WALDO EMERSON
4. La théorie des contraintes
• Le but de toute activité est de
faire du profit, maintenant et
durablement
• La Théorie des Contraintes est
une philosophie de
management qui se concentre
sur les performances des
contraintes, souvent des
ressources limitées, pour
améliorer la performance
globale du système
4
5. Optimum local et optimum global
“
Un système d’optimum locaux n’est
pas du tout un système optimum.
- Eliyahu M. Goldratt
5
6. Contrainte
• Tout système subit au moins une
contrainte, sans quoi il serait en
mesure d'atteindre indéfiniment des
performances élevées.
• Tout comme la solidité de la chaîne
est celle de son maillon le plus
faible, la performance globale d'un
système ne peut excéder la
performance de sa contrainte.
6
7. Le goulot d’étranglement
Le goulot
Backlog Code Déploiement
Toute perte de temps sur un goulot est une perte pour tout le système.
Tout gain de temps sur un non-goulot est un leurre.
7
8. 5 étapes de la TOC
1. Identifier la contrainte
2. Exploiter la contrainte
3. Subordonner toutes les décisions
par rapport à la contrainte
4. Elever la contrainte
5. Répéter à la nouvelle contrainte
8
9. Le but
Améliorer le throughput
Le rythme auquel le système
Throughput
génère de l’argent à partir des
Stock
vente.
Diminuer les stocks
Dépense Tout l’argent que le système à
opérationnelle investit en achetant des choses qu’il
à l’intention de vendre.
Diminuer les dépenses
opérationnelles
Tout l’argent que le système
dépense dans le but de transformer
Business model les stock en throughput.
9
11. One piece flow
Tirer une requête de
travail individuelle à
travers une séquence
d’activités ajoutant de
la valeur rapidement
et sans interruption.
Plutôt que :
Faire avancer des
batchs de travail au
sein des différentes
étapes du workflow.
11
13. Pull vs Push
• Ne pas réaliser une fonctionnalité dont personne n’a
besoin maintenant
• Ne pas écrire trop de spécifications par rapport à ce
que l’on peut développer
• Ne pas écrire trop de code par rapport à ce que l’on
tester
• Ne pas développer plus par rapport à ce que l’on peut
déployer
13
16. Kanban
Kanban repose sur 5 pratiques:
• Visualiser le travail
• Limiter le Work In Progess
• Rendre les règles explicites
• Mesurer et manager le flot
• Identifier les opportunités d’amélioration
16
18. Simulation de Kanban
S16
Design
Dev
Test
Jour Sortie Jour Temps de
d’entrée cycle
- 9 =
I2 (Refactor du module core)
Design
Dev
Test
Jour Sortie Jour Temps de
d’entrée
- 8 = cycle
Inspiré par www.getkanban.com 18
19. Limiter le Work In Progress
Diminuer le WIP permet de faire émerger les problèmes qui était cachés.
19
21. Identifier les opportunités d’amélioration
Le client Le client
demande reçoit un
un service service
Lead time
"All we are doing is looking at the time
line, from the moment the customer gives
us an order to the point when we collect
the cash. And we are reducing the time
line by reducing the non-value adding
wastes.“
Taiichi Ohno
21
25. Le contexte est important, donc…
Kanban vous permet de concevoir un
processus qui s’adapte au contexte, au lieu
de manipuler le contexte pour qu’il s’adapte
à un processus spécifique
26. Commencer avec Kanban
• Commencer par ce que vous faites maintenant
• Modifier légèrement pour passer en mode Pull
• Utiliser une méthode transparente pour
visualiser le travail et organiser l’équipe
• Limiter le WIP
• Avancer en reconnaissant les goulets
d’étranglement les gaspillages qui affectent la
performance
26
27. Références
La référence par David Anderson Gratuit sur InfoQ
http://www.infoq.com/minibooks/priming-kanban-jesper-boeg
27
The Lean goal of pulling individual work requests through asequence of value adding activities, quickly and withoutinterruption.as opposed toMoving batches of work between stages in a workflow.
Don’t build features that nobody needs right nowDon’t write more specs than you can codeDon’t write more code than you can testDon’t test more code than you can deploy