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

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

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

出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：

姓名（职务）
公司性质
实施方式
实施时间
结果
璎珞天色，负责过程改进
某知名大型互联网公司
自底向上
2006 年 3 月
成功
kaverjody，Scrum Master 某知名大型软件企业
自顶向下
2005 年 12 月
成功
David，Engineer
某知名大型互联网公司
自顶向下

失败
张汉东，Scrum Master
Nibirutech ，创业型公司 全面推进
2007 年 11 月
成功
赵师容，Senior Engineer 某创业型公司
自顶向下

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

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 培训，来给大家介绍 Scrum 里的规则，角色及 Scrum 的特点和它要解决的问题。大家都把疑问拿出来集体讨论。在讨论的过程中，让大家暂时了解什么是 Scrum。然后在实施的过程中，大家就慢慢地对 Scrum 的规则熟悉了。当然前提是推广 Scrum 的这个人，要对 Scrum 比较理解。

以上两个问题在我这其实也不算是困难，因为我推广 Scrum 的过程中几乎很顺利，大家都很支持我的工作。实施的时候基本也没有什么困难，很好上手。可能和我们用来尝试 Scrum 的项 目有关。客户已经把 backlog 写成了 Tickets 发给我们，然后从接受那些 Ticket 算起，到客户要求的交工时间为一个迭代期，没有超过 30 天。这些待办事项基本是优先级等同的，团队内部自己挑选能做的 Ticket，然后每天例会大家都严格回答 Scrum 里的三个问题，保持团队的一致。评审会议也是严格按照 Scrum 的规则来做。所以暂时没有什么问题。我想下一个 Scrum 尝试项目中可能会碰到细化需求制定 backlog 的问题，也许可以让客户把优先级排好，或者说帮助客户和客户一起把需求细分出来，排好优先级，然后在优先级的驱动下，漂亮地完成我们的每个迭代。

接着，笔者又请大家对某些具体困难的解决办法进行深入介绍，璎珞天色说：对应第一个需求模糊的问题，我们的做法是对需求文档统一模板，在计划会议前增加了需求讨论会，产品、测试和开发三方都参加；
第二个发布周期长的问题，我们在项目发布之外，还增加了对日常维护需求的管理方法。每周二和周四上班之前，产品经理会汇总所有维护性的小需求，例如页面修改，数据增删等。周二和周四晨会上提交给负责发布的工程师。 周二和周四的下午，会集中发布这些小需求；
第三、四个问题，无药可救，定期重构，业务第一，不做单元测试，只做代码 Review。

张汉东说道：我们公司目前实施 Scrum 的状态可以说是比较顺畅。所谓的顺畅，也许也包含我自己对 Scrum 理解不太深入，只是抓着一些自己理解的皮毛来加以应用。但我对敏捷的认知，对 Scrum 的认知就是那么一条，不断地迭代，不断地成功和失败，找到属于公司自己的 Scrum。在有一个项目里，因为需求不太明确，所以在 sprint 计划会议制定 backlog 时，粒度控制不是很好。我们的做法是，根据已知的需求先把要实现这个迭代的总体技术步骤列出来，以实现次序做为优先级……我们的迭代期很短，这次是 10 天。这样大概就可以在整体上把握项目的进度了。然后在每天的每日例会上大家都会有计划地把今天要做的 Item 写到看板上。这样有个好处，就是激发团队成员的自我管理意识，从而增进团队的自组织能力。

Q4. 采用 Scrum 后给项目、给公司带来了哪些收益？

璎珞天色：说不上，很难去度量是 Scrum 给公司带来的收益。说实话，我觉得 Scrum 所能带来的收益是没法度量的。我们只能通过调查问卷的方式，去感性地得出它所带来的好处。我们的方法是调查问卷，截 2 张图下来：

kaverjody：我很难在这方面做出一些总结。我所看到的收益包括，更快地获得某些功能的使用反馈，更早地发现一些如多站点开发会出现的问题，更多的机会来发现团队之间合作的问题，并进行反思和改进。工程师在某些软件开发实践和技能方面的能力评估和增长需求（非正式评估，是在不断的开发过程中大家所感受到的能力）更加清楚明确。

