osteching.com

Be at a loss in face of Scrum

迷失在Scrum
--猪眼看Scrum

Scrum 作为一种最近非常流行的敏捷方法论。有很多文章都讲到Scrum 的好处，Scrum 的最佳实践等等。本文无意再次强调这些而只是列举了一些在实际采纳Scrum的过程中不适当的做法，并和最佳实践做一下简单的对比。或许其中有些夸张，不过，请在怒斥之前对比下自身所在团队的实践。

PS: 俺长期战斗在生产第一线，按照Scrum 的说法，俺这样的角色是猪，所以副标题是，猪迷失在Scrum中。

0/ 团队成员 (Team member)

应该由那些人组成Scrum的团队？Scrum要求有三类基本的团队成员，一个Scrum Master，一个Product Owner，以及若干普通成员。很有意思的一点，Scrum实践推荐团队人员不要太多，一般5到9人。何故？效率！敏捷强调沟通，人员太多严重影响沟通效率。

对几个人的小项目来说，Scrum团队很简单，把人都拉在一起，基本上正好符合最佳实践。

对大型项目来说，如果要采用Scrum 的方式，在组队问题上最忌讳的大概就是把所有人看做一个团队。人太多了，沟通没法弄。几十个人分散在不同的小项目组，这些人按职责分可以看出测试人员，前台人员，后台人员；按功能模块也能很自然的分开。为什么不按这些分几个团队呢？把不相关的人拉在一起开短会，做回顾，能有多少是共同的问题呢？如果一个人提出的问题，超过半数人完全不知所云，这又能解决什么问题？

但也不是说非5到9人不可，在保证沟通效率的前提下，稍微多些人应该也可以接受，视具体情况而定。

1/ Product Owner

1/ 每日短会 (Daily Scrum)

每日短会大概是Scrum 实践中最容易被采纳的了。因为简单，当然用好了效果也会非常好。

善做表面功夫的人喜欢每天开短会，而常常选择性忽视其他Scrum 实践要素。我们是Scrum啊，你没见每天早上我们都凑一块说几句吗？我所经历过的一次就是，项目经理大手一挥：我们要Scrum喽，大家都过来开会。好家伙，将近三十号人全凑过来了。现在呢？已经没人理这样的短会了。

每日短会是要发现问题的。一两天没有问题算正常，但是持续一段时间大家都没问题就应该算是一个迹象--项目遇到了问题，或者是大家不敢提问题，或者是大家不知道存在什么问题。对于没人敢提出问题的情况，Scrum Master应该做检讨，是什么压制了团队成员的主动性。对于不知道存在哪些问题的情况，Scrum Master和Product Owner都要做检讨，Scrum不是光开短会那么简单，作为敏捷实践，Scrum有像Backlog 之类的诸多工具，项目的知识不只是在某几个人的脑子里，是应该团队共享的。不论哪种情况，经理们都要注意了，尽早改善情况，不要等项目失败了再追悔莫及。

没有采纳Backlog 等工具，其实也不怕。如果大家都明确在讨论什么，能够互相给出建议，那也是效果不错的沟通。要是就项目经理和路人甲知道怎么回事，拜托，大家都很忙。

2/ 冲刺（Sprint）

你见过百米线一直在变的比赛吗？

那对发布时间一直变的产品你感觉怎么样呢？尤其这个产品还是亲身参与其中的，没错，很让人沮丧，看不到尽头。对传统的瀑布式开发来说是这样。对短期冲刺来说情况可能稍微复杂一点。
Scrum 的每一个冲刺，要完成哪些功能，优先级怎么样，都是冲刺开始之前约定好的，根据团队的平均工作速率做的估算，而且每个冲刺的产出，应该都是可交付的。

好吧，我们的Scrum就一个冲刺就完成了。恩，要么你这个项目很短，一个月就可以搞定。要么你就是过来砸场子的瀑布流。

一般来说Scrum推荐的冲刺时间是一个月，但在实践中大家说法不一。基本上，观点讨论倾向于，开始用比较短的冲刺周期，评估出可信的团队开发行进速度；随着团队对Scrum 的接受，再根据客户的响应情况，定出一个合理的冲刺周期。

3/ 任务列表（Backlog）

每天工作干什么？完成情况怎么样？都需要有个地方说明，在Scrum 中这个就是Backlog。因为列表中各项是按优先级排列的，所以一般来说，应该按照这个顺序完成。在Product Owner看来，排在越前面的对客户价值越大。但经常遇到的问题是，在开发人员看来，可能前面的难解决，那先解决后面的吧。不要这样！如果不好解决，那就要提出来，由Scrum Master协调解决。项目是大家的项目，工作也是大家的，在敏捷的方法论中，多强调集体的力量。

Backlog 放在那的另一个目的是，在每个冲刺开始之初，由团队成员自己主动承担各个功能点，要求成员主动的承担责任，把这看做是自己的承诺。如果没有这个，而是由别人安排做哪些任务，就失去了这个责任感（哪怕是因为被迫主动承担了责任而间接获得的责任感）。这里有个隐藏的问题，成员主动承担责任，基本消除了原来项目经理安排由谁来做什么的“生杀大权”。这可能会让控制欲很强的项目经理（或者转型为Scrum Master）觉得缺乏安全感。

