Klik op een omslag om naar Google Boeken te gaan.
Bezig met laden... Kanban: Successful Evolutionary Change for Your Technology Businessdoor David J. Anderson
Geen Bezig met laden...
Meld je aan bij LibraryThing om erachter te komen of je dit boek goed zult vinden. Op dit moment geen Discussie gesprekken over dit boek. This book is very easy to read, and focuses on kanban (Japanense visual pull system), and Kanban (Davids Organisational Change Management Strategy). David does a great job of explaining the theory behind and practical advice on implementing all of the techniques that go with Kanban. His experience with this stuff is throughout the book and these examples help to explain the topics under discussion. I took a lot of value out the discussion around flow, limiting WIP, bottlenecks, and the history of Kanban. While I do not think that I would apply Kanban to teams/departments that build large features; I would certainly use it for maintenance/small feature teams. Either way the knowledge around flow, etc is very valuable. geen besprekingen | voeg een bespreking toe
Kanban ist eine neue Change-Management-Methode, um in IT-Organisationen kleinschrittige Veränderungen mit hoher Akzeptanz aller Beteiligten durchzuführen. Durch einfache Mittel wie Visualisierung und Limitierung parallel bearbeiteter Aufgaben werden Probleme und Engpässe schnell sichtbar und können Schritt für Schritt angegangen werden. Die wachsende Anzahl von Kanban-Teams auf der ganzen Welt deutet darauf hin, dass sich durch Kanban nicht nur der bestehende Prozess immer weiter verbessert, sondern dass sich auch eine Firmenkultur entwickelt, die durch Vertrauen und gegenseitigen Respekt gekennzeichnet ist. In diesem Buch beschreibt David J. Anderson, wie er Kanban 2004 als Manager bei Microsoft entwickelt hat und welche Erfahrungen er seitdem mit Teams auf der ganzen Welt sammeln konnte. Es werden nicht nur die Grundlagen von Kanban (Pull-Systeme, WIP-Limits, Kanban-Boards, Tickets, Kaizen) vermittelt, sondern auch fortgeschrittene Konzepte wie zweistufige Kanban-Boards, der Umgang mit Engpässen sowie verschiedene Arten von Variabilität. Abgerundet wird das Buch durch einen Erfahrungsbericht von Markus Andrezak, in dem er schildert, wie die mobile.international GmbH ihr Portfoliomanagement mit Kanban organisiert. Geen bibliotheekbeschrijvingen gevonden. |
Actuele discussiesGeenPopulaire omslagen
Google Books — Bezig met laden... GenresDewey Decimale Classificatie (DDC)005.133Information Computing and Information Computer programming, programs, data, security Programming Languages General Programming LanguagesLC-classificatieWaarderingGemiddelde:
Ben jij dit?Word een LibraryThing Auteur. |
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. ( )