张汉东：我 们整个公司现在采用 Scrum 式的管理，如开发部门，销售部门及 HR 部都会遵守 Scrum 规则。因为我们也是初次尝试使用 Scrum，所以大家都严格遵守规则。有新人进来的时候，也没有立即给新人讲解 Scrum 的概念，只是让他在日常的工作中，慢慢习惯 Scrum 规则。公司暂时完成了两个 Sprint 尝试，收益不敢说有多大，起码让我们每个人每天的工作都很有目标感，让我们在客户所规定的期限里完成了那个迭代。我们正在准备启动下一个 Scrum 开发项目。总的来说，一句话，我们也是在 Scrum 的尝试中。

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

David：我们的问题在于，有些高层错误理解了 Scrum 和 Agile，导致歪曲了某些东西，使得 Agile 变得形式化。举个简单的例子，当时的 Scrum Master 负责一个大项目的开发，走的比较顺利，然后有个项目经理发现这个东西挺好，就单独把 Daily Scrum 拿来进行推广；结果，这个经理并不理解什么是 Scrum，他把 Daily Scrum 变成了 Daily Report，而其他 Scrum 的精华部分都没有推广。

每个员工都要在早上固定时间开 Daily Scrum，然后把当天的任务告诉给他，让他来决定工作是不是饱满。这个把弹性工作制直接给破坏了，引起很多人反感；另一点就是很多人认为这样的 Daily Report 太频繁太低效，而且还有压榨员工的嫌疑。所以逐渐大家谈起 Daily Scrum 来都是恶心的不得了，于是经理也知趣地取消了 Daily Scrum，再到后来在公司内部就没有人谈什么 Agile 了。

赵师容：我们是分布式开发，当时中方的团队对于敏捷开发只是一知半解的水平（当然，我们都确定外方团队也好不到哪里去）。某一天，国外的 PM 突然发来几个链接，一看讲的是一个闻所未闻的词，就是 Scrum 了。好像就给了一两天的时间去看 Scrum 的介绍文档，然后就开 Stand-up Meeting（站立会议）。其实大家都知道沟通进度的重要性，但我们双方 7、8 个小时时差，那边一上班这边就快收拾东西走人了，就这样还要讲自己今天要做些啥，遇到啥困难，一点意思都没有。而且最关键的问题在于双方文化差异，语言差异，还有项目的整体规划协调。很快 Stand-up Meeting 就成了形式。后来，我们又间歇性地在自己团队内部做 Standup，但最后还是因为不能带给我们太大价值，流于形式，就放弃了。

再 说其他方面，我们没有计划会议，有名义上的 Product Owner，但是他不跟我们解释每一个 Story 具体的细节，也不说如何定义这个 Story 的完成状态。我们自己搞过 Retrospective（回顾），但总结出来的看法反馈到那边就没动静，后来也不做了。在第一次使用 ScrumWorks 的时候，好歹 Product Owner 还能来设置优先级，我们估算时间，最后决定哪些故事放到下一个 Sprint 里面。到后来就只要是人，就能往 Scrumworks 上扔任务，也不 知道哪些重要哪些不重要，我们自己开发人员看着办，最后剩下几百个小时完不成再扔到下一个 Sprint 里面去。后来公司里又搞 CMMI 认证，把我们项目作为 Pilot（试验），名义上是改善流程，但实际做法就是为了应付拿证，那就是一强制推行啊，把人搞得想辞职的心都有了。这个项目中间发生的事情太多了，反正磕磕碰碰的还在往前走，但现在我听见公司里有人提到敏捷就犯恶心。

小结

刚整理完这些资料，就在敏捷中国上看到在有关“敏捷测试”的话题中又出现了对“何谓敏捷”的讨论。忽然就想起了席慕容的一句诗：“生命原是要不断地受伤和不断地复原世界仍然是一个在温柔地等待我成熟的果园”。希望这篇文章可以让尚未接触敏捷实践，或者在推广敏捷实践特别是 Scrum 中碰到困境的读者有所收获。