Scrum方法在中国的应用文档格式.docx
《Scrum方法在中国的应用文档格式.docx》由会员分享,可在线阅读,更多相关《Scrum方法在中国的应用文档格式.docx(9页珍藏版)》请在冰豆网上搜索。
自底向上
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继续走下去。
异地的配合方式,工具,流程等建设中……)
主要是自顶向下。
我们的组织太大,这样的决策权只有顶层管理人员具有。
路线嘛,可以说是自顶向下和自底向上相结合。
我把资料拿给我们的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.“开发节奏太快,产品开发测试都没有时间停下来仔细考虑,历史需求没有善加利用。
对于所遇到的最大困难,我认为是同事们对于敏捷开发的不了解甚至误解,以及只看到具体使用的工具和采用的开发实践等,而没有正确领悟到这些决定之后的那些考虑,即为什么要选择这些工具?
为什么要采用这些开发实践?
选择的标准是什么?
选择的过程中才涉及到或者说真正体现出敏捷提倡的那些价值等。
而解决这些问题没有一蹴而就的办法,只能持续地进行教育工作。
一方面从理论上进行灌输,并通过长期的讨论来回答同事的问题,来消除大家的不安,另一方面,在遇到困难,或出现问题之后,及时地分析并解决难题,然后以此为案例向大家解释为什么要这样解决,以后再遇到这样的问题要怎么处理。
顺利开展实施前的最大的困难有两个:
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张图下来:
我很难在这方面做出一些总结。
我所看到的收益包括,更快地获得某些功能的使用反馈,更早地发现一些如多站点开发会出现的问题,更多的机会来发现团队之间合作的问题,并进行反思和改进。
工程师在某些软件开