kanban 看板管理法

25 Novembre 2014 Publié dans #amadeus, #life

严禁转载，使用请注明出处：http://alex2012-c.j.overblog.com/

作为Agile Master，我们组使用了看板管理方法。并有详细的规定。

kanban管理方法和敏捷开发有着很多的类似之处。工作中，每天都有standup组会，向大家介绍自己的工作进度。

我们有一个板子，板子上有很多的便利贴，代表不同的任务，板子分为5列:

to do/analyse/dev/test/done

每列有自己的标准

Content

In Kanban, the main item used to track the flow of the work is the board. Board’s purpose is to describe the process that we follow as a team. When any improvement is added in the process, the board must be changed according to this improvement in development flow.

When dealing with geographically spread teams (like the FOM since Q4 2013) or remote stakeholders (e.g. product/project/test managers), we have to share the status of most tickets externally, beyond the physical board. That is what Rally is for, as it contains the FOM backlog, and iterations, user stories and spikes it contains are supposed to be up-to-date.

Each user story in Rally should have a state coherent with its column on the board (see also exit criteria of each step in part 3 below),

Main principles

The main Kanban principles for the management board are:

Each column represents a step of the process; output criteria can be defined for each step.
- Work items are pulled in the board; these items must cross the board as fast as possible.
A work item cannot move back in the board.
When a team member is working in an item, a magnet that identifies this member has to be put over the sticker. This shows easily to the rest of the team who is working in each item. This magnet that identifies one team member is called avatar.
Before starting a new action item, the team member should first check that he can’t help to solve a blocking problem.
The number of items in one column cannot exceed the WIP (Work in progress) number of that column.
All work items must be defined as stickers in one of the possible categories. For each category, different data must be filled in the sticker rigorously.
Metrics are calculated from the data collected from the stickers. Accurate data in the stickers will produce much more useful metric information.

Work Items

Properties in the stickers

Each kind of work item has a set of properties that must be filled. Which are the correct properties to fill can be check in the samples found in the board for each kind of item. The properties that can contain the work items are:

Name: the title of the item. Short and clear description in one sentence of the work item feature.
Due date: is the date limit in which the item must be released. So for this date, this item must be in INT. This limit date can be for instance because of synchronization needs with other teams or due to legal limit dates agreed with customers or other entities. This is characteristic information of the fixed delivery date stickers, which description can be seen in next section.
Start date: is the date when the sticker begins to be processed by the team. The first person that takes the sticker from the backlog must put the date.
Target date: is the date when we estimate that the item will be completed and ready for demo. It must be filled at the same time than the start date, and as said it is estimation. It is characteristic data of the standard stickers.
End date: the date when the item has submitted for the business analyst sign-off. This moment is when the sticker is put in the Done section of VALIDATION column. This criterion ensures that we count as lead time the time since the task begins until the work in the sticker has finished. The person that moves the sticker toDone cell must fill this field with the current date.
Priority: is the number that defines the priority of the sticker comparing to the others of the same kind. Higher the number, higher the priority.

Work items types and markers

These are the kind of stickers that we have defined. It is worth to say that a task can change of category according to changes in its urgency for instance:

Expedite: highest priority items. This tasks must be done as fast as possible. The team members must stop other tasks they are doing if their help is necessary to process this item. The WIP for expedite items is for the whole board, not for column, and because of this the WIP for the columns doesn’t take in account the expedite items. This expedite WIP is limited to 2, so only 2 expedite stickers can be in the board at the same time.
Fixed delivery date: the item must be delivered before a fix date (due date in the sticker). Estimation must be as precise as possible. It should be treated before other work items, but in a reasonable delay before the expected delivery date. It can become an expedite if it is late.
Standard: estimation less precise than in fixed delivery date items. Estimated end-date required. Priority is required. It’s the normal work items.
Intangible: this type will be used typically for team internal tasks with lower priority than the standard items. They have low priority and no service agreement.

The WIP limits are defined for each column, so no matter the percentage of any kind of work items we have. It is only important the amount of stickers. This is true for all the types except Expedite, which as said have a limit in the whole board. This expedite limit is written in the board next to the Expedite sample sticker.

Metrics

Estimated time to complete is the estimated time required to finish a planned user task. This time Estimated time to complete is collected by FOM Release Manager during Weekly Follow up stand up.

Spending time is the estimated time spent working on a task. This time Estimated time to complete is collected by FOM Release Manager during Weekly Follow up stand up.

This metric simply shows the mean lead time whatever the type or the size of the work item. It can be used to build high level plan.

Scheduled

High level plan is built by capacity and lead time. Detailed methodology is described here.

The result is published as MSP file in the team sharepoint.

Commitments result of the schedule exercise is published in Rally with month granularity for long term plan and week granularity in a 2-3 months gliding window.

Release status screen in Rally provides a clear view of the schedule.

Partager cet article