Kanban et Scrum - tirer le meilleur des deux

Préfacé par Mary Poppendieck et David Anderson

Date de publication : 06/05/2010 , Date de mise à jour : 21/05/2010

Par Henrik Kniberg (autres ressources)
 Mattias Skarin
 Claude Aubry - traduction (Home)
 Frédéric Faure - traduction
 Antoine Vernois - traduction
 Fabrice Aimetti - traduction
 

Ce livre fait partie de la collection de livres InfoQ "Enterprise Software Development".
Avec ce livre, vous apprendrez ce qu'est Kanban, ses forces et ses limites, et quand l'utiliser. Vous apprendrez également comment Kanban peut améliorer Scrum, ou tout autre outil que vous utilisez, et à quel moment c'est possible. Henrik montre clairement que le plus important n'est pas l'outil avec lequel on commence, mais la façon dont on améliore constamment son utilisation et comment on développe progressivement son ensemble d'outils.

Mary Poppendieck, auteur de plusieurs livres de référence sur le Lean Software Development.
Je suis très heureux qu'Henrik Kniberg et Mattias Skarin aient émergé comme des leaders dans ce domaine. Vous, les praticiens, avez besoin d'informations afin de prendre des décisions éclairées et d'avancer dans votre travail. Henrik et Mattias sont au service de vos besoins, et d'une manière que je n'aurais jamais pu mettre en oeuvre. Je suis particulièrement impressionné par l'approche réfléchie d'Henrik en matière de comparaison et de livrable factuel et neutre. Ses dessins et illustrations sont particulièrement perspicaces et vous permettent souvent d'économiser beaucoup de temps de lecture. L'étude de cas faite sur le terrain par Mattias est importante car elle démontre que Kanban est beaucoup plus qu'une théorie : il vous montre par l'exemple comment Kanban pourrait vous être utile dans votre organisation.

David Anderson, fondateur de l'Agile Project Leadership Network, membre fondateur de Feature Driven Development (FDD), et auteur de livres sur l'agilité.
Cette traduction de l'édition originale que vous pouvez trouver sur la page de l'ouvrage sur InfoQ (tout comme les autres traductions) a été faite bénévolement par les traducteurs français, et Henrik Kniberg, Mattias Skarin, et InfoQ en ont autorisé la publication.
Henrik Kniberg, Mattias Skarin
Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites      


Copyright
Copyright initial
Glossaire
Glossaire
Preface
Préfaces
Préface de Mary Poppendieck
Préface de David Anderson
Introduction
1. Introduction
1ère Partie - Comparaison
2. 1ère Partie - Comparaison
2.1. Que sont Scrum et Kanban ?
2.1.1. Scrum en bref
2.1.2. Kanban en bref
2.2. Quels sont les liens entre Scrum et Kanban ?
2.2.1. Scrum et Kanban sont tous les deux des outils de processus
2.2.2. Comparer les outils pour mieux les comprendre et non pour les juger
2.2.3. Aucun outil n'est complet, aucun outil n'est parfait
2.2.4. Scrum est plus normatif que Kanban
2.2.5. Ne vous limitez pas à l'emploi d'un seul outil !
2.3. Scrum impose des rôles
2.4. Scrum impose des itérations de durée fixe
2.5. Kanban limite le TAF à chaque étape du workflow, Scrum limite le TAF à chaque itération
2.6. Les deux sont empiriques
2.7. Scrum autorise peu de changement dans une itération
2.8. Le tableau Scrum est réinitialisé à chaque début d'itération
2.9. Scrum impose des équipes multidisciplinaires
2.10. Les éléments du backlog Scrum doivent tenir dans un sprint
2.11. Scrum impose estimation et vélocité
2.12. Les deux permettent de travailler sur plusieurs produits simultanément
2.13. Les deux sont Lean et Agile
2.14. Des différences mineures
2.14.1. Scrum recommande un backlog produitpriorisé
2.14.2. Scrum impose des points quotidiens
2.14.3. Scrum recommande des burndown charts
2.15. Tableau Scrum vs Tableau Kanban - un exemple moins trivial
2.15.1. Flux à une pièce
2.15.2. Un jour au pays de Kanban
2.15.3. Est-ce que le tableau Kanban doit ressembler à ça ?
2.16. Résumé Scrum vs Kanban
2.16.1. Ressemblances
2.16.2. Différences
2ème Partie - Étude de cas
3. 2ème Partie - Étude de cas
3.1. Le métier d'exploitant
3.2. Pourquoi diable changer ?
3.3. Par où commencer ?
3.3.1. Vision de l'exploitation par les développeurs
3.3.2. Vision du développement par l'exploitation
3.3.3. Pour s'y mettre
3.4. Mise en ordre de marche des équipe
3.4.1. L'atelier
3.5. Impliquer les parties prenante
3.6. Construire le premier tableau
3.6.1. Le premier modèle Kanban
3.6.2. Lignes utilisées
3.6.3. Colonnes utilisées
3.7. Fixer une limite de TAF la première fois
3.8. Respecter la limite de TA
3.8.1. En discuter devant le tableau
3.8.2. Créer une colonne Débordement
3.9. Quelles tâches afficher sur le tableau ?
3.10. Comment estimer ?
3.10.1. Que représente la taille estimée ? Le temps de cycle ou le temps de travail ?
3.11. Alors, comment avons-nous travaillé, concrètement ?
3.11.1. Le point quotidien
3.11.2. La planification d'itération
3.12. Trouver un concept de planification qui fonctionne
3.12.1. Une histoire
3.12.2. Réinventer la planification
3.12.3. Approche 1 - Echanger et revoir
3.12.4. Approche 2 - Revue de haut niveau puis estimationestimat
3.13. Quoi mesurer
3.14. Comment les choses ont commencé à changer
3.14. Leçons apprises
3.14.1. Des contraintes émergent lorsque le travail à faire diminue
3.14.2. Le tableau va changer en cours de route, ne figez pas sa conception
3.14.3. N'ayez pas peur d'expérimenter et d'échouer
Points à retenir
4. Points à retenir
4.1. Commencez par des rétrospectives !
4.2. N'arrêtez jamais d'expérimenter !
Les auteurs et traducteurs
5. Les auteurs
5.1. Henrik Kniberg
5.2. Mattias Skarin
6. Les Traducteurs
6.1. Claude Aubry
6.2. Frédéric Faure
6.3. Antoine Vernois
6.4. Fabrice Aimetti


Valid XHTML 1.0 TransitionalValid CSS!

Copyright © 2010 Henrik Kniberg et Mattias Skarin. La copie, modification et/ou distribution par quelque moyen que ce soit, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur.
 
 
 
 
Partenaires

Hébergement Web