代写平台-奥鹏代做作业-电大作业代做-国开代做作业-奥鹏作业答案
  • 代做作业
  • 代做奥鹏作业

您当前所在位置:首页协会动态协会动态

案例正文:西安NE公司敏捷开发过程优化

作者:正规代写网  来源:本站  发表时间:2021-10-13  点击:14 cms

奥鹏作业答案,代做林肯MBA作业,代写研究生作业,国开形考任务代做,代做电大形考任务作业,奥鹏代做作业

案例正文:

西安NE公司敏捷开发过程优化

近些年软件行业迅猛发展,软件市场需求不断扩大,这使得一些软件开发企业国际竞争力水平不断下降。为了适应快速变化的市场需求,越来越多的软件开发企业使用敏捷软件开发模式,因此,如何灵活高效的使用敏捷软件开发模式成为了业内的研究热点问题。本论文针对NE公司Scrum敏捷软件开发现状,分析其在使用Scrum敏捷软件开发模式中的问题,确定出问题要素并对问题要素进行评价,根据评价结果提出优化方案。

关键词:软件开发;敏捷;项目管理; Scrum

0 引言

NE集团成立于2001年,总部位于美国南加利福尼亚,在全球范围内拥有超过2,500名雇员,该集团于2007年12月落户于高新区西安软件园,系 NE集团在中国继上海、台湾、成都之后的第四个海外运营机构。面对因用户需求不断增加,软件的开发和维护成本也越来越高导致的“软件危机”,于2012年全面开展敏捷开发,小杨2013年加入西安NE公司,具体负责虚拟产品(如软件,服务,游戏等虚拟产品)的后台管理系统的开发(包括EDI技术)。在运用敏捷开发思想,使用Scrum过程中,小杨感觉在开发team中实施效果并不理想,项目过程中总是问题不断,诸如延期、online bug、开发测试之间的矛盾等问题层出不穷,不知是水土不服还是敏捷开发实施不到位,各种问题一直持续不断并且好像无法解决一样。百思不得其解之后,小杨就向项目经理申请将此问题作为他MBA论文选题,借助MBA就读学校资源及师资力量完成对敏捷开发的问题诊断。

1 西安NE公司开发现状

    NE公司在2010年通过了CMMI L4 评估,截止2012年NE公司的软件开发模式都是遵循传统的软件开发模式,在NE集团正规传统的软件开发模式的大力扶持下虽然短短5年时间 ,NE西安的软件开发模式也快速形成。随着业务的不断复杂,系统维护成本的急剧增加,NE集团意识到传统的软件开发方法已经有些捉荆见肘,随后于2012年NE集团开始引进新型的软件开发模式,即Scrum敏捷软件开发模式在各个分公司大力推广,其中就包括NE公司西安技术支持中心。

   NE公司西安技术支持中心ESD团队是随着公司业务的扩展于2011年新成立的团队。团队成员最长工龄为5年,大多数都是一两年的新人。其前身是EDI(电子数据交换)团队,主要应对的业务就是与供货商进行无纸化电子数据交换,完成从下订单,到发货,到货款结算等一系列动作。 EID团队正是一个标准的传统软件开发团队,ESD团队则在EDI的基础上进行了业务扩展,销售一切虚拟的电子产品,即在NE公司没有存货的一系列电子产品,如软件,游戏,数据恢复服务等。

    ESD团队成立的初期,也是遵循标准的传统软件开发模式,但随着公司推广Scrum敏捷软件开发的进行ESD团队也逐步转变为敏捷团队,在开发模式转变的同时也承接成都等地移交过来的项目,所以团队总体业务成熟度低,尤其面对移交项目的修改,出错概率大。

