对Scrum的一些思考

如今，Scrum几乎已经成为软件开发流程的不二之选，甚至在软件开发之外的领域也开始崭露头角。我的职业生涯到现在一直是和Scrum相伴，但是不得不遗憾地说，我很少有那种Scrum流畅运转的感觉，似乎总有些不如意，彷佛开着一辆老旧的汽车，总会有些部件发出奇怪的声响。于是我有时会想着这些响声从哪里来的，是否会有那么一些地方，在那里一切如同新的保时捷一样运转。我思考的结果分成三个部分，先天的设计缺陷，速成的推广模式以及常见的对Scrum的误解。

先简单介绍下Scrum，Scrum是一个“新”的软件开发流程，属于更广义的Agile的一个分支。Scrum将一个产品的开发过程分为了一个一个小的开发周期，每个开发周期有着自己的目标。一个周期一般会有任务细化，计划，开发，展示以及回顾总结这几个部分，开发过程中每天早上的简短例会也是Scrum的特点。除了这一套流程之外，Scrum还定义了三种不同的角色，PO（Product Owner）来负责汇总用户的要求，厘清不同要求的相互关系以及优先级，开发小组来实际实现用户的需求，还有一名Scrum Master（for some reason no acronym）来负责整个流程的运转，发现并消除开发过程中会遇到的瓶颈。将一个大的复杂的问题分解成小的容易解决的问题，可以说是处理复杂问题时的必由之路，Scrum将这一方法明明白白地嵌入到自己的流程之中，并且设置了便于提前发现潜在风险的机制，不仅提高了项目的灵活性，也增加了项目成功的可能。同时固定周期的模式，一方面可以便于PO来估算项目的进展速度，为中长期的计划提供了可能，另一方面，每一个小目标实现会带来切实的成就感，可以激励组内的成员。

设计缺陷

Scrum的设计缺陷可以从Scrum Master谈起。Scrum Master从名字就能看到，是Scrum独有的角色，引入这个角色，部分是为了替代之前由管理层来完成的功能。比如之前你发现和其他部门沟通不畅，一般是上报给你的上司，由你的上司来出面解决这个问题。这种解决跨部门问题的职责被Scrum Master承担了。其最大的区别在于Scrum Master不是任何人的上司，Scrum小组中的所有成员在功能上是互补的，在地位上是平等的，对应于其扁平化的管理理念。但这带来了一个不好的后果，即Scrum Master解决问题的能力有限。这里不是指Scrum Master的个人能力，而是Scrum Master普通员工的地位让他没有以前处于领导职位的人一样的解决问题的能力，即中国人常说的“人微则言轻”。在跨部门沟通中，如果遇到了真正的问题，Scrum Master其实也只有上报高层这一种手段。对于小组中懈怠偷懒或是能力不足的成员也是如此，Scrum Master没有人事的任免权，只能上报等待结果。而且由于大家的同事关系，这种问题在回顾总结中也极少（有过）被提出来。在激励小组成员方面，Scrum Master的手段也很有限。在一定范围内增加会议的趣味性是很多Scrum Master用过的招数，比如相信很多人都参加过的乐高主题的回顾总结会议。很多Scrum Master会牵头组织一些团建活动，买一些甜品或是小玩具来增加小组的凝聚力。不得不说这些Scrum Master其实是在尽心尽力地履行自己的职责。但是现代人都很现实，现实就意味着，只有升职加薪（甚至是只有加薪）才是真正的激励，Scrum Master的那些招数在很多人看来都是骗小孩的把戏。给开发人员升职加薪也不在Scrum Master的权力范围之内。凡此种种，造成的现象是Scrum Master在很多组里面只是在维护Scrum的形式而已，甚至在这种形式被组员所熟悉之后，Scrum Master完全失去了作用。

我觉得Scrum的设计中应该包含高层管理，因为高层管理的支持不可或缺。Scrum Master只有假借高层的权威，才有可能去做完成他被赋予的职能。而且可以想象，Scrum以一种扁平化的管理模式，取代了以前的层级管理制度，原本属于中层管理人员的职责必然要被别人承担，而且必然是一部分向上，一部分向下。在这种情况下高层管理本来就应该承担更多的责任。但是Scrum没有明说这一点，很多高层对此也毫无准备，于是Scrum Master的呼喊无人回应，人事任免和嘉奖的职责无人拾起。很多公司在使用Scrum一段时间之后又重新引进了中层管理，我猜测是公司高层发现自己的工作量上升，甚至包含了他们原本并不熟悉或者是已经淡忘了的领域。中层管理的出现几乎必然是对Scrum的伤害。

推广模式