随着冲刺（Sprint）的进行，任务列表（Backlog）的各项逐个被完成，这个过程很好的显示了每个冲刺的进度。当然有些实践引入另一个更为直接的项目进度曲线--Burndown，这是个递减的曲线，理想的，项目完成时它的竖直方向应该归零。

下面说说敏捷方法的几大杀器，测试驱动开发、代码评审、重构和持续集成。

1/ 测试驱动开发 (Test-Driven Development)
单元测试绝对是必要的，如果觉得单元测试可有可无，直接忽略这部分，跳过往下看。TDD 强调测试先行，哪怕不是先行，功能代码完成之后立马写测试代码进行测试也可以接受。不要让测试代码沦为陪衬，单纯为了达到测试覆盖率才来写单元测试，毫无价值的单元测试，毫无价值的代码，这样的测试覆盖率不要也罢。

对待测试代码的态度也是个问题。比如，每日构建没过去，一看是单元测试没通过，赶紧把测试先注释掉，保证第二天有build 能用吧。这样的态度要单元干嘛呢？不是变成了没事找事了吗？这时候应该做的是解决问题，而不是糊弄了事。

另一个问题是太多的各种各样的mock来做单元测试，Mock的前提应该是，被mock的代码是测试通过的，只是因为复杂性原因才用mock的方式替代，比如数据库访问。如果被mock的代码没有经过测试，那以mock代码为基础的测试，也是不可靠的。

2/ 代码评审 (Code Review)

有两类代码评审，一类是结对编程式的评审，另一种是团队整体的评审。

如果真的是结对编程，这个很简单，编码的过程就是评审的过程。如果是有强制要求代码提交前要找人做评审，这时候就要注意了，经常问问自己，这个评审流于形式了吗？我问过我自己，我的答案是，没错，这个评审经常流于形式。这种类似结对而又流于形式的代码评审，除了浪费同事几分钟时间以外，没有什么可以预见的好处。唯一的好处大概就是出了问题多少能有人帮忙背锅--陷人于不义。稍微认真一点，可以采用这么个形式来完成结对式评审：评审人多问几个问题让实现者来回答。这个回答问题的过程，既是实现者回顾实现思路的过程，也是评审者发现问题的过程。

对待整个团队的代码评审，我犯过一个愚蠢的错误，我曾经把这个评审的作用简单到只看看代码风格之类的任务上。其实这些简单的任务都可以用自动化工具来完成。评审是知识共享的过程，应该把重点放在功能设计和实现上来。让新成员尽快熟悉系统以及找出潜在的设计实现问题。由于是整个团队一起做评审，所以要注意重点突出，不要浪费时间。也是因为时间宝贵，所以不可能面面俱到，评审的代码尽量应该是实现功能的核心代码。

3/ 重构 (Refactoring)

有些新成员喜欢上来就完全重新实现一套逻辑，理由一般都是之前的实现太烂。这不是重构，这是给自己找理由，在没有理解为什么如此实现之前就全盘推翻。

还有另一类是只做修修补补，这种情况在改bug 的阶段尤其明显，最后系统成了“丐帮的长老服”，补丁摞补丁，不知道什么是什么。这一类基本是完全没有体现重构。这样的系统继续下去，会让人越来越搞不懂，设计实现思路早晚迷失在补丁中间。可维护性得不到保证，积重难返，怕是早晚要来个伤筋动骨的大改造。

重构有自己的方法，要有单元测试，要小步快跑，是个逐步演变的过程。没有单元测试质量就无法保证，步子太大就容易变成推翻重做。

4/ 持续集成 (Continous Integration)

这个一定要是定时自动完成的，这样才能确保发现问题。固定下来的持续集成，类此开发工作的心跳，持续不断才有价值。如果临时需要手工处理集成，也不要打断正常的集成周期，确保周期性的集成报告发出。

持续集成不应该作为惩罚工具。持续集成是为了保证项目质量，如果因为变相惩罚，而导致团队成员有故意为了让持续集成通过而降低质量的情况发生，那就得不偿失了。相信没有人会故意捣乱不让持续集成正常完成，所有成员都是为了项目高质量按时完成，不要因为变相惩罚而导致积极性降低。

可以从两方面解决集成失败问题，一是积极交流沟通，教给正确的做事方法，这个很容易做，也很容易被人接受。再有就是再加个工具，比如现在有些提交代码前的集成测试工具。如果使用类似的工具，那就一定要保证工具简单易用。否则工具就成了额外的负担，早晚必遭弃用。

理论是一方面，实践是一方面。敏捷实践的方法论也不是说要用就要全盘接受，可以逐步的采纳或者只采纳其中一部分。比如，有很多虽然不是完全敏捷开发，但仍然采用测试驱动（可能是先从单元测试开始）的团队。也有很多不算是用Scrum 的团队，却很好的利用了Scrum meeting 的方式。这些都是很好的工程实践，只有不断在实践中发现问题解决问题，才能更好的用好这些方法。

References:
Scrum Alliance
Scrum中文网
Scrum Content on InfoQ
It's Not Just Standing Up: Patterns of Daily Stand-up Meetings