总结敏捷开发

Posted 2021-04-25 刘汉亮

当时刚到喜马拉雅实习时，我开始经历了真正的需求评审会，公司也正好开始实行敏捷开发，当时我还不懂什么叫Scrum，现在回想起来有点体会。一个大的项目（Product Backlog）拆分成按月交付(Sprint Backlog)，一个月就是一个Sprint，一个月分成4个礼拜，每天十点一个站会，也就是daily meeting，大家讲自己昨天做了什么，今天要做什么，遇到什么问题，要调用哪些资源。大家面对面的沟通，能当面讲的就尽量不写文档，提高效率，及时反馈，然后是每周一个回顾会议（Sprint Retrospective）。下面做一个总结：

什么是敏捷开发？

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

瀑布式开发

瀑布模型要求软件开发严格按按照需求→分析→设计→编码→测试的阶段进行，每一个阶段都可以定义明确的产出物和验证准则。瀑布模型在每一个阶段完成后都可以组织相关的评审和验证，严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过后才能够进入到下一个阶段。遵循自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

瀑布模型式是最典型的预见性的方法。

瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

敏捷开发以人为本，瀑布流以文档驱动。

敏捷价值观

1. 以人为本：重视个体间的合作互动

2. 目标导向：我们最终交付的是“可使用的软件”，而不是一堆繁重的文档

3. 客户为先：理解客户需求，与客户合作

4. 拥抱改变：客户会在不断变化需求的过程中明晰真正需要的，因此敏捷需要拥抱变化

为什么说是以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

 

什么是迭代？

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

 

关于Scrum和XP

前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲Scrum。

 

什么是Scrum？

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

术语

Sprint：冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。

User Story：用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。一个好的用户故事包含以下三个要素：

1. 角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能。

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

Task：由User Story 拆分成的具体开发任务。

Backlog：需求列表，可以看成是小目标的清单。分为Sprint Backlog和Product Backlog。

Daily meeting：每天的站会，用于监控项目进度。有些公司直接称其为Scrum。

Sprint Review meeting: 冲刺评审会议，让团队成员们演示成果。

Sprint burn down：冲刺燃尽图，说白了就是记录当前周期的需求完成情况。

Rlease：开发周期完成，项目发布新的可用版本。

Scrum 框架结构

Scrum敏捷开发流程主要包括：三个角色、三个物件和四个会议。

三个角色：

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

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

开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右。

三个物件：

1、product Backlog ： 产品Backlog指根据初始需求分解出的任务列表，包括功能性和非功能性的所有功能。

2、Sprint Backlog ，这是一个迭代计划会议的输出，包含开发团队在迭代周期内所要完成的工作列表。 如果说产品backlog是以story为单位，文档归属为PM团队，那么Sprint Backlog 是以小时（时间）为单位的，文档归属为开发团队。

3、燃尽图。

燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。理想情况下，该图表是一个向下的曲线，随着剩余工作的完成，“烧尽”至零。燃尽图向项目组成员和企业主提供工作进展的一个公共视图。（引自百度百科）

scrum基本流程（四个会议）：

1.产品负责人负责整理user story，形成左侧的product backlog。

2.产品发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。

3. spring计划会议：在每个迭代之初，开发团队和 Product Owner 共同来计划在迭代周期内要完成的工作。Product Owner 负责向团队讲解要完成的工作的内容，开发团队负责对工作进行估计。

4.spring每日立会：每天，开发团队和产品负责人都要进行一个短暂的沟通。团队成员回答昨天做了什么？今天计划做什么？遇到了什么问题？

5.spring演示会议：在迭代周期结束时，开发团队向产品负责人及所有干系人进行演示，并接受反馈。

6.spring回顾会议：在迭代周期结束时，Scrum 团队通过会议来对迭代的过程进行总结，以促使团队自我持续改进。

Scrum场景图示例

产品Backlog: 与下面的不同，公司采用石墨文档，用Excel做的需求池。

Daily meeting:哈哈每天最有意思的事情，好像原始社会里族群商量狩猎计划。

有一天，我的身边多了一个黑板,emm叫做任务看板，上面那个图就叫燃尽图（Burndown Chart）。

the end