自从NE公司实施Scrum以来,西安的Scrum团队能接触到的项目干系人只有产品负责人,产品负责人通过和客户确认需求,并建立用户故事,排出优先级,并负责向Scrum讲解用户故事。西安Scrum团队分解用户故事给出一个Sprint能完成的工作,并进行实施。在一个Sprint即将结束的时候,向产品负责人展示一次产品功能,确保产品的完整性和正确性。在Sprint的过程中,首先进行项目启动会议,产品负责人通过语音视频设备向团队成员介绍用户故事,团队成员在对用户故事进行分析后,由团队中的开发人员给出开发时间估算,测试人员给出测试时间估算。根据现有经验在一个Sprint过程中开发测试估算的时间基本对半分配。估算完成后由团队成员中的开发人员写出需求文档,通过需求评审后,Sprint正式开始,团队中的开发人员进行代码编写,测试人员进行测试用例编写,在Sprint结束后,完善在线文档(公司要求的文档管理系统),进行回顾会议。NE公司Scrum软件开发流程如图1所示。

 

1 NE公司Scrum软件开发流程

 

根据自己的经验,小杨认为,NE公司Scrum过程中有许多问题,如产品负责人的参与程度不高,没有优秀的Scrum Master,缺少自动化测试工具等,但最大的问题在于生搬硬套了Scrum框架,并未遵循Scrum的原则,在每一个Sprint中分为开发,测试两部分,以详尽的文档交流为主,沟通为辅,这种模式实则是在Scrum的框架下,在每一次Sprint中下进行传统瀑布开发,所以在需求多变,时间紧迫的情况下测试开发的压力都比较大。当然分析问题不能仅凭个人猜测,应该集思广益,尤其是需要采纳当事人的想法和意见,这样才能不失偏颇的分析问题,解决问题。

2. NE公司实施过程问题诊断

为了能够确定NE公司Scrum实施过程中问题所在,小杨与项目经理及项目组成员确定调研方案,并积极与消防指导老师沟通,确定采用Delphi法进行问题识别。

首先,选取被调研对象。选取的专家需要具备四个条件,即,必须为NE公司在职员工。经历NE公司Scrum实施过程,工作年限在5年以上。熟悉公司业务流程。有基层开发或测试经历。基于以上原则选取的专家为NE公司7个团队的7位团队负责人和7位测试负责人及每个团队选出一位资深Scrum Master,共计21人。为了使参与调查者能全面快速的了解NE公司现行Scrum实施过程的相关数据,增加发现问题的准确性,准备了NE公司现行Scrum流程积累的数据背景资料,从开始实施Scrum的项目中选取7个项目,分别统计出质量,客户满意度,本地bug率,线上bug率等数据供专家参考。

经过3轮专家问卷调查,结果见表1,归纳总结出NE公司Scrum实施过程中的问题,主要集中在5个方面,即沟通、业务成熟度、测试、Scrum流程、环境。而在这5个方面下总结出的问题共计14个,即与BSD沟通、开发测试沟通、开发和Master沟通、业务复杂、项目移交、人员离职、回归测试、程序发布、文档缺陷、任务拆分、需求变动、Scrum认知、系统环境、测试环境。

1 第三次问卷调查结果表

方面和

问题

沟通



业务成熟度



测试



Scrum流程



环境



BSD沟通

开发测试沟通

开发和Master沟通

业务复杂

项目移交

人员离职

回归测试

程序发布

文档缺陷

任务拆分

需求变动

Scrum认知

系统环境

测试环境

专家人数



13

16

3

9

16

15

18

12

12

15

18

18

12

9

所占比例

0.619

0.762

0.143

0.429

0.762

0.714

0.857

0.571

0.571

0.714

0.857

0.857

0.571

0.429

0.508

0.635

0.667

0.810

0.500

小杨和他们的项目团队就调查结果进行反思,为什么在国外使用有效的Scrum敏捷开发在NE公司的实施就多灾多难呢?经过大家的不断探讨,才认识到:Scrum敏捷开发本身只是一套方法论,并不是一套实施准则,所以每个公司在实施Scrum过程中运用的方法不同,所面临的问题也不同。针对NE公司Scrum实施过程中出现的问题可以看出,NE公司Scrum实施过程只是套用了方法论本身,而没有领会Scrum的精髓,例如,在沟通方面出现了不少问题,这直接有悖于Scrum核心思想即“个体与交互胜过过程与工具”,“客户协作胜过合同谈判”;在Scrum流程方面的需求变动问题,直接体现了NE公司没有领会Scrum核心思想即“响应变化胜过遵循计划”;而在测试方面的文档缺陷问题更是指出NE公司只是生搬硬套Scrum方法论。Scrum核心思想中的“可以工作的软件胜过面面俱到的文档”,只是说可运行的交付物重要,但并不是说文档不重要,错误的理解Scrum核心思想是NE公司Scrum实施困难的核心问题之一。

