在回首，差不多十年前的内容其实在今天依然充满魅力。敏捷中的Scrum，至今让我印象深刻。对人的尊重，对团队的信赖，持续计划，持续输出，持续改进。坚持下来，已然难能可贵。

角色

Scrum Master

1. 团队有Scrum Master

2. Scrum Master一直在团队身边

3. Scrum Master关注在帮团队移出障碍

Team 团队

1. 团队成员需要坐在一起

2. 团队成员协作完成用户故事

3. 团队成员不能定死角色

4. 团队成员协作先完成优先级高的用户故事

5. 团队成员承认遇到困难并勇于寻求帮助

6. 团队成员互相帮助

7. 团队成员可以互相承担职责

Product Owner 产品负责人

1. 每个团队都要有PO

2. PO有能力对团队要开发的需求进行排序

3. PO要足够的了解产品，以做出较好的排序

4. 一个PO至少要有一个专有的团队

物料

Product Backlog 产品需求列表

1. PO是Product Backlog的Owner

2. Product Backlog要可视化

3. Product Backlog要在Sprint Planning之后更新

4. PO了解所有的用户故事

5. 每个用户故事的“用户满意条件”和“怎样演示”都是很清楚的

6. Product Backlog包含的是用户故事而不是任务

Sprint Backlog 迭代需求列表

1. 团队有Sprint Backlog

2. Sprint Backlog高度可视化

3. Sprint Backlog每日更新

4. 任务估算每日进行

5. Story和Task要能够区分开

6. 哪个任务属于哪个用户故事要很清楚

7. 团队成员自己更新Sprint Backlog，而不只是Scrum Master

8. 团队成员要能够很容易地更新Sprint Backlog

Sprint Burn Down Chart 燃尽图

1. 团队要有燃尽图

2. 燃尽图要高度可视化

3. 燃尽图要有每天更新

4. 当燃尽图偏离基准太高或太低时需要采取行动

Impediment Backlog 障碍需求列表

1. 团队要有障碍Backlog

2. 障碍Backlog要高度可视化

3. 障碍Backlog要持续更新

4. 障碍Backlog是排列好优先级的

5. 不能解决的障碍Backlog要上报PO和管理层

仪式

Daily Standup Meeting 每日站会

1. 每天，同一时间，同一地点

2. 按时开始，按时结束

3. 所有团队成员都要参加

4. 团队成员之间互相沟通，而不是向Scrum Master汇报

5. PO有规律参加每日站会

Sprint Review Meeting 迭代演示会议

1. 演示可工作的功能

2. 只有完成的用户故事才演示

3. 所有利益相关者都要被邀请参加演示

4. 演示过程中要收到利益相关者的一些反馈

5. 演示开始的时候要介绍下原始的Sprint计划

Sprint Retro Meeting 迭代回顾会议

1. 回顾会议一定要开

2. PO+Scrum Master+团队都要参与

3. 要有具体的改进建议产出

4. 建议一定要在接下来的Sprint会议中实施

5. 每个人都要发言

6. 没有被要求的人不能参加

Sprint Planning Meeting 迭代计划会议

1. PO必须参加计划会议

2. 所有团队成员都要参加计划会议

3. 会议结果要放在Sprint Backlog中

4. 所有团队成员要对计划可行性达成共识，并且承诺完成

5. PO对优先级的排列感到满意

6. 所有的用户故事都要有评估

7. Sprint计划会议要按时开始和结束

Sprint 迭代

1. 每个迭代结束团队都有增量的功能交付

2. 团队按照PO指定的优先级来开发

3. 团队已承诺的内容，要保证在Sprint结束时交付

4. 团队在进度落后时要采取措施

5. 团队遇到困难时随时告知PO

6. 对任何一个用户故事，团队知道从哪里获得更多信息

7. 发现问题后立即解决，而不是等到以后

8. Sprint一定要固定长度

9. Sprint之间最多有一天的间隔，最好不要有间隔

10. 主要的没有在计划中的工作项目要被记录下来

11. 团队不是经常加班工作

12. 投资方和客户了解Sprint的安排

13. 和团队其他团队和公司其他部门了解Sprint的安排

14. 团队有时候会承诺偏多，有时候会承诺偏少

15. Sprint中开始开发的故事在Sprint内开发完成

其它

velocity 速率

1. 每个迭代结束时要记录速率

2. 速率只包括安装DoD表情完成用户故事

3. 速率要用于Release Planning

Definition of Done，DoD，完成的定义

1. 每个用户故事都要有DoD，或者继承于默认的DoD

2. 团队要尊重DoD

3. PO和团队要用心了解DoD

4. 团队要能够不依赖于其它团队做到DoD

5. DoD要包含测试

Estimation 估算

1. PO从团队那里获得估算

2. 团队估算的时候，要能够找到PO

3. 只有团队来做估算

4. 每个团队成员都要参与估算

5. 用户故事要足够小，一个Sprint至少可以完成几个用户故事