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

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

我在07年10月份到NibiruTech的时候，初次接触敏捷。当时团队内部普遍的敏捷做法是每天按时召开的例会。当时我不太明白这个例会有什么作用？一直到11月底，强烈的好奇心让我想搞清楚这个问题。于是我找到了Scrum。因为创业团队嘛，刚开始项目管理方面只是用Trac和我们公司自己写的管理系 统。Scrum先进的思想让我们当时的管理现状黯然失色。于是我就决心在公司推广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继续走下去。异地的配合方式，工具，流程等建设中……）

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

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

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

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

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

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

1. “需求太模糊，造成后期开发沟通成本巨大，反复和产品经理沟通花了太多时间。”
2. “发布周期太长，一个Sprint要做3、4周才能上线，产品经理希望每周都能上两次线。”
3. “由于Scrum过程的特点，我们不能很系统地把握历史需求和整个产品的架构。”
4. “上线时间被业务拍死了，哪儿有时间做单元测试，连代码Review的时间都挤不出来。”
5. “目前的Backlog，人和人之间的协调，任务之间的瓶颈什么的都看不大清楚。”
6. “需求上线，至少1周才能分析数据看结果，没法在这个Sprint一做完就提出新的改进方案。”
7. “开发节奏太快，产品开发测试都没有时间停下来仔细考虑，历史需求没有善加利用。”

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

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

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

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写到看板上。这样有个好处，就是激发团队成员的自我管理意识，从而增进团队的自组织能力。

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

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

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

我们的问题在于，有些高层错误理解了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（试验），名义上是改善流程，但实际做法就是为了应付拿证，那就是一强制推行啊，把人搞得想辞职的心都有了。这个项目中间发生的事情太多了，反正磕磕碰碰的还在往前走，但现在我听见公司里有人提到敏捷就犯恶心。