1. Formation
Présentation Kanban
Mathieu Gandin

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

9. Visualiser les activités
Marketing MOA Design User Dev Recette
Story
© OCTO 2011 9

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

17. Principes
 Limiter l’en-cours
 Plusieurs lignes
 Mesurer
 La ligne d’or
 Améliorer
© OCTO 2011 17

18. AGENDA
Motivation
Mise en place
Amélioration continue
© OCTO 2011 18

19. Keep / Drop / Start
© OCTO 2011 19

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