1 / 9
文档名称:

方法计划在中国应用.docx

格式:docx   大小:151KB   页数:9页
下载后只包含 1 个 DOCX 格式的文档,没有任何的图纸或源代码,查看文件列表

如果您已付费下载过本站文档,您可以点这里二次下载

分享

预览

方法计划在中国应用.docx

上传人:泰山小桥流水 2023/2/20 文件大小:151 KB

下载得到文件列表

方法计划在中国应用.docx

文档介绍

文档介绍:该【方法计划在中国应用 】是由【泰山小桥流水】上传分享,文档一共【9】页,该文档可以免费在线阅读,需要了解更多关于【方法计划在中国应用 】的内容,可以使用淘豆网的站内搜索功能,选择自己适合的文档,以下文字是截取该文章内的部分文字,如需要获得完整电子版,请下载此文档到您的设备,方便您编辑和打印。优选文档
优选文档

芆虿
膃螀
节薄
袀莅
1
优选文档
Scrum在中国——企业实行状况检查实录
近来,InfoQ中文站就Scrum实行状况对国内一些企业的相关人士进行了问卷检查。从检查结
果中我们选出了5个比较有代表性的事例,此中既有来自傲型企业的,也有来创始业型企业的;
既有采纳自底向上的实行方式的,也有自顶向下实行的;有成功,也有失败。
尽管这不过是一个小范围检查,每个企业的详尽状况也不尽同样,而成功事例所表达的做法仅能
说明在详尽状况下使用者以为最适合的某种实行方式,(实质上,他们的做法都是迥异的),
但经过认识其余人如何实行Scrum(无论成功也好,失败也罢),我们都可以从中汲取营养。
正如MikeCohn(《敏捷预计与规划》和《UserStoriesAppliedforAgileSoftware
Development》的作者)在《ScrumandXPfromtheTrenches》一书的代序中所说的:“我
们应该认识的是哪些是优秀的实践,它们的应用范围是什么在读过足够多成功团队的实践经
验今后,你便会做好充分的准备,来面对实行Scrum和XP的过程中将会遇到的困难险阻”。
出于保护企业和个人隐私的缘由,大部分被采访人的详尽信息均已隐去,其名单以下:
姓名(职务)
企业性质
实行方式
实行时间
结果
璎珞天气,负责过程改进
某有名大型互联网企业
自底向上
2006
年3
成功

kaverjody,Scrum
某有名大型软件企业
自顶向下
2005

成功
Master
12月
David,Engineer
某有名大型互联网企业
自顶向下
失败
张汉东,ScrumMaster
Nibirutech,创业型企业
全面推动
2007

