David J. Anderson (1) (1939–)
Auteur de Kanban: Successful Evolutionary Change for Your Technology Business
Pour les autres auteurs qui s'appellent David J. Anderson, voyez la page de désambigüisation.
A propos de l'auteur
David J. Anderson has been in the software business for more than 20 years
Œuvres de David J. Anderson
Étiqueté
Partage des connaissances
- Nom légal
- Anderson, David James
- Date de naissance
- 1939
- Sexe
- male
Membres
Critiques
Vous aimerez peut-être aussi
Statistiques
- Œuvres
- 6
- Membres
- 328
- Popularité
- #72,311
- Évaluation
- 3.7
- Critiques
- 3
- ISBN
- 27
- Langues
- 4
Kanban for software development descends from the broader lean traditions that have been gaining greater prominence in the world of agile software. Lean in general, and Kanban in particular, focuses on the idea that there is not one best process that works for all teams. As such, Kanban is not a software development methodology -- it is a change management methodology. The tools of Kanban help teams figure out how they can customize their processes to improve their performance. Kanban flips the question from "How can we get more done?" to "What is blocking our ability to get more done?"
At the heart of Kanban (although not sufficient on its own) is work in progress limits. Limiting the work in progress to get more done may seem counterintuitive. The value of these limits flow from the assumption that the gains to be had from improving the process are greater than the productivity lost by not having everyone fully loaded all of the time. This plays out in several ways.
First, limiting the work in progress forces teams to acknowledge the parts of their process that are bottlenecks. Without strict limits, the parts of the process that are not bottlenecks can keep taking on more and more work, causing it to pile up once it gets to the bottleneck. With strict limits, the problems become obvious.
Limiting the work in progress forces teams to deal with blocked work items. Without strict limits, it is easy to let blockers delay the completion of a task for a long time. First, the part of the team not responsible for the task is not motivated to deal with the blocker because they can just ignore it. Second, the task owner may also not deal with the block as quickly as they might otherwise because they have other tasks to work on. When the work in progress is limited, blocks have to be addressed.
Limiting the work in progress optimizes for latency over throughput. Many teams aim to get tasks done as quickly as possible. In practice, urgent (but not necessarily more important) items tend to jump into the work queue as soon as they come up, and people juggle multiple projects. Limiting the work in progress forces a conversation about priorities: Do we have to take on this task right away, or can it be on the top of our list of things to tackle next? If we have to work on it right away and we're already working at our limit, what can we drop? (Note that this sort of dropping is already common at an individual level. However, it's not necessarily communicated to the team or the external stakeholders which leads to mismatched expectations about when work will get done.)
Finally, limiting parallel work decreases task switching overhead, both at the individual and team level. At the individual level, too much parallelism can make people feel overwhelmed. "Too much" varies from person to person, but everyone has a limit. At the team level, too much parallelism fragments knowledge and/or leads to higher communication overhead since people have to share a larger amount of context whenever they solicit input from someone working an unrelated task.
Of course, just limiting the work in progress on its own does not make things better. The bulk of Anderson's book describes other concepts needed to effectively monitor and improve a development process. A mature Kanban system has a lot of pieces -- pieces that can make it look a lot like a development process -- but the key to remember is that these mature systems developed by adding and tweaking and removing process as it was shown to be needed by the problems they had in practice. While teams with a mature process derived using Kanban may have some similar best practices, part of the power of this system is making sure that those practices evolved based on the needs of the team. These practices shouldn't be adopted without thought -- and if they are, they'll likely fail.… (plus d'informations)