最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。
尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。正如Mike Cohn（《敏捷估计与规划》和《User Stories Applied for Agile Software Development》的作者）在《Scrum and XP from the Trenches》一书的代序中所说的：“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。 出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：
姓名（职务） 璎珞天色，负责过程改进 kaverjody，Scrum Master David，Engineer 张汉东，Scrum Master 公司性质 某知名大型互联网公司 实施方式 自底向上 实施时间 2006年3月 2005年12月 2007年11月 结果 成功 某知名大型软件企业 某知名大型互联网公司 Nibirutech，创业型公司 自顶向下 自顶向下 全面推进 自顶向下 成功 失败 成功 失败 赵师容，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中碰到困境的读者有所收获。
因篇幅问题不能全部显示，请点此查看更多更全内容