我不信奉Scrum，我信奉敏捷

Scrum一直以来争论不断。虽然创始人Ken在演讲中曾说过即使是白痴也可以用Scrum，但是依然有很多人认为Scrum对团队成员的素质要求非常高。另据统计，75%以上的Scrum都可以称得上失败。

去年十月，有幸参加了Outsofting鲍央舟老师的Scrum培训。培训期间，另一位敏捷教练Julien问我：“你信奉Scrum吗？”当时我冲口而出的回答是：“我不信奉Scrum，我信奉敏捷。”回想起来，了解Scrum这几年来，一直对Scrum有一种怪怪的感觉。这难道就是传说中男人的直觉？呵呵。

1. 我们这样走向Scrum

1.1 在Scrum之前，我们是这么干的。

任何一个项目都可以划分为活动，角色和产物。在典型的瀑布模型中，活动分为计划、需求、设计、实现、测试和发布，当然全生命周期还要增加维护。角色是项目经理，需求分析人员，设计师，代码人员和测试人员。产物有项目计划，需求文档，分析设计文档，代码，测试用例和最后的软件包。

 

1.2 Scrum是这样的

Scrum也符合这一原则，分为活动，角色和产物。活动分为计划会议，每日立会，评审会议和回顾会议。角色是ScrumMaster，产品负责人和团队。产物有产品订单（Product backlog），冲刺订单（Sprint backlog）和燃尽图。

听说Scrum非常神奇，看看Scrum如此简单，不如我们开始吧。

 

1.3 然后就郁闷了

Scrum并不像想象中那么美好，只是看起来简单而已。

迭代中的任务总是不能完成，问题非常多。计划会议时间太长，感觉效率低下，准备不足，有效信息不足。每日立会是个比较严重的负担，时间超时，让人窒息。评审会议走过场。回顾会议变成抱怨大会。

QA开始抱怨测试工作压力非常大，每个迭代只交付部分功能让QA工作不好安排，效率太低；随着迭代的增加，回归测试工作量不断增加，而引入自动化成本又太高，当前的团队在自动化方面的技能不足。开发人员需要学习的东西更多，代码在几个迭代后快速的腐化，每个迭代都要安排不少时间来重构返工，架构不能支撑业务需求，多次大调整。ScrumMaster仅仅是维护Scrum的流程就很累了。（上面仅是部分问题列举）

结果并不理想，但是Scrum应该没有问题，那么问题在哪里呢？苦苦思索，好像有了答案。如果我们有了优秀的人，他们组成了优秀的自组织团队，使用优秀的工具，采用优秀的实践，那么Scrum应该能够发挥它的作用。

 

2. 我不信奉Scrum

2.1 Scrum不是解决方案

不少企业或组织根据Scrum重新定义了角色，活动和产物，然后开始工作，然后碰到了困难。于是他们请来教练进行诊断，一番诊断后，教练给出了诊断结果，你们做的不是真正的Scrum，你们做的是Scrum-but。在那一霎那，心都碎了，我们做的不是真正的Scrum。拿出Scrum的定义看看，我们一个也没少啊，怎么就不是真正的Scrum了呢？（文学夸张，请见谅，呵呵。）

按照Scrum创始人对Scrum的定义，Scrum不是一种方法学，而只是一种管理框架。Scrum不能解决问题，只能暴露问题。然而为什么大家都认为它就是解决方案呢？

1. 问：为什么大家都认为Scrum是解决方案？

2. 答：因为我们需要解决方案。

3. 问：可Scrum不是解决方案啊。

4. 答：这不重要，因为我们需要解决方案。

5. 问：我们还需要学习敏捷思想、原则和其他实践。

6. 答：实践可以有，思想就不必了，因为我们已经有了Scrum解决方案。

上面的问答真有爱。“你想要什么，你便得到了什么。”因为我们需要解决方案，我们就有了解决方案，我们也有了无数的网站和人宣传和咨询这个解决方案。

2.2 硬套会死的很难看

Scrum不是解决方案，它甚至不是一种方法学，Scrum可以和其他的方法学一起使用，当然相性不合，死的很难看。

2.3 Scrum配合敏捷

回到敏捷宣言和原则，从以事为中心到以人为本、人事和谐发展，这应该是Scrum可以发挥更大威力的重要方式。（篇幅有限，没有讨论为什么我信奉敏捷。）