敏捷开发模式
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。
把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品
a, 每日站立会议
b, 任务看板
如何进行Scrum开发?
1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;
2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;
3、有了Product Backlog列表,我们需要通过Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个SprintBacklog;
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 _ Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);
8、最后就是 SprintRetrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;
Devops
可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。它是一套针对这几个部门间沟通与协作问题的流程和方法。用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。
原来,各角色仅关注于自己本身的工作,虽然大家都同处于一个项目中,但各自划分了"领地",产品经理就应该将MRD写得清清楚楚,如果开发人员认为不清楚,那就回去再改。开发人员只管按照MRD上的内容进行开发,很少考虑可测性和易测性问题。测试人员只管按照MRD中内容来测试,有问题通过内部工作流平台提交问题单。运维人员只管根据开发人员提交的上线操作单进行操作。似乎各角色之间的沟通介质只有各自的"交付物"。
现在,各角色都能够共同合作,以项目的最终交付为目标,积极讨论需求,优化实现。因为角色之间的这种紧密合作让所有人对不同角色都有了深入的了解。开发人员耐心为产品经理解释技术实现,说明计划安排,测试人员与开发人员共同讨论验收条件,避免遗漏需求。开发人员让运维人员了解架构设计,细心听取运维人员的建议,进行技术改造,使部署工作更快捷有效。
首先是需求收集与整理,撰写MRD(Marketing Requirement Document)或总体设计后,进行评审。如果涉及到多模块,每个模块的开发人员会对各自负责的模块进行详细设计,给出大致的开发计划,并商定联调时间点。
- 之后,开发人员会从主干上拉出项目分支,并在该分支上进行开发。当到最后联调点时,几个开发人员才会在将代码合在一起,进行联调。
- 当调通之后,开发人员再申请提测。测试人员接到提测申请单后,进行测试,记录Bug,通知开发人员修复,直致质量达到标准。
- 之后,开发人员会填写上线申请单,经运维人员确认后,运维人员操作进行上线部署工作。如图所示。