3. NE公司Scrum软件开发过程要素评价

根据专家调查问卷结果,小杨针对NE公司Scrum实施过程中五个主要问题,包括沟通、业务成熟度、测试、Scrum流程和环境,在与各项目经理进行充分交流沟通的情况下,确定了NE公司Scrum实施过程出现问题的问题和因素两个层次,识别出14个因素。如图2所示。

2 NE公司Scrum实施过程中的问题

面对这样的层次结构问题,如何确定改进过程中的关键问题,这是需要使用合适的研究方法方可解决的问题。为此,小杨请教了他的MBA导师。

老师告诉他,这是一个典型的系统评价问题,而且是一个层次结构模型,适于用层次分析法来确定各要素的权重,对要素进行排序,就可以确定这些问题的主要原因,从而便于优化开发流程。

为此,小杨邀请NE公司7位资深PM对NE公司Scrum过程中出现的问题进行对比打分,在进行对比打分时要求各位PM结合自身多年的Scrum实施经验对底层要素之间的重要程度进行打分,建立判断矩阵。使用AHP法进行评价,得到评价结果(见表2)

2 总排序权重表

 

 

A1(沟通)

A2(业务成熟度)

A3(测试)

A4(Scrum流程)

A5(环境)

因素层总排序权重

0.378

0.248

0.080

0.121

0.174

F1(BSD沟通)

0.215

0.046

0.019

0.024

0.018

0.1002

F2(开发测试沟通)

0.093

0.014

0.1

0.061

0.057

0.0639

F3(开发和Master沟通)

0.043

0.012

0.01

0.039

0.032

0.0303

F4(业务复杂)

0.139

0.091

0.042

0.034

0.104

0.1007

F5(项目移交)

0.075

0.128

0.068

0.028

0.063

0.0799

F6(人员离职)

0.053

0.128

0.068

0.046

0.018

0.0659

F7(回归测试)

0.084

0.094

0.153

0.106

0.168

0.1094

F8(程序发布)

0.023

0.019

0.047

0.033

0.101

0.0387

F9(文档缺陷)

0.066

0.215

0.244

0.04

0.036

0.1089

F10(任务拆分)

0.013

0.02

0.03

0.144

0.023

0.0337

F11(需求变动)

0.062

0.129

0.033

0.106

0.066

0.0824

F12(Scrum认知)

0.062

0.02

0.013

0.19

0.031

0.0578

F13(系统环境)

0.041

0.021

0.031

0.063

0.105

0.0491

F14(测试环境)

0.031

0.062

0.143

0.087

0.177

0.0799

按总排序结果权重值,可以将NE公司Scrum实施过程中的问题分为三个层次,如图4.2所示。

3 NE公司Scrum实施问题权重层次图

NE公司Scrum实施过程中的问题来看,问题主要分布在4个方面即测试,文档,业务,沟通,而每一个方面又有诸多要素,且每一个问题要素的权重不同,例如在测试方面就有三个问题即回归测试、测试环境、系统环境,分属三个不同层次,所以要进行流程优化,需要从四各方面入手。

4.NE公司Scrum软件开发过程优化

在经过一系列的研究后,小杨与7个团队的7位团队负责人和7位测试负责人认真分析了评价结果,就现存的测试、文档、业务、沟通四个方面的具体问题确定了改进方案,如图4所示。

 

4 四方面问题改进图

(1) 测试方面

从调查结果可以看出,NE公司在测试方面最大的问题是没有自动化测试工具,造成测试工作压力巨大。即便一个小小的改动对回归测试来说也有巨大工作量,这样不仅影响项目工期,同时影响项目质量。

