扫盲——敏捷开发 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
来源：简书