Saturday, 22 February 2014

What is Kanban?




Kanban is a new technique for managing a software development process in a highly efficient way.
 Kanban   underpins Toyota's "justtime" (JIT) production system.
 Although producing software is a creative activity and therefore different to mass producing cars, the underlying mechanism for managing the production line can still be applied.
Kanban became an effective tool in support of running a production system as a whole, and it proved to be an excellent way for promoting improvement. Problem areas were highlighted by reducing the number of kanban in circulation.One of the main benefits of Kanban is to establish an upper limit to the work in progress inventory, avoiding overloading of the manufacturing system.
 Other systems with similar effect are for example CONWIP.
Kanban also is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and team members pull work from a queue.

Kanban can be divided into two parts:
Kanban-A visual process management system that tells what to produce,when to produce it,and how much to produce.
The Kanban method –
 An approach to incremental, evolutionary process improvement for organizations.
A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal process to a highly formal phased process. In this article, we'll assume a simple phased process of:
 (1) analyse the requirements, (2) develop the code, and (3) test it works.

The Effect of Bottlenecks
A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.

Using our development pipeline 
as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.
If the analysts and developers aren't aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.
The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.
Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.
If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it.
 For example, the analysts could help with testing and the developers could work on test automation.






No comments:

Post a Comment