扫盲——敏捷开发 Agile development 之 Scrum开发

觉得这篇文章写的非常好,非常有助于大家了解敏捷开发,原文链接在下面

https://www.jianshu.com/p/eb8f4448c5c8

什么是敏捷开发?

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。(把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。)

主要目的:降低需求变化的成本

开发流程:编写用户案例,架构规范,实施规划,迭代计划,代码开发,单元测试,验收测试等等。

原则和方法:迭代式开发。增量交付。开发团队和用户反馈推动产品开发。持续集成。团队自我管理。

核心做法:小规模,频繁的版本发布,短迭代周期。测试驱动开发、结对编程、持续集成、每日站立会议、共同拥有代码、系统隐喻。

精髓:2/8法则(20%交付功能代表80%最终商业价值);

为什么说是以人为核心?

我们大部分人都学过瀑布开发模型,它是以文档为驱动的。在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;

而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

什么是迭代?

迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

关于Scrum和XP

敏捷是一种指导思想或开发方式,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式

什么是Scrum?

Scrum是一个敏捷开发框架;由一个开发过程,几种角色以及一套规范的实施方法组成。

【Scrum开发流程中的四大角色】

产品负责人(Product Owner)

该角色负责产品的远景规划,平衡利益相关者的利益。确定不同的产品需求积压的优先级等。

在开发中,主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

他是开发团队和客户或最终用户之间的联络点。

利益相关者(Stakeholder)

该角色与产品之间有直接或间接的利益关系,通常是客户或最终用户代表。他们负责收集编写产品需求,审查项目成果等。

流程管理员(Scrum Master)

主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

他也是开发团队与产品拥有者之间交流的联络点。

开发团队(Scrum Team)

主要负责软件产品在Scrum规定流程下进行开发工作,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

Scrum名词解释:

backlog:可以预知的所有任务,包括功能性的和非功能性的所有任务。建立Product Backlog 的过程就是将用户需求转化为一个个User Story 并确定其优先级的过程。

story:用讲故事的方式来表达需求,这样便于让原始客户比较清晰的对需求进行表达,开发和测试也会逐渐以客户的需求思维来思考自己的工作。

sprint:一次迭代开发的时间周期,一般最多以30天为一个周期。在这段时间内,开发团队需要完成一个制定的backlog,并且最终成果是一个增量的,可交付的产品。

sprint backlog:一个sprint周期内所需要完成的任务

scrum Master:监督整个Scrum进程,修订计划

time-box:一个用于开会时间段。每个daily scrum meeting的time-box为15分钟。

sprint planning meeting:启动每个sprint前召开。一般为8小时。产品Owner和团队成员将backlog分解成小的功能模块,决定在即将进行的sprint里需要完成多少小功能模块,确定Product Backlog的任务优先级。还需详细讨论如何按需求完成小功能模块。

Daily Scrum meeting:开发团队召开,开发人员向ScrumMaster汇报:今天完成了什么?遇到了什么障碍?明天做什么?团队成员相互了解项目进度

Sprint review meeting:每个Sprint结束后,Team将Sprint成果演示给Product Owner和其他人员。并总结结束的Sprint。

 

Scrum流程图

如何进行Scrum开发?

1、确定Product Backlog(按优先顺序排列的一个产品需求列表),由Product Owner 负责的;

2、Scrum Team做工作量的预估和安排;

3、Product Backlog列表中挑选出一个Story作为迭代目标,然后Story进行细化。

团队在Backlog列表中挑选出当前sprint内完成的工作。团队决定如何将选定的产品Backlog转化为潜在可交付产品的功能增量。

形成一个Sprint Backlog(Sprint Backlog是由Scrum Team去完成的)

4、召开sprint planning meeting,确定迭代任务,优先级,并分配给每个成员

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting,每个人汇报昨天完成了什么,承诺今天要完成什么,遇到不能解决的问题。回答完成后,更新 Sprint burn down(Sprint燃尽图);

6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;

7、当一个Story完成,也就是Sprint Backlog被完成也就表示一次Sprint完成,这时,我们要进行 SrpintReviewMeeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

8、最后就是Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

 


其他资料

利益相关者:敏捷开发保证了项目中所有利益相关者的利益,不论是客户、项目管理、开发团队或测试小组。每个人对项目都有清晰的可见性,这是成功的关键点所在。敏捷开发原则上鼓励用户积极地参与,不论是产品开发,或是团体协同的方方面面。这对关键利益相关者提供了非常好的可见性,包括项目的进度或是产品本身,最终这有利于保证产品预期的效果。

质量:不像传统的瀑布模型,等到开发完成才开始测试,可是在敏捷开发中,我们随着需求的准备便开始进行测试。因此,测试集成贯穿整个开发周期,使得工作产品像开发一样去定期检查。这允许工作所有者有必要时做出适当调整,以及及早的给产品团队检查出任何质量问题。

核心原则

◆主张简单:简单模型入手,慢慢迭代

◆拥抱变化:需求时刻在变,Project stakeholder(项目利益相关者)也可能会变化。项目环境不断变化

◆可持续性:实现项目投资者的需求,其中就包括你的系统应该要有足够的鲁棒性(robust ),能够适应日后的扩展。可持续性可能指的是系统的下一个主要发布版,或是你正在构建的系统的运转和支持

◆递增的变化:

和建模相关的一个重要概念是你不用在一开始就准备好一切。你不用在模型中包容所有的细节,你只要足够的细节就够了,开发一个小的模型,或是概要模型,打下一个基础,然后慢慢的改进模型。

◆令投资最大化

你的项目投资者为了开发出满足自己需要的软件,需要投入时间、金钱、设备等各种资源。投资者应该可以选取最好的方式投资,也可以要求你的团队不浪费资源。并且,他们还有最后的发言权,决定要投入多少的资源。

◆快速反馈

从开始采取行动,到获得行动的反馈,二者之间的时间至关紧要。和其他人一共开发模型,你的想法可以立刻获得反馈,特别是你的工作采用了共享建模技术的时候。和你的客户紧密工作,去了解他们的的需求,去分析这些需求,或是去开发满足他们需求的用户界面,这样,你就提供了快速反馈的机会。

◆轻装前进

你建立一个工件,然后决定要保留它,随着时间的流逝,这些工件都需要维护。如果你决定保留7个模型,不论何时,一旦有变化发生(新需求的提出,原需求的更新,团队接受了一种新方法,采纳了一项新技术...),你就需要考虑变化对这7个模型产生的影响并采取相应的措施。而如果你想要保留的仅是3个模型,很明显,你实现同样的改变要花费的功夫就少多了,你的灵活性就增强了,因为你是在轻装前进。每次你要决定保留一个模型时,你就要权衡模型载有的信息对团队有多大的好处(所以才需要加强团队之间,团队和项目投资者之间的沟通)。

作者:王皮皮_
链接:https://www.jianshu.com/p/eb8f4448c5c8
来源:简书

 

©️2020 CSDN 皮肤主题: 酷酷鲨 设计师:CSDN官方博客 返回首页