我对于Scrum的推广活动其实所知不多，但是看到过咨询公司价格不菲的培训课程和考试。很多的Scrum Master的培训为期两周，之后再加一个考试，净用时不到一个月，能拿到某种资质证明，找工作时可以展示。这种速成的模式给咨询公司带来了很多的经济利益，也有助于Scrum的快速推广，但对其效果我却很怀疑。在Scrum中，其实Scrum Master和PO是最挑战个人能力的职位，PO的角色尤其困难，需要很强的沟通能力，逻辑分析能力和决策判断能力。而开发小组很多时候只要按照任务要求执行即可，很接近于体力活，“码农”之称，不完全是自嘲。而实际情况是，PO和Scrum Master几乎是没有门槛的，反倒是“码农”们因为编程本身的门槛，成为了最难的岗位。这种角色难度和招聘门槛（当然也包括薪资待遇）的不匹配造成了工作中的很多问题，当事者自己或许也很沮丧。Scrum Master在之前说过很多，个人能力不出众或是责任心不强的就会成为组内的隐形人。PO中有很多非常依赖开发人员来作出决策，或者很难反驳组内较强势的开发人员的观点，这和PO本身对于问题解决方案的不熟悉有关。这种不熟悉肯定也会影响到和用户的交流以及优先级的判断。没有很多的项目经验，也很难想象PO能够对Scrum中更加灵活多变的用户需求应对自如。我遇到过非常勤勤恳恳的PO，学习能力很强，做了大量分外的工作，也没能摆脱这些影响。按我的想法，那些在Scrum框架下消失掉的中层管理，如果他们思想开放不在意级别的高低，或许是简单培训之后做PO或Scrum Master的最佳人选。与之类似的是本将会成为中层管理的有经验的开发人员。

一般误解

对于Scrum的误解比较琐碎，这些细小的区别，要么加大了Scrum的时间成本，要么降低了Scrum的效用，导致了很多Scrum徒有形式，却没有其该有的灵活，如同买东西付了款却没有收到货物一般。

首先是对于任务复杂度的过度关注。预估任务的复杂度本是细化任务过程中的一个很实用的技巧，如果大家对于某一个任务的复杂程度有着相同的看法，那么说明任务的描述是清晰的，大家对解决方案也有一个大体上一致的想法。复杂度本身是一个没有严格定义的概念，又是在预测未来，实在是没有精确的可能。作为一个辅助工具，也没有精确的必要。但是很多人对此非常较真，对于简单的任务，有时关于复杂度的讨论甚至会超过完成该任务本身所需要的时间。我还参加过很多次专门来“校准”复杂度的会议，大家翻出来以前做过的任务，重新讨论那些任务该有的复杂度，并试图以此来标定以后的任务。这大概是最没有意义的会议，却又极其耗费精力。其过程和网购很像，要从淘宝比价到京东，看到旁边“猜你喜欢”又要对比不同的品牌，从单项性能的对比直到对用户评价的掂量，这是一个时间和脑力投入的无底洞。

其次是对于计划中目标制定的轻视。很多的计划会议，不过是对任务清单按照优先级做一个排序，然后根据开发的速率选取前N个任务。这是一个完全刻板的过程，甚至可以在一定程度上自动化，但计划本不应该是这个样子的。计划承担着将复杂问题细小化的任务，本该是所有环节中最富于智力挑战的过程。计划本该围绕着目标展开，但大多数PO的做法是在选定了任务之后对大家说，我们来想个目标来描述下我们要做的事情吧。这样做的后果就是目标与产品的逻辑联系较弱，很多时候即使开发周期圆满结束，开发小组也并没有取得可以展示的成绩，获得直接反馈、提前发现问题都无从谈起，成就感也大打折扣。

第三，没有人事先为回顾总结会议作准备。除了Scrum Master会准备一下会议流程之外，其他的成员都是即兴发挥，他们也只被要求即兴发挥。回顾总结会议上最常被问到的是小组成员的主观感受，而并非客观的数据，或是用户的回馈。因此即使大家都全身心投入，看到的问题还是受限于组内成员自己的经验，并没有遵循“以用户为中心”这一想法。这一做法的一个副作用是总结会议上议题的重复度很高。我觉得如果由PO或者是一部分小组成员事先采集一些用户反馈，准备一些数据，回顾会议会更深刻并且更加切合实际。回顾会议的另一个问题是发现了的瓶颈得不到解决，会在每次会议上反复出现，造成令人沮丧的局面，对应于之前提到的Scrum Master本身权力的限制。

写在最后

我对Scrum的思考必然是受我自己的经验限制的。如前所说，Scrum伴随我的职业生涯至今，这意味其他的开发/管理模式都在我的经验之外，因此我其实没有多少对比。同样受经验之限，虽然我对PO发了很多议论，对于PO这个工作我其实了解的很少。开发者和PO的交集不过是几次Scrum的会议，在此之外PO做了大量的工作，都是我看不见的。把自己的阶段性的思考写下来也是方便在以后的工作中以及和别人的交流中验证自己的想法。慢慢地也确实感受到流程只是一个死的工具而已，再好的流程也无法给予有效的保证，还是要看执行的人。正如现在大家常说的，Scrum是一种思维模式。