learning from the Trenches 12-16 用看板管理大型项目
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