Scrum方法在中国的应用.docx
《Scrum方法在中国的应用.docx》由会员分享，可在线阅读，更多相关《Scrum方法在中国的应用.docx（9页珍藏版）》请在冰豆网上搜索。
Scrum在中国——企业实施情况调查实录
最近，InfoQ中文站就Scrum实施情况对国内一些企业的相关人士进行了问卷调查。
从调查结果中我们选出了5个比较有代表性的案例，其中既有来自大型企业的，也有来自创业型公司的；既有采取自底向上的实施方式的，也有自顶向下实施的；有成功，也有失败。
尽管这仅仅是一个小范围调查，每个企业的具体情况也不尽相同，而成功案例所讲述的做法仅能说明在具体情况下使用者认为最合适的某种实施方式，（实际上，他们的做法都是迥异的），但通过了解其他人如何实施Scrum（无论成功也好，失败也罢），我们都可以从中汲取营养。
正如MikeCohn（《敏捷估计与规划》和《UserStoriesAppliedforAgileSoftwareDevelopment》的作者）在《ScrumandXPfromtheTrenches》一书的代序中所说的：
“我们应该了解的是哪些是优秀的实践，它们的应用范围是什么……在读过足够多成功团队的实践经验以后，你便会做好充分的准备，来面对实施Scrum和XP的过程中将会遇到的艰难险阻”。
出于保护企业和个人隐私的缘故，大部分被采访人的具体信息均已隐去，其名单如下：
姓名（职务）
公司性质
实施方式
实施时间
结果
璎珞天色，负责过程改进
某知名大型互联网公司
自底向上
2006年3月
成功
kaverjody，ScrumMaster
某知名大型软件企业
自顶向下
2005年12月
成功
David，Engineer
某知名大型互联网公司
自顶向下
失败
张汉东，ScrumMaster
Nibirutech，创业型公司
全面推进
2007年11月
成功
赵师容，SeniorEngineer
某创业型公司
自顶向下
失败
在交流中谈到的主要问题包括：
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这个说法拿出来。
就是首先和业务一起商量什么时候上线，商量出来的结果是每个月定期上线。
于是就有了一月一个项目的进度（我们是线上服务，没有版本的概念，有一堆需求过来，对技术来说就是在这一个月以内完成这些需求，把这一个月以内的工作叫一个项目）。
然后为了管理，我们开始开晨会。
然后为了改进，我们开始开项目总结会，把Productreview和Teamretrospective放在一起，既有产品经理介绍现状，也有大家讨论成绩，不足和挑战。
后来总结会上觉得质量不好，我们加入了单元测试和代码Review机制。
至于计划会议，一开始我们就采用的Scrum的方法。
项目小，MSProject太难调。
我们就更换了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：
我很难在这方面做出一些总结。
我所看到的收益包括，更快地获得某些功能的使用反馈，更早地发现一些如多站点开发会出现的问题，更多的机会来发现团队之间合作的问题，并进行反思和改进。
工程师在某些软件开
升级会员 