敏捷开发流程

1.敏捷开发介绍

1.1什么是敏捷开发？

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

1.2什么是迭代？

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

1.3什么是Scrum？

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

1.4什么是Sprint？

Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

2.Scrum开发流程

2.1确定Product Backlog

按优先顺序排列的一个产品需求列表，这个是由Product Owner 负责的。

2.2 工作量预估和安排

Scrum Team根据Product Backlog列表，做工作量的预估和安排。

2.3 Sprint计划会议

从Product Backlog中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是2~6个星期，然后把这个Story进行细化，形成一个Sprint Backlog。

2.4 细化Sprint Backlog

Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）。

2.5 Daily Scrum Meeting（每日会议）

每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出。

2.6 每日集成

也就是每天都要有一个可以成功编译、并且可以演示的版本。

2.7 Srpint Review Meeting（演示会议）

当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，每一个Scrum Team的成员都要演示自己完成的软件产品。

根据需求考虑，可与回顾会议合并为一个会议。

2.8 Sprint Retrospective Meeting（回顾会议）

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

3.Scrum Master的职责

3.1 管理Scrum流程

1）管理Scrum流程；

2）帮助PO建立product backlog与sprint backlog，并确立其中每个story的优先级；

3） Scrum Master应该有一个block list用来记录Team在开发中遇到的问题障碍，由Scrum Master自己进行管理并最终使得列表中的每一问题得到及时处理。

3.2 向PO获取合理的工作量

1） 不承诺太多的工作，导致Team在sprint的后期连续加班，致使Team的效率严重降低。同时避免由于时间的匆忙，急于交付，导致了项目的质量很低，最终形成了恶性循环。

2） 保护team在sprint的过程中不受PO干扰。

3.3 把关质量

1） 控制速度

不应过于强调速度，应保持合理的开发节奏，才会使得产品质量具有一定的保障。Scrum流程在每个sprint应统一完整，使得Team形成习惯，最终达到良好的开发节奏。

2）制定coding style

代码的规范非常重要，好的代码可以提高整体团队的开发与沟通的效率。可通过Jenkins集成sonarQube对代码进行审查，审查内容包括bug、漏洞、代码规范、单元测试覆盖率、代码重复率。

3）冒烟测试

在每天下班之前，停止push代码，然后进行冒烟测试。冒烟测试成功之后，才会下班回家。这是一种很好的方法，它保证了每天功能都是可用的，从而确保了质量。

3.4跟踪进度

1） 利用jira工具进行进度跟踪

2） 通过daily scrum meeting获取到Team每天的工作进展。此时我们可以根据进展进行一些必要的调整。

4.Confluence（文档集中化管理）

Confluence为团队提供一个协作环境。在这里，团队成员齐心协力，各擅其能，协同地编写文档和管理项目。从此打破不同团队、不同部门以及个人之间信息孤岛的僵局，Confluence真正实现了组织资源共享。

4.1文档分类

1）Sprint文档

包括Sprint计划、回顾会总结等相关文档；

2）产品文档

包括需求分析、产品操作手册登文档；

3）开发文档

包括接口规范、数据库设计、编码规范登文档；

4）测试文档

测试相关文档，根据实际情况考虑；

5）其他文档

其它各种团队共享文档。

5.Jira（项目管理）

5.1 jira的主要功能

1）问题追踪和管理，用它管理项目，跟踪任务、bug、需求，通过jira的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多（邮件功能暂未能使用）；

2）问题跟进情况的分析报告：可以随时了解问题和项目的进展情况；

3）项目类别管理功能：可以将相关的项目分组管理；

4）组件/模块负责人功能：可以将项目的不同组件/模块指派相应的负责人，来处理所负责的组件的Issues；

5）无限制的工作流：可以创建多个工作流为不同的项目使用。

5.2 迭代管理

团队刚开始采用kanban的形式，后期根据实际情况考虑是否采用sprint模式；

5.3 Bug管理

1）open

发现人员建立BUG后，指派给相关的开发人员，指定其为BUG的经办人，此时BUG为OPEN状态；

2）resolved

当经办人开发人员解决了该BUG并在测试环境自行检查通过后，点击“解决问题“，选择合适的解决类型（Fixed,Won’t Fix, Duplicate, Cannot Reproduce），并点击”解决“，将BUG状态变为Resolved，同时可以在“描述”里填写合适的解决原因；

3）closed

BUG状态变为Resolved后，BUG的报告人对BUG进行Verify工作。如果验证后发现BUG已经被解决，则报告人点击“关闭问题”将BUG变为CLOSED状态；

4）reopen

如果验证后发现BUG依然存在，则报告人点击”重新开启问题“，将BUG状态变为REOPENED。

6.持续集成

频繁地（一天多次）将代码集成到主干，让产品快速迭代，同时还能保持高质量。

6.1持续提交

流程的第一步，是开发者向代码仓库提交代码，所有后面步骤都始于本地代码的第一次提交（commit）；

6.2自动化持续代码质量扫描

只要提交了代码，jenkins就会从代码仓库拉取代码进行进行代码质量分析，然后将分析结果发送至sonarqube平台，开发人员可以使用ide插件同步sonarqube结果，并可以在线分析；

Jenkins支持每当代码分析无法满足SonarQube的质量标准时，即工程构建失败，构建失败可通过邮件通知开发人员（该步骤暂未实行）。

6.3自动化部署

后端项目：后端代码提交后，Jenkins自动构建并打包为镜像文件上传到harbor仓库，jenkins远程控制应用服务器上的脚本从harbor仓库拉取镜像完成部署；（gitlab+Jenkins+harbor+docker镜像部署方式为后期生产环境的集群部署和上云准备）；

前端项目：前端代码提交到gitlab后，Jenkins自动打包，并通过ssh远程传输dist包到nginx完成部署；

6.4测试

代码集成到主干之前，必须通过测试，只要有一个测试用例失败，就不能集成；

项目前中期，以手动测试为主，在后期的时候，可考虑自动化的全面覆盖保证回归测试的有效进行。

6.5 发布版本

测试通过之后，由专人集成到主干，同步到生产环境。

6.6持续部署/持续交付

持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤。

持续交付，它强调的是，不管怎么更新，软件是随时随地可以交付的，以供评审。

测试环境和生产环境网络不互通，持续交付/继续部署暂时无法实现，目前预发布和正式环境仍采用手动部署。

7.分支管理

1）master分支: 闲置，限制权限；

2）prod： 同步生产环境，限制权限；

3）test：测试分支，保证有一个稳定的测试版本；

4）dev：开发分支，开发人员在该分支开发；

5）feature：根据开发人员个人情况决定是否创建；

6）当存在长时间无法存在的大bug时，可考虑新开一个bug分支。