Agile development with Kanban

Editor's note: For teams that need to collaborate at different locations and times, electronic signage, such as Leangoo, can be used.

Body

Today I would like to share with you an Agile development tool "Kanban", the word from the island, when I see the English kanban, I was really shocked, Kanban unexpectedly is kanban?!

We can combine Scrum with Kanban, make project management more effective, make resource allocation more reasonable, make performance appraisal more fair!

• For the project manager, the most worrying is that the project progress is not controllable, do not know the specific work progress of each developer, with the Kanban everything is so clear.

• For the development manager, the most worrying is that the allocation of resources is unreasonable, busy people busy, idle people die, with Kanban all is so natural.

• For developers, the most worrying is the performance appraisal is not fair, "with what I do more than him, take the salary is less than him?" It's unfair! "With the Kanban everything is so fair."

Visible, the project manager, the development manager, the developer has the Kanban, also has the harmony and the joyful!

So what exactly is Kanban? Let's take a look at this form first:

Let's take a look at this form now!

• This table has 5 columns: Backlog (original requirement), Selected (selected demand), Develop (development phase), deploy (Deploy phase), live (on-line stage)

• Where the Develop stage consists of 2 sub-stages: ongoing (in progress), done (completed)

• Includes 3 roles: Product Manager (Red villain), Developer (blue villain), deployment person (green villain), in fact there is a project manager, but he/she runs through all the Times, and all is not drawn out.

Many small cards are placed in the Backlog, which are referred to as WIP (work in Process, on-product) in Kanban. For product managers, WIP is a requirement, and WIP is a task for developers and Deployer.

The actual WIP cards come with some textual descriptions, including: Title, description, priority, and so on.

It is important to note that there is a number below Selected, Develop, and Deploy that represents the maximum number of WIP that can be placed in this stage. For example, you can have up to 2 WIP in Selected, and only 2 WIP in Develop (including its sub-stages). The numbers here are just an example of how much can be determined by the actual team. There is an empirical formula that can refer to "WIP cap = Team Size * 2-1", minus 1 means that you need to collaborate, for example: 4-person team, WIP limit is 7.

Maybe someone would ask, why is there no Test phase? --This can be, here is just an example, you might as well add it yourself.

For multiple projects, you can add more lanes (rows) to this table, each line equals one item, and all project progress is clear.

Good! Continue our Kanban, interesting things are about to happen!

The Product Manager selects 2 WIP to Selected, at which point the development manager determines the technical difficulty of the task, assigns the task to the specified developer by the project manager, and assigns the same task to two people to pair programming.

Developers (architects and programmers) can perform a workload assessment of the requirements in the Selected, which can be done by voting, ultimately giving a reasonable estimate, the entire estimating process, and the project manager without involvement, primarily by developers.

Development manager can set a "score" on the task, this score can directly affect the subsequent performance appraisal, so for everyone, this score is publicly visible, who do more, who do less, at a glance. Of course, developers can also take the initiative to have more challenging tasks (to exercise themselves and to get more money), but the decision to assign tasks is always in the hands of the project manager.

Now that the A and B two tasks have been handled separately by different developers, the tasks should be moved to ongoing, and the product manager can pick out 2 high-priority requirements into Selected from the Backlog. This ensures that both Selected and Develop have reached the WIP limit.

Someone has finished a, so a can be moved to done. Then the deployer can start working.

The deployer can move a from done to the deploy, indicating that the deployer is doing the job. At the same time, the developer of the a task can do other new tasks, just move from Selected to ongoing, move this thing is not the developer random operation, but the project manager is responsible. The product manager found that only one D in Selected could consider putting in some new requirements.

At this point, the deployment personnel encountered a problem, found that a deployment is always an error, not run up. At the same time, other developers have completed the B task.

The developer who completed the B task would have been able to do the new requirements, but the project manager found that only 2 tasks were allowed in the Develop, so there was definitely a problem at the back of the stage, causing the whole process to be blocked. Project managers can flexibly dispatch human resources and focus on solving the problems they are experiencing.

So the project manager had to give up the new task and get the developers to help deploy the staff to solve the problem. At this point, the other developers are still doing the C task.

The deployment problem has not yet been resolved, and the C task has been completed, and the product manager has put in a new K-demand to ensure that the Selected is filled with water.

The whole deployment problem looks more like a person, all the developers are in the battle, concentrating more people's wisdom to solve this thorny problem. At this point, the product manager can not put more demand, because at this time Selected has been completed. In fact, developers face too much demand, often will feel pressure, body and mind haggard.

It seems that this deployment problem, really enough to toss, even the product manager came to join in the fun. But he may not know the technology, but many people more than the mind, is the so-called "lookers, Onlooker sees most", eventually through the efforts of everyone, will certainly conquer this bunker!

A few days later, the Kanban process is still stable, we division of labor and Cooperation, human resources reasonable use. Everyone is a team, the goal is to do the project well, not because of their own things are done idle.

We may as well stick this form on the wall! Let every employee can see, let the road bosses can also see our hard work, this is really a very good project management Method!

Article Source: http://my.oschina.net/huangyong/blog/196883

Agile development with Kanban