所以NE公司必须由敏捷委员会推动成立自动化测试工具开发小组,在每个业务部门中专门挑出有资深业务能力的测试开发人员,成立专项Scrum团队,开发完善自动化测试工具。自动化测试工具是基于NE公司的并非每一个业务部门一个这样可以防止在测试部门联合业务时出现问题。该测试工具不仅支持全公司,而且每一个业务也可单独使用于自己部门内部的程序。每当有新业务出现时,专项Scrum团队完善自动化测试工具,保证自动化测试工具随时可用。

当自动化测试工具框架基本完善后,再由每一个Scrum团队的测试角色编写测试脚本,维护测试脚本库。自动化测试工具每天定点运行,监控现有程序版本的质量,当自动化测试工具基本稳定后,则Scrum团队就可以从繁重的测试中解脱出来,真正关注现有功能的开发和修改。

(2) 文档方面

敏捷宣言中有句话:“可以工作的软件胜过面面俱到的文档”,这句宣言并非说文档不重要,而是说可工作的软件的重要程度胜过面面俱到的文档,在软件开发中文档的重要性不言而喻,无论在何种软件开发模式中文档都是非常重要的。

在传统的软件开发过程中文档在于传递信息,保留信息。如需求文档,设计文档等,它们不仅是开发过程中传递信息的工具,而且是日后软件改进的依据。在Scrum中传递信息方式是“沟通”,所以在每一个冲刺中文档只是辅助沟通的手段,任何能面对面沟通的信息,绝不用文档传递。所以文档的形式不限,方式不限。文档可以是个便条,可以是简单的记录,也可以没有,只要能满足团队成员间的沟通就行。但是为了日后系统的改进,新员工了解现有系统的需求,还是需要一份完整的文档保存信息,所以,在一个冲刺结束后,不用马上开始下一个Sprint,以预留一两天时间撰写文档,然后再开始下一个冲刺。在这预留的时间内Scrum团队成员的主要任务就是完成文档记录,并由Scrum Master监督文档质量,不要一份文档多个地方记录。将文档记录到NE公司Wiki(一个在线文档记录工具)上即可,这些文档包括数据库设计文档,需求文档,设计文档。注意文档记录任务并不在冲刺中,而是在冲刺的间隙中,这样不仅可以让团队成员不受打扰的完成文档,保证文档质量,而且可以帮助团队成员调整心态进入下一个冲刺,当然,有些文档在冲刺的过程中就可以产生,如数据库设计文档等,冲刺过程中的文档由Scrum团队成员自行决定其产出,如果为了日后记录wiki方便,也可提前产出。Scrum 主管最终只审查Wiki上的文档记录。

在文档方面改革后最终只会有一处地方记录完整文档即Wiki。但是,目前NE公司Wiki存在编写复杂,操作繁琐的情况,这样在文档维护上耗时费力,所以NE公司需要在最后的文档记录方面进行改革。可以修改现有wiki的记录方式。可以重新开发文档记录工具,或者直接购买现成的文档记录工具。无论哪种改变方式,最终的目的就是要便利快捷的进行文档维护工作。

(3) 业务方面

一个庞大的公司,必然有庞大的业务,而对程序而言,每一个细节都不能出错。所以在业务传承方面一般有四个方法,即保留完整文档;公司老员工带领新员工;公司业务培训;新员工自己摸索。显而易见,新员工自己摸索是最低效,最危险的方式,而其它三个方式单独一个并不能很好的传承业务,所以NE公司需要在保留完整文档的基础上,由公司进行整体业务框架培训,具体业务细节由老员工传授,再加上新员工的自己摸索,这样才能最大程度的进行业务传承,让新员工以最快的速度进入自己的角色。文档如何保留在上面文档部分已经说了,老员工带领要注意以下几个方面的问题。

1) Scrum团队中决不能出现有一块业务只有一个人员了解,而其他人员并不了解的情况。这是传统软件开发的特点,也是Scrum要重点攻克的问题之一。即团队所有的成员并非各司其职,而是围绕冲刺的最终目标共同努力完成每一个冲刺。

