- Copertina flessibile: 261 pagine
- Editore: Lightning Source Inc (7 aprile 2010)
- Lingua: Inglese
- ISBN-10: 0984521402
- ISBN-13: 978-0984521401
- Peso di spedizione: 608 g
- Media recensioni: 4.2 su 5 stelle Visualizza tutte le recensioni (4 recensioni clienti)
- Posizione nella classifica Bestseller di Amazon: n. 13.611 in Libri in altre lingue (Visualizza i Top 100 nella categoria Libri in altre lingue)
Kanban (Inglese) Copertina flessibile – 7 apr 2010
|Nuovo a partire da||Usato da|
- Scegli tra gli oltre 8.500 punti di ritiro in Italia
- I clienti Prime beneficiano di consegne illimitate presso i punti di ritiro senza costi aggiuntivi
- Trova il tuo punto di ritiro preferito ed aggiungilo alla tua rubrica degli indirizzi
- Indica il punto di ritiro in cui vuoi ricevere il tuo ordine nella pagina di conferma d’ordine
Spesso comprati insieme
Chi ha acquistato questo articolo ha acquistato anche
David J. Anderson leads a management consulting firm focused on improving performance of technology companies. He has been in software development nearly 30 years and has managed teams on agile software development projects at Sprint, Motorola, Microsoft, and Corbis. David is credited with the first implementation of a kanban process for software development, in 2005. David was a founder of the Agile movement through his involvement in the creation of Feature Driven Development. He was also a founder of the Agile Project Leadership Network (APLN), a founding signatory of the Declaration of Interdependence, and a founding member of the Lean Software and Systems Consortium. He moderates several online communities for lean/agile development. He is the author of Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Most recently, David has been focused on creating a synergy of the CMMI model for organizational maturity with Agile and Lean methods through projects with Microsoft and the SEI. He is a co-author of the SEI’s Technical Note “CMMI and Agile: Why not Embrace Both!” He is based in Sequim, Washington, USA.
Non è necessario possedere un dispositivo Kindle. Scarica una delle app Kindle gratuite per iniziare a leggere i libri Kindle sul tuo smartphone, tablet e computer.
Per scaricare una app gratuita, inserisci il numero di cellulare.
Garanzia e recesso: Se vuoi restituire un prodotto entro 30 giorni dal ricevimento perché hai cambiato idea, consulta la nostra pagina d'aiuto sul Diritto di Recesso. Se hai ricevuto un prodotto difettoso o danneggiato consulta la nostra pagina d'aiuto sulla Garanzia Legale. Per informazioni specifiche sugli acquisti effettuati su Marketplace consulta… Maggiori informazioni la nostra pagina d'aiuto su Resi e rimborsi per articoli Marketplace.
Se sei un venditore per questo prodotto, desideri suggerire aggiornamenti tramite il supporto venditore?
Quali altri articoli acquistano i clienti, dopo aver visualizzato questo articolo?
Principali recensioni dei clienti
Mi dispiace per gli altri autori, ma per chi vuole fare le cose fatte bene...è questo che deve comprare e poi si deve STUDIARE......basta con questa superficialità e queste approssimazioni....bisogna studiare, studiare, studiare......quindi ben venga un libro come questo che ti porta a fare considerazioni e riflessioni anche di giorni interi. Io sul capitolo che descrive il limite al WIP ci ho passato 4 giorni.
Senza considerare che sto facendo i riassunti scritti di ogni paragrafo che mi interessa (quasi tutti).
Ripeto mi dispiace per gli altri autori: Kanban in Action, etc......tutta superficialità.......
Studiate se non volete fare casini..studiate per avere più cultura......e chi non ne ha voglia......rimanga nella sua placida ignoranza.
Un riferimento per tutti quelli che vogliono migliorare in ottica kaizen (miglioramento continuo), in tutti gli ambiti.
Le recensioni clienti più utili su Amazon.com (beta) (Potrebbero essere presenti recensioni del programma "Early Reviewer Rewards")
One major caveat, do not buy as a Kindle book. It is a terrible transfer, slips from text to text as picture. That means no conforming to display preference and no highlighting. Just buy the paper book.
I was always under the impression that Kanban was just an example of the usage of a team board. This book proved how wrong I was. Kanban is much and much more!
The book is divided into four parts with in total twenty chapters:
▪ Part I: Introduction
▪ Part II: Benefits of Kanban
▪ Part III: Implementing Kanban
▪ Part IV: Making improvements
The first part contains two chapters introducing Kanban. Kan-ban is a Japanese word that literally means “signal card” in English. Kanban is an
evolutionary change method that utilizes a kanban pull system, visualization and other tools to catalyse the introduction of lean ideas into technology development and IT operations.
The book gives the following definition: “A Kanban system is a system were a number of cards equivalent to the agreed capacity of a system are placed in circulation. One card is the equivalent of one piece of work. Each card acts as a signalling mechanism. A new piece of work can be started only when a card is available. This free card is attached to a piece of work and follows it as it flows through the system. When there are no more free cards, no additional work can be started. Any new work must wait in a queue until a card becomes available. When some work is completed, its card is detached and recycled. With a card now free, a new piece of work in the queuing can be started.” This is what you call a pull mechanism.
When there is no explicit limit to the work in progress (WIP, or the maximum number of cards at a specific process step) and there is no mechanism to show that we have to pull new work into the system, it is not a Kanban system.
Key properties of a Kanban system are:
▪ Visualize the workflow (using a kanban board);
▪ Limit work in progress;
▪ Measure and manage flow;
▪ Make progress policies explicit (e.g. the number cards/work units at a certain step);
▪ Use models to recognize improvement opportunities (e.g. ToC, system thinking, …).
The second part explains the benefits of Kanban. In three chapters we get a recipe for success, a real life implementation example at Microsoft and the importance of a continuous improvement culture.
The author describes his six steps in the recipe for success: Focus on quality, reduce work-in-progress, deliver often, balance demand against throughput, prioritize and attack sources of variability to improve predictability. To grow in or build maturity you first have to “learn how to build high-quality code. Then reduce the work-in progress, shorten lead times, and release often. Next, balance demand against throughput, limit work-in-progress, and create slack to free up bandwidth, which will enable improvements. Then, with a smoothly functioning and optimizing software development capability, improve prioritization to optimize value delivery. “
In Kanban it’s important to have explicit policies, designed to manage risk and deliver customer expectations. Work must be tracked transparently and all team members must understand and know how to apply the policies.
The last chapter of this part elaborates on a continuous improvement culture. In Japanese, the word Kaizen literally means “continuous improvement”. “Kanban provides transparency into the work, but also into the process (or workflow). It provides visibility into how the work is passed from one group to another.” “In addition to the visibility into the process flow, work-in-progress limits also force challenging interactions to happen sooner and more often.“
Part III, covering half of the book, is al about the implementation of Kanban. I created an example of a Kanban board and use that example to explain some of the key characteristics of the Kanban system (see: https://hennyportman.wordpress.com/2015/05/25/book-review-kanban-successful-evolutionary-change-for-your-technology-business/). To build your Kanban system you could follow the following high-level steps:
▪ To set up your visual control board you you first have to define a start and end point for control. This results in an outline of the workflow (from left to right) on the card wall.
▪ Next you have to define your work item types. Think about requirement, feature, user story, use case, change request, production defect, maintenance, refactoring, bug, improvement suggestion or blocking issue.
▪ As a following step add buffers and queues to the workflow to manage the bottlenecks.
▪ For each type of work you must make a study of the demand (in the figure the swim lanes for Change Request, Maintenance and Production Defect) and allocate capacity according to the demand. This results in limits for each queue.
▪ On the board we are putting work item cards. Each visual card representing a discrete piece of customer-valued work has several pieces of information on it, e.g. id number, explanation, data accepted, hard-delivery date, et cetera.
▪ Set the input and output boundaries. Upstream and downstream partners want to see their work on your card wall. For you, you first want to provide transparency onto your own work. In the example you find the input queue and release ready columns.
▪ At the top of each column you show the WIP (Work-in-progress). When there are fewer cards in a column than the WIP you have to pull a card from the previous column to keep the flow going. This will help to reduce the lead-time.
▪ Downstream you have to discuss the input queue size. This depends on the prioritization cadence and the throughput of the system. Upstream you have to agree on delivery coordination and method.
▪ Decide on the different classes of service. Each class comes with its own set of policies and target lead-time. Use e.g. for standard class of service the yellow post-it, for fixed delivery date the purple post-it, and for expedite the grey post-it.
▪ For issues (impediments) you could add a red post-it to the existing work item.
▪ As a result establish service level agreements and policies.
In the book these steps (and several more) are explained in much more detail including lots of best practices how to apply them.
The last part is the most difficult part of the book. If you want to make improvements to your Kanban system you have to look for bottlenecks and non-instant availability, waste elimination and reduction of variability. This part ends with issue management and escalation policies.
To get familiar with Kanban this is a good book to read. The book uses good examples and gives you a good insight how Kanban can and must work. It will help you to set up, use and optimize your own kanban system. Like all agile approaches don’t start with everything, begin simple and build upon it based on your own experiences and feedback.
I work in a development / support IT group (we support and enhance a suite of internally developed software applications). Using guidance from the book, we've slowly modified our processes and have achieved a moderate level of success and are continuing to improve as time goes on. We've now been using Kanban for a little over a year, and other groups in the company have started to ask for our help getting them started using similar processes.