赞
踩
思维导图:
在软件开发的早期阶段,人们开发软件是没有模型
、方法
、流程
的,这样会导致产出的软件产品质量很难控制,人们为了解决这些问题,发展出了软件工程
、开发方法
、开发模型
。随着开发方法的不断升级,规范程度不断提高的时候,人们发现,在开发软件的过程中按照某些重量级的开发模型
去开发,往往是得不到很好的效果的,因为重量级的开发模型
往往更加关注于文档
、流程
,通过这些方式来规范你的开发,这样一来我们会发现开发人员的负担会越来越重,而产生的大量的文档
、流程
并不一定能够真正的用的上,所以花了很多时间,但是最终做出来的东西却并一定好。
所以有人就提出来,要给开发人员减负
,那么怎么减负呢?就是把一些没有必要的流程
砍掉,把没有用的文档
减去。这样就形成了敏捷开发的基本思想。
值得注意的是敏捷开发模型
并不是一个模型,而是一组模型
,它包含有:
这些模型有着共同的价值观
、原则
、思想
和理念
,甚至很多最佳实践
也是保持一致的
我们应该重点学习敏捷开发模型
的一些基本原则
和价值观
敏捷开发(Agile Development)是一种
以人为核心、迭代、循序渐进
的开发方法。怎么理解呢?首先,我们要理解它不是一门
技术
,它是一种开发方法
,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人
;它采用的是迭代式开发
;
我们大部分人都学过瀑布开发模型,它是以
文档
为驱动的,为什么呢?因为在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发
的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间
,面对面的交流
,所以它强调以人为核心。
迭代是指把一个复
复杂
且开发周期很长
的开发任务,分解为很多小周期
可完成的任务,这样的一个周期就是一次迭代的过程
;同时每一次迭代都可以生产或开发出一个可以交付的软件产品
Scrum的英文意思是橄榄球运动的一个专业术语,表示
争球
的动作;把一个开发流程的名字取名为Scrum
,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作
- 产品负责人(Product Owner)
主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果
- 流程管理员(Scrum Master)
主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发
- 开发团队(Scrum Team)
主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标
1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;
4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);
5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);
6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;
7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
对于一些大型的机构,开展项目的会议会比较多,而会议又比较耗时,这样往往会消耗软件开发人员的大量时间,对于软件开发项目而言,最重要的资源就是人力资源
,如果把人力资源用来开过多的会议,往往会降低效率。短平快的会议
的核心思想就是,将过多的没有必要的会议
砍掉,将仅用来传达指令的会议用其他形式代替,将现有的会议缩短
,甚至是站立式的会议
,以达到控制时长
的目的,从而让会议更加的高效
、快速
敏捷开发模型强调,做再多的文档
,最终给用户呈现的是软件产品
,得到用户认可的也是软件产品,所以应该做一些小型的版本
,让用户或客户整个开发流程中能够用到一些开发过程中的版本,并发现一些问题,提出一些建议。这一点跟原型开发模式
是相近的
TODO
这些规则都是为了化繁为简
,简化开发的流程。但是这种状态和一开始就简单化的模式是有区别的,正因为简化了开发了流程(例如砍掉了一些文档),导致敏捷开发模型
也有一系列的弊端,例如敏捷开发模型
只能开发一些小型的项目
,对于大型的项目就显得力不从心了,
IBM
曾经用XP
极限编程开发一个大型的软件项目,并将其作为极限编程的样板工程
,但是最终失败,原因就是敏捷开发模型
不适合开发大型项目,它适合的是小步快跑的开发项目
敏捷开发模型
的四大价值观是:沟通
、简单
、反馈
、勇气
人与人之间的沟通
,而不是人与文档之间的沟通
。过度设计
,能够满足需求即可。例如留了很多接口,但是后续却不一定能够用的上需求变更是无法避免的,既然如此我们应该有勇气去面对
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。