成功
11月
赵师容,SeniorEngineer
某创业型企业
自顶向下
失败
在沟通中谈到的主要问题包含:
在项目中使用Scrum的原由是什么?
在实行Scrum时采纳了如何的路线,为何这样做?
在实行时遇到的最大的困难是什么,你又是如何解决的?
实行Scrum今后,给项目、企业带来了哪些收益?
Scrum实行为何遭受失败?
?
璎珞天气:
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
需求变化太快;产品路线图不明;提升效率;加强沟通;赶忙让业务部门看到结果。
kaverjody:
因为当前组织中使用的瀑布开发模型所固有的一些缺点,以及我们研发部门当前的一些问题,沿
用当前的方法无法有效地解决问题或改变现状。上层经过研究论证后决定采纳Scrum模式,同
时经过其余的一些手段辅助,来解决当前的这些问题。包含交付新的软件公布版本时间太长、软
件保护效率低成本高,等等。
张汉东:
我在07年10月份到NibiruTech的时候,首次接触敏捷。当时团队内部广泛的敏捷做法是每
天准时召开的例会。当时我不太理解这个例会有什么作用?向来到11月尾,激烈的好奇心让我
想搞清楚这个问题。于是我找到了Scrum。因为创业团队嘛,刚开始项目管理方面不过用Trac
和我们企业自己写的管理系统。Scrum先进的思想让我们当时的管理现状黯然失色。于是我就
信心在企业推行Scrum。
,为何这样做?
璎珞天气:
我们不是采纳纯粹的Scrum,而是将Agile中的很多理念,包含XP的部分做法,而后结合现
有的开发环境与要求,用Scrum的回顾不停地做改进,从而趟出自己的一条路。假如这个Sprint
我们回顾时感觉自己代码Review(审察)做的不好,下个Sprint就会引入新的代码Review
体系。这个Sprint感觉重复性的bug许多,下个Sprint就会引入缺点预防体系。
我们是自底向上,先做小范围试点,再全面推行,中间对过程进行千锤百炼:
年3月——06年6月(1个团队,8人左右采纳)
年6月——07年12月(3个团队,25人左右采纳)
07
年12月——08
年1月(一个部门,6
个团队,50人左右采纳)
08
年1月——到现在(异地开发,原有团队的
Scrum连续走下去。异地的配合方式,工具,流
程等建设中)
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
3
优选文档
kaverjody:
主若是自顶向下。我们的组织太大,这样的决策权只有顶层管理人员拥有。
张汉东:
路线嘛,可以说是自顶向下和自底向上相结合。我把资料拿给我们的CEO看了,同时也把资料
发散给同事来看。至于为何用这类路线推行,我当时不过抱着一心想把好东西给大家分享的心
态,其实也没想那么多路线。
随后笔者又向璎珞天气发问道,“在试点时是如何的实行过程?是针对项目的详尽问题,逐渐采
用各种敏捷实践来加以解决?还是先给团队做培训,介绍敏捷开发的理论实践,而后推行?”,
她回答说:
其实我们一开始并无把
Scrum
这个说法取出来。就是第一和业务一起商议什么时候上线,商
量出来的结果是每个月按期上线。
于是就有了一月一个项目的进度
(我们是线上服务,没有版本
的看法,有一堆需求过来,
对技术来说就是在这一个月之内完成这些需求,
把这一个月之内的工
作叫一个项目)。而后为了管理,我们开始开晨会。而后为了改进,我们开始开项目总结会,把
Productreview和Teamretrospective
放在一起,既有产品经理介绍现状,也有大家谈论成
绩,不足和挑战。今后总结会上感觉质量不好,我们加入了单元测试和代码
Review体系。至
于计划会议,一开始我们就采纳的
Scrum
的方法。项目小,MSProject
太难调。我们就更换
了Scrum的Excel计划表,今后又换了
Xplanner。
就这样走了几个月后,我们把大家叫到一起,开了一个Agile方法分享会。把大家从前实践总结
一下,而后告诉大家,我们的做法就叫做Scurm,并且它是很有名的哦。而后再把XP、Agile
和Scrum都给大家系统讲一遍。于是大家恍然大悟,本来我们是在走Scurm啊~~~~!!!
同时这个项目组的成绩也获取了高层认同,高层也以为效率提升了。于是让这个团队给四周的团
队做分享。并挑几个团队开始试行。因为我们团队成员可能会有轮岗和互调,一个团队使用Project,一个团队使用Xplanner,有时员工也难以上手。为了部门管理一致,方法一致,工
具一致,最后高层命令所有实行Scrum。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
4
优选文档
,你又是如何解决的?
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
璎珞天气:
第一应该解决领导的问题,解决方式就是拍晕他。拍的方式,一言难尽啊。至于接下来,说真话,
我感觉推Scrum这类方式还是很简单推的,但是是一种管理理念。比当年推CMMI那种东西很多了。最困难的是你要不停解决裸露出来的问题。比方说,以下这些呼声:
1.
“需求太模糊,造成后期开发沟通成本巨大,屡次和产品经理沟通花了太多时间。

2.
“公布周期太长,一个Sprint要做3、4周才能上线,产品经理希望每周都能上两次线。

3.
“因为Scrum过程的特色,我们不可以很系统地掌握历史需乞降整个产品的架构。

4.
“上线时间被业务拍死了,哪儿有时间做单元测试,连代码
Review的时间都挤不出来。

5.
“当前的Backlog
,人和人之间的协调,任务之间的瓶颈什么的都看不大清楚。

6.
需“求上线,最少
1周才能解析数据看结果,无法在这个
Sprint一做完就提出新的改进方案。

7.
“开发节奏太快,产品开发测试都没有时间停下来仔细考虑,历史需求没有善加利用。

kaverjody:
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
6
优选文档
对于所遇到的最大困难,我以为是同事们对于敏捷开发的不认识甚至误会,的工具和采纳的开发实践等,而没有正确领悟到这些决定以后的那些考虑,

