文/一觉亮天 2010-10-24

这篇文章之所以叫第二眼看Scrum，是因为我曾写过一篇文章名为First
Sight At Scrum。写第一篇文章时我刚用Scrum不久，对Scrum的理解还不深。

大约一个多月前，公司出钱，我参加了一次Scrum Master认证培训。据说培训费是500美金，培训过后还发了一个ScrumAlliance的证书，PDF格式的。

从初识Scrum到如今用Scrum大约十个月，再加上参加完这个培训，感觉还是有些心得和体会，就以Recipe的形式记录下来。

Scrum是什么？

Scrum是敏捷开发的一种管理流程。Scrum中包括三种角色，Product
Owner，Scrum Master，Team，而且只有这三种角色。维护两份Backlog，Product
Backlog和Sprint Backlog。一张图，Burning
Down Chart （燃尽图）。

项目经理哪去了？

传统软件开发中项目经理的角色，一部分任务划归了Product Owner，一部分任务划给了Scrum
Master。

Scrum拥抱变化

和传统软件开发相比，Scrum更适合于变化比较多比较快的软件的开发。Scrum的每个Sprint的长度一般2-4周。在Scrum的每个Sprint，都会产出潜在的可交付的软件。那可交付的软件所具有的特征，它都应该有，比如用户手册文档，比如软件是测试过的可运行的，等。这也对设计提出了更高的要求，软件设计更多地要按Feature设计，最重要的Feature在早期Sprint完成。如果Sprint失败，损失就是一个Sprint的投入，不会像传统瀑布模型软件开发到最后交付一刻才知道成功失败。Scrum流程不怕失败，如果注定失败，期待失败早点来临早点发现。

Scrum不适合所有项目

如果软件的需求变化不多，或难度不大，不一定要采用Scrum的方式。Scrum更适合于难的，变的。对于维护类型的项目，没有办法预料有哪些问题会来临的，类似于救火的这种项目，Scrum可能也不适合。

PO的职责

Product Backlog由Product
Owner维护，其中的Product Backlog Item(PBI)一定按优先级排序的，也一定有初始Effort的估计。PO关注投入产出比(Return
of Investiment, ROI)，也就是Effort/Priority。只有PO有权增减PBI。Effort的估计需要Team完成，因为是Team做事。

PBI每一个最初都是详细设计过的吗？

不是。优先级排在前面的PBI，设计得比较详细，优先级排在后面的PBI，开始可能没有设计，但随着项目的推进，随着Product
Backlog中优先级高的PBI的完成，随着低优先级PBI优先级的提升，设计逐步细化。也许低优先级的PBI最终不做了，如果前期就详细的设计，最终不做了就会浪费时间。

用Scrum挽救我们的行业

通常，在销售那里什么承诺都是可以做的，保证如期保质保量地完成需求。但是现实中，软件开发项目鲜有不超期，也有很多最终是失败的。我们要让客户知道风险，Team只承诺每个Sprint能够交付的目标。

Scrum Master做什么？

Scrum Master不是管理者（Manager），也不是决策者(Decision
Maker)。Scrum Master的任务是确保Scrum按流程进行，排除障碍(
Remove Impediment)。Scrum强调时间限制（Time
Box）。Sprint Planing花费时间是有规定的，Daily
Scrum Meeting的时间也是有规定的（15minutes），Scrum
Master要确保行为在时间限制内完成。PO随意变动Sprint Backlog，Scrum
Master要制止。Sprint Backlog一旦确定下来，就不要随便变动，因为这是Team对PO的承诺，如果Sprint
Backlog不稳定，如何能保证承诺的实现呢？

Scrum Master可以是Team Member不？

最好Scrum Master由非Team成员担任。Scrum
Master也是Team一员，有好处也有坏处。好处是，Scrum Master更了解Team，更了解Sprint的进展。坏处是，大家会分不清角色。

Sprint planning
做什么？

Sprint planing Part 1，选择。选择PBI，一定是按照优先级选。

Sprint planing Part 2, 
承诺。把PBI转化为Sprint Backlog Item
(SBI)。定义Definition of Done。包括设计。如果PBI过大，需要Break
Down。

Team自管理自成长

Scrum强调Team的自我管理，不是Scrum
Master，也不是PO来管理Team。Commitment没有完成，是整个Team的失败。Scrum
Team中的每一员最好是多面手，这样才能保证按优先级来选择任务，而不是按每个人擅长的领域来选择任务。在Sprint的结束，Team会自省(Retrospective)，哪些是做得好的方面，以保持，哪些是不好的方面，以改进。

最佳工程实践

Scrum强调迭代（Iterative）开发，有一些方法，比如测试驱动开发(Test
Driven Development， TDD)。要知道TDD是一种设计方法方面的实践，而不是一种测试。例如基于Unit
Test的测试驱动开发，要实现一个功能，先写测试代码，然后写实现代码，每次都要保证编译通过，测试用例通过。测试代码和功能代码一样要进行配置管理，版本控制。迭代开发与测试自动化往往也分不开。比如你新增加了Feature，为了确保不影响旧有Feature，以前的测试用例需要执行一遍。但是如果执行这些测试用例用手动的方式，则是一件繁琐耗时的事情。如果有测试自动化，则事情简单许多。