2) 新人进入Scrum团队后必然影响团队的成熟度。所以,首选,新员工前在试用期期间,第一个月了解公司的文化制度,最后两个月进入Sprint团队。注意新员工并非以Scrum团队正式成员身份进入团队,而是以参观者的角色进入Scrum团队。即,工时估算时不能考虑他。其次,Scrum 主管根据其特点安排任务,这些任务的目的在于让新员工了解Scrum团队工作模式,了解部门的业务细节。最后,每个月各部门进行一次部门业务培训,由部门业务专家进行部门业务讲解,参加人员可以积极提问,这样不仅对培养新员工有所帮助,并且可以增强各个Scrum团队对部门整体业务的理解,以便在出现特殊情况时可以从容支援。

3) 人员离职,国内大多数软件公司的现状是人员离职频繁,更有甚者是整个团队离职,正所谓“铁打的营盘,流水的兵”,这种现象目前无法解决。只要公司体制上是完善的,就不用担心人员离职带来的困扰。对于Scrum团队来说,人员离职是件很糟糕的事,所以需要培养Scrum团队成员全面性,统一公司Scrum模式,在个别团队成员离职后可以快速培养一个合格的Scrum团队成员。同时人力部门要采取措施,时刻注意,避免大批人员离职的情况。

对于“结对编程”这种敏捷手段,暂时不推荐,原因是,首先,结对编程必然造成成本上升,用这些上升的成本,提高现有员工的福利和积极性对于公司来说效果应该更好。其次,Scrum团队成员的目标就是共同努力完成每一次冲刺,所以就算采取结对编程,只是扩充Scrum团队体积罢了,当团队成员都比较成熟全面时,对公司业务传承来说已经够了,没有必要采用结对编程。

(4) 沟通方面

NE公司的沟通问题主要指产品负责人和Scrum团队的沟通,Scrum团队内部的沟通。产品负责人和Scrum团队的沟通由于NE公司的现状(地域限制和8小时的时差)基本不可能做到面对面的实时沟通。所以产品负责人同Scrum团队的沟通基本限于电话、即时通讯工具、邮件。所以在有限的时间内产品负责人和Scrum团队的沟通必须规范化标准化。

首先,根据时差情况找出公共时间。如每天早上8点到10点,这段时间是专属的沟通时间,必须排除一切干扰,进行沟通。为了使沟通效率最大化,可以在每天下班前以邮件的方式将第二天要沟通的内容发出,以便双方思考和准备。

其次,Scrum团队内部的沟通,由于NE公司之前是每个Script中嵌入小瀑布的开发模式,所以有传统开发模式沟通的弊病。即各司其职造成测试开发之间的责任推诿,开发间的缺少沟通。所以在优化Scrum框架后,Scrum团队成员之间没有责任之分,任务延时或失败就是整个Scrum团队的责任。团队成员之间面对失败的责任是同等的,面对成功的奖励是同等的,开发测试间再也没有先后顺序。用面对面的沟通取代了文档式交流,这样Scrum团队的沟通才能和谐,才能畅通。当然这样的责任制度需要很多保障措施,如绩效考核的优化,人员招聘的优化等。

5 Scrum开发优化过程保障措施

为了能够保障测试,文档,业务,沟通四个方面优化方案的顺利实施,NE公司确定了相应的保障措施,如图5所示。

 

5 NE公司Scrum保障措施图

1)人力资源管理

人力资源管理部门看似对NE公司Scrum软件开发影响不大,实则人力资源管理部门才是NE公司Scrum软件开发模式能否成功实施的重中之重。从NE公司现状来看,NE公司的现有人员显然对Scrum敏捷开发认知不够,其中包括Scrum 主管并且公司没有一个专门致力于Scrum改革的机制,如Scrum委员会。所以这就需要NE公司人力资源部门推动公司Scrum改革。

首先,招聘Scrum资深专家。由资深专家对试点Scrum团队进行指导,全力打造出一个标准的,完善的,熟练的,适合NE公司现状的Scrum团队。以此为种子进行扩散。

其次,定期组织Scrum培训,扩大Scrum的影响力。

最后,需要在招收人员方面进行设计。设计的主旨就是,如何排除和改变那些难交流,排斥Scrum的员工并且对于一些顽固不化的员工,需要采取强制措施。

