如何实施 SCRUM

如果严格按照书本上的 Scrum 法则一条条地看，那么我们队伍现在的做法也许根本不算 Scrum。不过好歹我们也被称作 Scrum 一段时间了，我的资历比不上前面的资深开发者，只能说一些目前的一点经验。

经验一：整个团队必须理解 Scrum 的目的和限制。
如果管理团队把 Scrum 当作一种新的管理流程，那么这个理解绝对是错误的，而且有害。要正确理解 Scrum 的实施原则，需要从理解其设计目的开始。

我所理解的 Scrum 的目的在于两点：

1. 适应变化。Scrum 的一个基本假设，就是外部需求模糊而难以理解。Scrum 对此的理念是：让客户直接看到半成品，他们才知道自己要什么。很多 Scrum 的原则都是围绕如何解决这个问题的：比如每个 Sprint 结束时由 Product Owner 为客户进行展示，又比如任务细化一般不超过一个 Sprint。理解了这一点，才会理解为什么 Scrum 似乎总在变化，因为需求总在变化。
2. 快速迭代。Scrum 的另一个基本假设，是团队生存在一个快速变化且充满竞争的世界。如果自己一年半才能发布一个新版本，而竞争对手半年就能发布，那么几年之内，我们就会被对手甩得远远的。Scrum 对此的理念是：发布即 Milestone（里程碑），宁可每次发布二十个功能发布五次，也不要在内部搞五个 Milestone 然后一口气发布一百个功能。理解了这一点，才会理解为什么 Scrum 会认为发布时砍功能是一种正常情况而非一种失败。

要实施 Scrum，整个团队至少必须取得共识，即以上两点是不能商量的。流程必须为目的服务。如果队伍相信增加前期沟通才是让需求清晰起来的最好方法，或者相信发布的功能必须是大批量一次性，那么请使用瀑布开发模式。

相应地，我们必须明白 Scrum 不能做什么。我的理解可能耸人听闻，仍是两点：

1. 因为发布周期缩短，团队没有能力保证作出的每一个决定都正确，很多开销都必须花在试错上；
2. 快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队，因为一个人的离职或病假都可能对单一功能的进度造成影响，不利于短期频繁发布。

Scrum 对此的解答是：不要试图不犯错误，而是保证小的错误能被尽快发现从而不会酿成大错。所以 Scrum 过程中总会有些不确定性，或者功能不合需求而返工，或者突然缺了人手导致一些单个功能必须延期完成。如果非要事先确定发布周期而且还得保证不许功能裁剪，请出门左转找 CMM 认证：它可以把任务精确到每个对话框上该用什么字体。前期计划精确到这个粒度，什么都可以在掌控之中。但问题是，我们必须用更长的发布周期来换。

理解了上面的内容，我们实施时就不会对某些形式性的东西过于纠结，比如 Burn down chart，比如 Scrum 扑克。需知形式服务于目的，而形式未必适用于每一个团队，正如瀑布模型在每一个团队中也都有差异。如果仅仅是因为团队成员没有在 planning meeting 上打扑克就认定这不是 Scrum，那么未免愚蠢了些。反过来，某些看似烦人的「流程」却不可或缺，比如每天的 15 分钟 stand-up，如果我们明白它对交流方面的重要作用，就绝对不会认为它可以被省略。

举个实际的例子，在我们的团队里，我们强迫一周一个 Sprint。就我所知，即使在很多实施很成功的项目中，这种做法也是相当激进的。一开始我也不理解这一点，但实施了一段时间后，我开始认同这一条，因为一周的发布周期让我们没有机会把任务往后推，从而迫使我们尽快从瀑布模型中转移出来。这对一个有着悠久瀑布开发传统的团队来说非常重要，但对别的团队来说，就不一定了。

经验二：正确定位队伍中的 Scrum Master。
为什么单独提 Scrum Master？如果只是看书本和参加培训，我相信多数人都会同意我的观点，即 Scrum Master 或许是整个开发过程中作用最不清楚的角色：不参与需求分析、不参与代码开发、甚至不参与任何人事问题，只有一句「去除阻碍」这种含糊的表述。但是，当我真正当起这个 Scrum Master 之后，才发现这个角色承担的职责非常具体。比如：

1. 确保流程执行正确。进入 Scrum 之后，很多团队仍然会以各种方式走老路，比如有意无意地拉长 Sprint 周期，并以此区别计划周、开发周和测试周，实际上是把原来三个月的瀑布开发周期变成了两到四个星期的瀑布周期；又比如以开发时间有限为理由把自动测试开发任务缩减为手工测试。好的 Scrum Master 应该有能力发现并制止这种情况。——顺便说一句，相信我，不要以为两个星期的瀑布周期是个可行的开发计划，我们不可能完成测试任务的。
2. 制止官僚主义流程。典型的例子就是一个又一个的 spec/plan review 和 sign-off 邮件；又比如非要区分所谓 Unit Test、BVT 和 Functional Test：或许对一个图形界面程序来说这两者区别极大，可对于函数库则几乎没有原则差别。合格的 Scrum Master 应该制止这样的倾向。——不过我也得说，这一条我现在做得很差，还需要改进。
   
3. 构建交叉知识结构。整个团队的知识模型应该是各有专长但互有交叉的，而传统开发的一个很重要的问题是知识结构不平衡，比如测试的只管测试，开发的只管开发。这种模式对于发布时间长的大团队来说也许能接受，但对人手短缺又要求快速发布的小团队则是致命的。好的 Scrum Master 应当能够对团队的决策具备影响力，确保不会让某个任务陷入「只有一个人知道细节」的情况。——这一条在习惯了传统瀑布开发模型的团队中往往是最大的阻碍，需要时间改善。

但正因为上面的理解，我基本上不同意 Scrum Alliance 的教科书里关于 Scrum Master 的大多数表述。首先，Scrum Master 必须承担一部分开发任务，因为没有介入一线开发，很难想象 Scrum Master 会真正理解团队的「痛点」。其次，Scrum Master 需要关注团队的每一个人，不然队伍可能由于所谓「自组织」的原则而隐藏一些问题，比如某个人过于专精某一项而忽略了和其它成员的交流。当然，也有些部门的 Scrum Master 只负责写报告和推事情。这不是我共事过的任何一位 Scrum Master 的做法，而且我也可以很自信地说，这种 Scrum Master 在我们公司是生存不下去的。

Scrum Master，你是肩负着人类使命的人啊！嗯！（握拳）