以及只看到详尽使用
即为何要选择这些
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
工具?为何要采纳这些开发实践?选择的标准是什么?选择的过程中才涉及到也许说真切表现出敏捷倡议的那些价值等。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
而解决这些问题没有一蹴而就的方法,只好连续地进行教育工作。一方面从理论长进行灌输,
经过长远的谈论来回答同事的问题,来除掉大家的不安,另一方面,在遇到困难,或出现问题之
后,及时地解析并解决难题,而后以此为事例向大家解说为何要这样解决,今后再遇到这样的
问题要怎么办理。


优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
张汉东:
顺利睁开实行前的最大的困难有两个:
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
。我想这应该是个公共问题。但是下而上的敏捷推行策略)也说了,假如高层其实不支持

InfoQ
Scrum

头几日有篇文章(渐进式敏捷:由,那么就障蔽高层,在团队内部开
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
展就行。幸亏我们

CEO



CTO

都比较支持

Scrum


优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档


Scrum

培训。同事对

Scrum

都不太认识,于是我组织了一次

Scrum

培训,来
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
给大家介绍Scrum里的规则,角色及Scrum集体谈论。在谈论的过程中,让大家临时认识什么是慢地对Scrum的规则熟****了。自然前提是推行

的特色和它要解决的问题。大家都把疑问取出来
Scrum。而后在实行的过程中,大家就慢
Scrum的这个人,要对Scrum比较理解。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
14
优选文档
以上两个问题在我这其实也不算是困难,因为我推行
Scrum的过程中几乎很顺利,大家都很支
持我的工作。实行的时候基本也没有什么困难,
很好上手。可能和我们用来试试
Scrum的项目
相关。客户已经把backlog写成了Tickets
发给我们,而后从接受那些
Ticket
算起,到客户要
求的交工时间为一个迭代期,没有超出30
天。这些待做事项基本是优先级等同的,团队内部自
己优选能做的Ticket
,而后每日例会大家都严格回答
Scrum里的三个问题,保持团队的一致。
评审会议也是严格依据
Scrum
的规则来做。因此临时没有什么问题。我想下一个
Scrum试试
项目中可能会遇到细化需求拟定
backlog
的问题,也许可以让客户把优先级排好,也许说帮助
客户和客户一起把需求细分出来,
排好优先级,而后在优先级的驱动下,
美丽地完成我们的每个
迭代。
接着,笔者又请大家对某些详尽困难的解决方法进行深入介绍,璎珞天气说:
对应第一个需求模糊的问题,我们的做法是对需求文档一致模板,在计划会议前增添了需求谈论
会,产品、测试和开发三方都参加;
第二个公布周期长的问题,我们在项目公布以外,还增添了对平常保护需求的管理方法。每周二
和周四上班从前,产品经搭理汇总所有保护性的小需求,比方页面更正,数据增删等。周二和周
四晨会上提交给负责公布的工程师。周二和周四的下午,会集中公布这些小需求;
第三、四个问题,无药可救,按期重构,业务第一,不做单元测试,只做代码Review。
张汉东说道:
我们企业当前实行Scrum的状态可以说是比较顺畅。所谓的顺畅,也许也包含我自己对Scrum
理解不太深入,不过抓着一些自己理解的皮毛来加以应用。但我对敏捷的认知,对Scrum的认
知就是那么一条,不停地迭代,不停地成功和失败,找到属于企业自己的Scrum。在有一个项
目里,因为需求不太明确,因此在sprint计划会议拟定backlog时,粒度控制不是很好。我们
的做法是,依据已知的需求先把要实现这个迭代的整体技术步骤列出来,以实现次序做为优先
级我们的迭代期很短,此次是10天。这样大概就可以在整体上掌握项目的进度了。而后在
每日的每日例会上大家都会有计划地把今日要做的Item写到看板上。这样有个好处,就是激发
团队成员的自我管理意识,从而增进团队的自组织能力。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
、给企业带来了哪些收益?
璎珞天气:
说不上,很难去胸襟是Scrum给企业带来的收益。说真话,我感觉Scrum所能带来的收益是
无法胸襟的。我们只好经过检查问卷的方式,去感性地得出它所带来的好处。我们的方法是检查
问卷,截2张图下来:
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
16
优选文档
kaverjody:
我很难在这方面做出一些总结。我所看到的收益包含,更快地获取某些功能的使用反响,更早地发现一些如多站点开发会出现的问题,更多的机遇来发现团队之间合作的问题,并进行反思和改进。工程师在某些软件开发实践和技术方面的能力评估和增添需求(非正式评估,是在不停的开发过程中大家所感觉到的能力)更加清楚明确。
张汉东:
我们整个企业此刻采纳Scrum式的管理,如开发部门,销售部门及HR部都会遵守Scrum规
则。因为我们也是首次试试使用Scrum,因此大家都严格遵守规则。有新人进来的时候,也没
有马上给新人讲解Scrum的看法,不过让他在平常的工作中,慢慢****惯Scrum规则。企业暂
时完成了两个Sprint试试,收益不敢说有多大,最少让我们每一个人每日的工作都很有目标感,
让我们在客户所规定的限期里完成了那个迭代。我们正在准备启动下一个Scrum开发项目。总
的来说,一句话,我们也是在Scrum的试试中。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
17
优选文档
?
David:
我们的问题在于,有些高层错误理解了Scrum和Agile,以致歪曲了某些东西,使得Agile变
得形式化。举个简单的例子,当时的ScrumMaster负责一个大项目的开发,走的比较顺利,
而后有个项目经剪发现这个东西挺好,就单独把DailyScrum拿来进行推行;结果,这个经理
其实不理解什么是Scrum,他把DailyScrum变为了DailyReport,而其余Scrum的精华部
分都没有推行。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
18
优选文档
每个员工都要在清早固准时间开DailyScrum,而后把当日的任务告诉给他,让他来决定工作是否是饱满。这个把弹性工作制直接给破坏了,引起很多人厌烦;另一点就是很多人以为这样的DailyReport太屡次太低效,并且还有压迫员工的嫌疑。因此逐渐大家谈起DailyScrum都是恶心的不得了,于是经理也识相地撤消了DailyScrum,再到今后在企业内部就没有人谈


优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
什么

Agile

了。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
赵师容:
我们是分布式开发,
当时中方的团队对于敏捷开发不过一孔之见的水平
(自然,我们都确立外方
团队也好不到哪里去)
。某一天,外国的PM突然发来几个链接,一看讲的是一个闻所未闻的词,
就是Scrum了。忧如就给了一两天的时间去看
Scrum的介绍文档,而后就开
Stand-up
Meeting(站立会议)。其实大家都知道沟通进度的重要性,但我们两方
7、8
个小不时差,那
边一上班这边就快整理东西走人了,
就这样还要讲自己今日要做些啥,
遇到啥困难,一点意思都
没有。并且最要点的问题在于两方文化差异,语言差异,还有项目的整体规划协调。很快
Stand-upMeeting
就成了形式。今后,我们又间歇性地在自己团队内部做
Standup,但最后
还是因为不可以带给我们太大价值,流于形式,就放弃了。
再说其余方面,我们没有计划会议,有名义上的ProductOwner,但是他不跟我们解说每一
个Story详尽的细节,也不说如何定义这个Story的完成状态。我们自己搞过Retrospective
(回顾),但总结出来的看法反响到那里就没动静,今后也不做了。在第一次使用ScrumWorks
的时候,好歹ProductOwner还可以来设置优先级,我们估量时间,最后决定哪些故事放到下一
个Sprint里面。到今后就只若是人,就能往Scrumworks上扔任务,也不知道哪些重要哪些
不重要,我们自己开发人员看着办,最后剩下几百个小时完不行再扔到下一个Sprint里面去。
今后企业里又搞CMMI认证,把我们项目作为Pilot(试验),名义上是改进流程,但实质做法
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
就是为了对付拿证,那就是一强迫推行啊,把人搞得想辞职的心都有了。这个项目中间发生的事
情太多了,反正磕磕碰碰的还在往前走,但此刻我听见企业里有人提到敏捷就犯恶心。
小结
刚整理完这些资料,就在敏捷中国上看到在相关“敏捷测试”的话题中又出现了对“何谓敏捷”的谈论。突然就想起了席慕容的一句诗:“生命原是要不停地受伤和不停地复原世界依旧是一个在温柔地等候我成熟的果园”。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
22
优选文档
希望这篇文章可以让还没有接触敏捷实践,

也许在推行敏捷实践特别是

Scrum

中遇到困境的读者
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档
有所收获。
优选文档
优选文档

芆虿
膃螀
节薄
袀莅
9
优选文档