Scrum方法在中国的应用

Scrum在中国——企业实施情况调查实录

最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。

尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：

在交流中谈到的主要问题包括：

1. 在项目中使用Scrum的原因是什么？

2. 在实施Scrum时采用了怎样的路线，为什么这样做？

3. 在实施时遇到的最大的困难是什么，你又是如何解决的？

4. 实施Scrum以后，给项目、公司带来了哪些收益？

5. Scrum实施为何遭遇失败？

Q1. 在项目中使用Scrum的原因是什么？

璎珞天色：

需求变化太快；产品路线图不明；提高效率；增强交流；尽快让业务部门看到结果。kaverjody：

由于当前组织中使用的瀑布开发模型所固有的一些缺陷，以及我们研发部门当前的一些问题，沿用当前的方法无法有效地解决问题或改变现状。上层经过研究论证后决定采用Scrum模式，同时通过其他的一些手段辅助，来解决当前的这些问题。包括交付新的软件发布版本时间太长、软件维护效率低成本高，等等。

张汉东：

我在07年10月份到NibiruTech的时候，初次接触敏捷。当时团队内部普遍的敏捷做法是每天按时召开的例会。当时我不太明白这个例会有什么作用？一直到11月底，强烈的好奇心让我想搞清楚这个问题。于是我找到了Scrum。因为创业团队嘛，刚开始项目管理方面只是用Trac 和我们公司自己写的管理系统。Scrum先进的思想让我们当时的管理现状黯然失色。于是我就决心在公司推广Scrum。

Q2. 在实施Scrum时采用了怎样的路线，为什么这样做？

璎珞天色：

我们不是采用纯粹的Scrum，而是将Agile中的很多理念，包括XP的部分做法，然后结合现有的开发环境与要求，用Scrum的回顾不断地做改进，从而趟出自己的一条路。如果这个Sprint 我们回顾时觉得自己代码Review（审查）做的不好，下个Sprint就会引入新的代码Review 机制。这个Sprint觉得重复性的bug较多，下个Sprint就会引入缺陷预防机制。

我们是自底向上，先做小范围试点，再全面推广，中间对过程进行不断改进：

06年3月——06年6月（1个团队，8人左右采用）

06年6月——07年12月（3个团队，25人左右采用）

07年12月——08年1月（一个部门，6个团队，50人左右采用）

08年1月——至今（异地开发，原有团队的Scrum继续走下去。异地的配合方式，工具，流程等建设中……）

kaverjody：

主要是自顶向下。我们的组织太大，这样的决策权只有顶层管理人员具有。

张汉东：

路线嘛，可以说是自顶向下和自底向上相结合。我把资料拿给我们的CEO看了，同时也把资料分发给同事来看。至于为什么用这种路线推广，我当时只是抱着一心想把好东西给大家分享的心态，其实也没想那么多路线。

随后笔者又向璎珞天色提问道，“在试点时是怎样的实施过程？是针对项目的具体问题，逐步采用各种敏捷实践来加以解决？还是先给团队做培训，介绍敏捷开发的理论实践，然后推行？”，她回答说：

其实我们一开始并没有把Scrum这个说法拿出来。就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。于是就有了一月一个项目的进度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目）。然后为了管理，我们开始开晨会。然后为了改进，我们开始开项目总结会，把Product review和Team retrospective放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。后来总结会上觉得质量不好，我们加入了单元测试和代码Review机制。至于计划会议，一开始我们就采用的Scrum的方法。项目小，MS Project太难调。我们就更换了Scrum的Excel计划表，后来又换了Xplanner。

就这样走了几个月后，我们把大家叫到一起，开了一个Agile方法分享会。把大家之前实践总结一下，然后告诉大家，我们的做法就叫做Scurm，而且它是很有名的哦。然后再把XP、Agile 和Scrum都给大家系统讲一遍。于是大家如梦初醒，原来我们是在走Scurm啊～～～～！！！

同时这个项目组的成绩也得到了高层认可，高层也认为效率提高了。于是让这个团队给周围的团队做分享。并挑几个团队开始试行。因为我们团队成员可能会有轮岗和互调，一个团队使用Project，一个团队使用Xplanner，有时员工也难以上手。为了部门管理统一，方法统一，工具统一，最后高层下令全部实施Scrum。

Q3. 在实施时遇到的最大的困难是什么，你又是如何解决的？

璎珞天色：

首先应该解决领导的问题，解决方式就是拍晕他。拍的方式，一言难尽啊。至于接下来，说实话，我觉得推Scrum这种方式还是很容易推的，不过是一种管理理念。比当年推CMMI那种东西好多了。最困难的是你要不断解决暴露出来的问题。比如说，以下这些呼声：

1. “需求太模糊，造成后期开发沟通成本巨大，反复和产品经理沟通花了太多时间。”

2. “发布周期太长，一个Sprint要做3、4周才能上线，产品经理希望每周都能上两次线。”

3. “由于Scrum过程的特点，我们不能很系统地把握历史需求和整个产品的架构。”

4. “上线时间被业务拍死了，哪儿有时间做单元测试，连代码Review的时间都挤不出来。”

5. “目前的Backlog，人和人之间的协调，任务之间的瓶颈什么的都看不大清楚。”

6. “需求上线，至少1周才能分析数据看结果，没法在这个Sprint一做完就提出新的改进方案。”

7. “开发节奏太快，产品开发测试都没有时间停下来仔细考虑，历史需求没有善加利用。”

kaverjody：

对于所遇到的最大困难，我认为是同事们对于敏捷开发的不了解甚至误解，以及只看到具体使用的工具和采用的开发实践等，而没有正确领悟到这些决定之后的那些考虑，即为什么要选择这些工具？为什么要采用这些开发实践？选择的标准是什么？选择的过程中才涉及到或者说真正体现出敏捷提倡的那些价值等。

而解决这些问题没有一蹴而就的办法，只能持续地进行教育工作。一方面从理论上进行灌输，并通过长期的讨论来回答同事的问题，来消除大家的不安，另一方面，在遇到困难，或出现问题之后，及时地分析并解决难题，然后以此为案例向大家解释为什么要这样解决，以后再遇到这样的问题要怎么处理。

张汉东：

顺利开展实施前的最大的困难有两个：

1. 公司高层的支持。我想这应该是个公共问题。但是InfoQ前几天有篇文章（渐进式敏捷：由下而上的敏捷推行策略）也说了，如果高层并不支持Scrum，那么就屏蔽高层，在团队内部开展就行。幸亏我们CEO和CTO都比较支持Scrum。

2. 公司员工的Scrum培训。同事对Scrum都不太了解，于是我组织了一次Scrum培训，来