12. Capturing and Using Process Metrics

Two process metrics:
• Velocity (features per week)  (每周功能数)
• Cycle time (weeks per feature)  周期时间（每个功能的开发时间）

1. Velocity

1. a reality check tool to make sure that the release plan is realistic

2. it’s used as a tool to predict approximately how many features will be done by a certain date

1)  前几周瓶颈是系统测试   2) 有助于流程改进

2.  Why We Don’t Use Story Points

？In practice, however, the feature sizes turned out to be quite evenly distributed

？estimating in story points  would have been a waste of time.

3.  Cycle time (weeks per feature)  周期时间（每个功能的开发时间）

“Howlong did it take for feature X to move from “Next Ten Features” to “Ready for Acceptance Test.”

预测：This graph is useful for predicting how long it will take for a feature to get done。

经过的天数（周期时间）通常是实际工作时间的5到10倍 ---> using techniques such as limiting WIP(制品限额） to shorten

功能大小与周期时间没有明确的相关性。

影响周期时间因素：功能大小，  专注程度 ，是否有骨干人员可用

improvement  target:

1. More stable velocity

2. Higher velocity     3->5

3. Lower cycle time  6 weeks -> 2 weeks.

Balance  : 

The goal is to have a low enough WIP limit to keep people collaborating and to expose problems—but not low enough to expose all problems at once (which just causes frustration and unstable low).

4. Cumulative Flow 累积流量

Cumulative flow diagrams 显示历史瓶颈的常用工具

but ours like

5.  Process Cycle Efficiency

13. Planning the Sprint and Release

Sprint planning meetings :The purpose of sprint planning meetings is to figure out what to do next.  To Decide which features go into the “Next Ten Features” column.

The meeting has two parts: backlog grooming and top ten selection.

1. Backlog grooming is all about getting features to the “Ready for Development” state

按 大，中，小 划分，大需要进一步划分

2. Selecting the Top Ten Features

Aspects：

• Business value—which features will the customers be happiest to see?
• Knowledge—which features will generate knowledge (and thereby reduce risk)?
• Resource utilization—we want a balance of feature areas so that each team has stuff to work on.
• Dependencies—which features are best built together?
• Testability—which features are most logical to test together and should therefore be developed in close proximity to each other?

3.  Why We Moved Backlog Grooming Out of the Sprint Planning Meeting

Separately meeting for backlog grooming

4. Planning the Release

Take each epic and estimate how many features it will break into.

Once we have estimated the number of features for each epic, we can count the total number of features and divide by our historic velocity of three to five features per week.

--> estimation (based on real data)

14.  How We Do Version Control

broken trunks and branches -> the mainline model, a stable-trunk pattern

14.1 No Junk on the Trunk

Test it at the feature level before checking it in to the trunk and before moving the card to the “Ready for System Test” column.

14.2 Team Branches

3.  System Test Branch

15. Why We Use Only Physical Kanban Boards

One of the main reasons is evolution

The second reason we use a physical board: collaboration

an electronic tool : Using Google Drawing as an Electronic “Wall”

16. What We Learned

了解目标 Know Your Goal

不断实验 Experiment

拥抱失败 Embrace Failure

解决真正的问题 Solve Real Problems

拥有专职变革推动者 Have Dedicated Change Agents  ： one insider and one outsider

让人们参与进来 Involve People