Actions du vent sur les bâtiments selon lEurocode 1 – Partie 1-4.pdf
Kanban vs Scrum (slides)
1. Traduit par Fabrice Aimetti le 30/05/2009
19 Mai 2009
Guide pratique
Henrik Kniberg – Crisp AB
Coach Agile & Java Guy
Cofondateur / CTO de Goyada (services mobiles)
30 développeurs
Lead architect chez Ace Interactive (jeux)
20 développeurs
Responsable du développement chez Tain (jeux)
40 développeurs
Coach Agile dans différentes
entreprises
2. 2Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Introduction
But de cette présentation :
Clarifier Kanban et Scrum en les comparant
... afin que vous puissiez comprendre comment vous
pouvez être amené à les utiliser dans votre
environnement.
3. 3Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Scrum en bref
Divisez votre organisation
Divisez votre produit
Grand groupe passant beaucoup de temps à construire un gros truc
Petite équipe passant un peu de temps à construire de petites choses
... mais intégrant régulièrement pour voir l'ensemble
Optimisez la valeur métier
Optimisez les processus
Divisez le temps
Janvier Avril
4. 4Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Kanban en bref
Visualisez le workflow
Limitez le WIP (l’encours)
Mesurez & optimisez le flux
5. 5Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Racines de Kanban
(Toyota)
Taiichi Ohno
Père du Système de Production Toyota
Les deux piliers du Système de Production Toyota
sont le juste-à-temps et l'automatisation avec une
touche humaine, ou autonomation.
L'outil utilisé pour faire fonctionner le système est
kanban.
7. 7Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Kanban et Scrum sont deux outils processus
Outils physiques Outils procesus
alias « patterns d’organisation »
8. 8Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Prescriptif vs adaptatif
Prescriptif Adaptatif
Miyamoto Musashi
Samouraï du 17ème
siècle
Ne développez pas un attachement
à une arme
ou une école de combat
10. 10Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Scrum prescrit des itérations
Equipe Scrum
Equipe Kanban 1
Equipe Kanban 2
Equipe Kanban 3
11. 11Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Les deux limitent le WIP, mais d’une manière
différente
Tableau Scrum Tableau Kanban
WIP limité par unité de
temps (itération)
WIP limité par état dans le
workflow
12. 12Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Les deux sont empiriques
Kanban est plus configurable
Super, beaucoup plus
de choix !
Oh non, c’est plus
compliqué !
13. 13Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Exemple : testez avec des limites WIP
Lundi, Semaine 1 Lundi, Semaine 2 Lundi, Semaine 3 Lundi, Semaine 4
Lundi, Semaine 5
14. 14Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Scrum n’autorise pas le changement
en milieu d’itération
15. 15Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Le tableau Scrum est réinitialisé à chaque
nouvel itération
Scrum
1er jour du sprint A mi-sprint Dernier jour du sprint
Kanban
Tous les jours
16. 16Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Scrum prescrit des équipes multidisciplinaires
Kanban – exemple 1 Kanban – exemple 2
Equipe
multidisciplinaire
Equipe
multidisciplinaire
Spécialiste
Equipe
multidisciplinaire
Equipe
spécialisée
17. 17Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Les items d’un backlog Scrum doivent tenir dans
un sprint
18. 18Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
En Scrum, estimation et vélocité sont prescrites
Vélocité probable : 8 par sprint
(rythme soutenable ?)
19. 19Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Les deux autorisent le travail sur plusieurs
produits simultanément
Kanban – exemple 1
Tâches avec un code couleur
Kanban – exemple 2
Couloir de nage avec un code couleur
20. 20Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Les deux
sont Lean
et Agile
1. Individus et Interactions
plutôt que Process et Outils
2. Un Logiciel qui fonctionne
plutôt qu’une Documentation Complète
3. La Collaboration du Client
plutôt que la Négociation du Contrat
4. Répondre au Changement
plutôt que le Suivi d’un Planning
1. Fondez vos décisions sur une philosophie à long terme, même au détriment des
objectifs financiers à court terme
2. Organisez les processus en flux continu pour mettre au jour les problèmes
3. Utilisez des systèmes « tirés » pour éviter la surproduction
4. Lissez la charge de travail (heijunka)
5. Inculquez une culture de résolution immédiate des problèmes, d’obtention de la
qualité au premier coup.
6. La standardisation des tâches est la base de l’amélioration continueet de la
responsabilisation des employés
7. Utilisez des contrôles visuels pour qu’aucun problème ne reste caché.
8. Utilisez uniquement des technologies fiables, longuement éprouvées, qui servent
vos collaborateurs et vos processus.
9. Formez des responsables qui maîtrisent parfaitement le travail, sont imprégnés
de la philosophie et l’enseignent aux autres.
10. Formez des individus et des équipes exceptionnels , qui appliquent la philosophie
de votre entreprise.
11. Respectez votre réseau de partenaires et de fournisseurs en les encourageant et
en les aidant à progresser.
12. Allez sur le terrain pour bien comprendre la situation (genchi genbutsu)
13. Décidez en prenant le temps nécessaire, par consensus, en examinant en détail
toutes les options. Appliquez rapidement les décisions.
14. Devenez une entreprise apprenante grâce à la réflexion systématique (hansei) et
à l’amélioration continue (kaizen).
21. 21Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Différence mineure : Scrum prescrit un Backlog
Produit priorisé
Scrum :
Le Backlog Produit doit
forcément exister
Les changements du Backlog
Produit prennent effet dans
le prochain sprint (pas dans
le sprint courant)
Le Backlog doit être trié
selon la valeur produit
Kanban :
Le Backlog Produit est
optionnel
Les changements du Backlog
Produit prennent effet dès
qu’il ya retour à la capacité
N’importe quel principe de
priorisation peut être utilisé :
Prendre n’importe quel item
Toujours prendre le premier
item
Toujours prendre le plus vieil
item
20% sur des items de
maintenance, 80% sur des
nouveaux items
Répartissez de façon égale la
capacité entre le produit A et le
produit B
Prenez toujours les items
urgents en premier
… mais beaucoup d’équipes combinent ces approches
22. 22Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Différence mineure :
Scrum prescrit des réunions quotidiennes
… mais beaucoup d’équipes Kanban le font de toute façon
23. 23Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Différence mineure :
En Scrum, les burndown charts sont prescrits
Pas de graphiques particuliers
prescrits en Kanban. Les équipes
utilisent ce qu’elles veulent.
24. 24Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Exemple : tableau Scrum vs tableau Kanban
Scrum
Kanban
40. 40Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Kanban vs Scrum
Ressemblances :
Les deux sont Lean et Agile
Les deux utilisent le Juste à temps
Les deux limitent le WIP
Les deux utilisent la transparence
pour piloter l'amélioration des
processus
Les deux se concentrent sur la
livraison d’un produit logiciel
rapidement et fréquemment
Les deux sont fondées sur l'auto-
organisation des équipes
Les deux requièrent de diviser le
travail en éléments
Dans les deux cas, le planning de
versions est continuellement
optimisé et basée sur des données
empiriques (vélocité / temps de
cycle)
Différences :
41. 41Henrik Kniberg
Traduit par Fabrice Aimetti le 30/05/2009
Le plus important :
commencez avec les rétrospectives !
Mettez en pratique le bon
processus adapté à votre contexte.
Ne vous préoccupez pas de faire
bien du premier coup au début.
Déployez votre boîte à outil.
Expérimentez !
