More Related Content
Similar to Présentation kanban
Similar to Présentation kanban (20)
More from Mathieu Gandin (8)
Présentation kanban
- 2. AGENDA
Motivations
Mise en place
Amélioration continue
© OCTO 2011 2
- 3. Objectifs
Construire un objectif commun pour toutes l’équipe
Sur quoi on pourra mesurer le succès de tout le projet
Construire et piloter un flux de valeur en commun
Définir un point permettant de partager sur
Ce que l’équipe a fait depuis le dernier point
Ce que l’équipe prévoit de faire jusqu’au prochain point
Identifier les problèmes qui peuvent freiner l’équipe
Résoudre des problèmes
© OCTO 2011 3
- 4. Construire un flux de valeur en commun
Identifier toutes les étapes nécessaires pour délivrer une idée
sous la forme d’un produit logiciel
Partager et piloter ce flux avec du management visuel par le
biais d’un Kanban
© OCTO 2011 4
- 5. Kanban
Historiquement développé par Taiichi Ohno à partir des années
1950 au sein des ateliers de Toyota, dans le cadre plus large du
Lean pour le pilotage de la production par l’aval (en flux tiré)
Depuis Kanban est une approche Lean du développement
logiciel, dans le domaine IT
D’autres approches du développement intégraient déjà les
principes Lean (Scrum, …)
Mais en 2004, David Anderson, pionnier sur le sujet, a mis en
place un approche plus directe inspirée de la TOC et du Lean
Avec l’appui d’experts comme Don Reinertsen, il a abouti au
« Kanban (pour le développement logiciel) »
Cf : http://www.crisp.se/kanban
« Kanban – Successfull evolutionary change for your technology business » David Anderson
© OCTO 2011 5
- 6. Principes généraux du Kanban
Visualiser le flux
Découper le travail à faire en tâches
Écrire ces tâches sur des cartes et les afficher au mur
Utiliser des colonnes nommées pour indiquer où se trouvent les tâches
au sein du flux
Limiter l’encours (WIP – Work in Progress)
Définir des limites précises et explicites sur le nombre de tâches qui
peuvent être traitées en même temps
Mesurer le temps de cycle (Lead Time)
Temps de cycle = Temps moyen pour traiter une tâche
Optimiser le processus pour minimiser le temps de cycle et le rendre le
plus prédictif possible
© OCTO 2011 6
- 7. Le Kanban permet de Piloter le flux de valeur
Théorie de la contrainte
Où est le goulot d’étranglement ?
Soulager le goulot de ses tâches non-productives
Subordonner le reste du système au goulot
Améliorer le goulot
Et recommencer …
Pour identifier le goulot d’étranglement on va utiliser les
informations disponibles par le Kanban
© OCTO 2011 7
- 8. AGENDA
Motivation
Mise en place
Amélioration continue
© OCTO 2011 8
- 10. Visualiser l'ensemble des tâches à réaliser pour finir
le produit logiciel
Marketing MOA Design User Dev Recette
Story
Note de cadrage US 98 US 90
Spécification StoryBoard US
consulter YYY Feature AAA Ecran EEE 113
US US US 95
Spécification StoryBoard
Ecran FFF 110 100
Feature BBB
US US 91
Spécification StoryBoard 102
Feature CCC Ecran GGG
US US 93
Spécification
Feature DDD 104
Bug [XXX]
Bug [ZZZ]
© OCTO 2011 10
- 11. Lisser l'activité
Marketing MOA Design User Dev Recette
Story
Note de cadrage US 98 US 90
Spécification StoryBoard US
consulter YYY Feature AAA Ecran EEE 113
US US US 95
Spécification StoryBoard
Ecran FFF 110 100
Feature BBB
US US 91
Spécification
Limite = 2 Feature CCC
StoryBoard 102
Ecran GGG
US US 93
Spécification
Feature DDD Limite = 3 Limite = 3 104
Bug [XXX]
Bug [ZZZ]
Limite = 4
Limite = 4
Limite = 5
© OCTO 2011 11
- 12. Traiter les goulet d'étranglement
Marketing MOA Design User Dev Recette
Story
Note de cadrage US 98 US 90
Spécification StoryBoard US
consulter YYY Feature AAA Ecran EEE 113
Spécification
Feature BBB
Spécification
Limite = 2 Feature CCC
Spécification
Feature DDD Limite = 3 Limite = 3
Bug [XXX]
Bug [ZZZ]
Limite = 4
Limite = 4
Limite = 5
© OCTO 2011 12
- 13. Définition du "Fini Fini" pour chaque activité
DoD
•Faire relire le code par un
développeur qui n’a pas
travailler sur la User Story
•Tous les Tests unitaires sont
au vert
•Faire valider
fonctionnellement la User
Story par le PO
•Déployer en environnement
de tests
© OCTO 2011 13
- 14. Mettre en place un bac rouge
A côté des colonnes du Kanban on dispose une feuille et on
marque bac rouge dessus
Lorsqu’une User Story revient en arrière dans le Kanban, à
cause d’une anomalie ou d’un problème technique, on la
recopie dans lebac rouge
Lors de chaque rétrospective l’équipe analyse les user story qui
se retrouve dans le bac rouge pour comprendre les problèmes
qu’il y a derrière
© OCTO 2011 14
- 15. Piloter le flux de valeur
Cumulative Flow Chart
250
200
INPUT QUEUE
STUDY DEV - WIP
STUDY DEV - DONE
150
number of items
VALIDATION - TODO
VALIDATION - WIP
DONE - WAIT JAVA
LT: < 2 sem
DONE - WIP JAVA
100
En cours : 15 tickets DONE - IN CI
DONE - DONE
CANCELLED
50
Lead Time : 6
En cours : 30 tickets
0
09/0…
11/0…
13/0…
17/0…
19/0…
23/0…
25/0…
27/0…
31/0…
02/0…
06/0…
08/0…
10/0…
14/0…
16/0…
20/0…
22/0…
24/0…
28/0…
30/0…
04/1…
06/1…
08/1…
12/1…
14/1…
18/1…
20/1…
21/1…
25/1…
27/1…
29/1…
time
© OCTO 2011 15
- 16. Principes
N’y mettre que des User Story
Elles doivent être suffisamment petites et priorisées
Chaque colonne du Kanban doit avoir une définition du fini-fini
Mettre en place un bac rouge
Etendre les colonnes
© OCTO 2011 16
- 18. AGENDA
Motivation
Mise en place
Amélioration continue
© OCTO 2011 18
- 20. Amélioration continue
•Identifier le problème
•Créer un nouveau standard
•Analyser les facteurs
•Former
•Faire une prédiction
Act Plan •Etablir un indicateur
•Vérifier la prédiction
Check Do •Mettre en œuvre l’amélioration
•Confirmer ou abandonner •Analyser les effets indésirables
•corriger la mise en œuvre
l’amélioration
© OCTO 2011 20