2) 团队绩效考核

在人力资源采取措施的同时,绩效考核也必须跟进,否则可能造成大批员工离职的情况。

首先,在绩效考核方面,将KPI考核的重点落到团队上,实行奖金制度,对每一个产品,根据生产率,bug率,客户满意度等硬性数据进行排名奖励。降低个人的考核部分,提高团队考核比重。对于试点团队培养出来的种子员工,在其扩散Scrum的时候,根据其带领的Scrum团队硬性指标给予扩散者一定的绩效考核奖励。

其次,进行Scrum改革的初期,除了绩效考核的奖励外,需要提高员工的基本工资,工资不能低于同行业的中等水平。因为Scrum团队成员要求全面,这样对公司现有员工的要求必然提高,所以需要对应的回报予以支持。否则,Scrum可能在改革初期就夭折了。

最后,Scrum改革的尝试阶段,要允许犯错,在绩效考核上应该予以支持,对于Scrum改革初期和员工商讨绩效考核项,设立绩效最低保障,让员工安心的投入到Scrum改革中。

3)系统环境改善

“工欲善其事必先利其器”,无论是业务传承方面,还是自动化测试方面,都必须有良好的,统一的系统环境

首先,统一NE公司三种测试环境,包括部署目录,网络环境。,这样才能保证程序的部署和自动化测试过程中的问题,同时也能减少环境问题引起的线上bug。

其次,统一编码,目前NE公司有些业务部门编码工具繁多,这样不仅对Scrum成员技术掌握是种压力,而且对自动化测试的实施是强大的阻碍。所以需要进行平台改革,统一开发平台,尽量做到一种技术,一个平台来实现。这样对团队成员在Scrum实施上会有很大帮助,也有利于将一种技术做到极致。

最后,在上述两方面完成的基础上,寻找整个项目期间的重复工作,将一切可以自动化的工作都逐步转向自动化,如程序部署,发布等环节。

4) 领导层支持

任何改革都会遇到强大阻力,这时就需要领导层的全面支持。如上所述的各种保障措施,如果没有领导层的全面支持是无法实现的,尤其是牵扯到公司利益的事情,所以成立Scrum敏捷委员会并且成员都是公司高层的目的就在于此。缺少领导层的全面支持,Scrum的改革只会给公司带来灾难。

6.尾声

 软件开发行业竞争日趋激烈,能快速有效的应对市场需求的变化成为了企业竞争的重中之重。Scrum敏捷软件开发模式虽然可以快速的响应市场需求,但是,如果不能科学合理的使用这一模式,不仅不会给企业带来效益,还可能会增加软件项目失败的风险。NE公司在经历阵痛之后,突破生搬硬套敏捷软件开发模式,尝试改变软件开发过程,不断创新,在扩展敏捷开发模式视角的同时,进一步丰富敏捷开发理论知识,这不仅完善了敏捷软件开发模式的内涵,更扩展了敏捷软件开发模式的外延,对业内人士的研究提供了理论基础,对国内同行转型提供了指导作用。

 

(案例正文字数:7739)

 

Abstract:In recent years, software industry is developing rapidly, software market continues to expand, which makes some software enterprises international competitiveness level is declining. In order to adapt to the fast changing market demand, more and more enterprise software development using agile software development mode. Therefore, how to use agile software development model has become a hot issue in the field of research. In this paper, This thesis is aimed at the present situation of Scrum agile software development in NE company, analysis of the problem in using Scrum agile software development model, identify the elements of the problem and evaluate the factors . According to the evaluation results, the optimization scheme is proposed.

Key words: Software Development, Agile, Project Management, Scrum

Copyright Right © 2012 www.daixie119.com Powered By 专业奥鹏电大作业代做网-奥鹏作业代做-电大国开作业代做

地址:江苏省苏州市    电话:QQ:3148628365    传真:QQ:3148628365    邮编:362000
访问量:2136195
  • QQ咨询

  • 在线咨询
  • 点击这里给我发消息
  • 点击这里给我发消息
  • 点击这里给我发消息