声明，该文档从很多网友的文章中收集而来，为了总结，为了系统化知识。

敏捷开发流程

概述

常见的软件开发模式（或流程），主要有四类：瀑布式，迭代式，螺旋式，敏捷开发。

瀑布式模型，其实就是门径管理流程（80年代提出）在软件行业的一个写照。早期的软件开发模型，大多是这种模型，现在在一些行业还有在用。门径管理流程，包含了至少三组阶段&关卡。门径并没有过时，其实它并不排斥迭代（门径的发明者，从未有提过不允许迭代的发生）；它是一个产品/商品从创意产生到生命周期的末尾，所经历的各个阶段的一个描述；门径特别强调关卡（评估节点），每个阶段，必须经历项目评估后，才能进入下个阶段或者被放弃/搁置。

迭代式开发，也称增量开发，它将整个开发阶段分成了一系列小的阶段，每个阶段，都包含了需求分析、设计、实现、测试等过程。

敏捷开发，是从90年代开始引起广泛注视的，现在软件开发行业应用广泛。敏捷原则如下：

总结，上述敏捷开发的关键原则如下

关键原则

1. 首要任务：尽早和持续交付有价值的软件来满足客户
2. 随时欢迎需求变更
3. 频繁的交付可运行的软件
4. 项目期间，业务人员与开发者共同工作
5. 筛选积极主动的项目开发人员
6. 面对面交流
7. 可运行的软件是衡量进展的主要标准
8. 敏捷流程有利于可持续开发
9. 持续关注先进的技术和优秀的设计，提高敏捷性
10. 简洁
11. 自组织
12. 定期反思

常用的敏捷开发流程有多种，如极限编程（XP），Scrum等等。

敏捷开发名词及流程

产品待办列表（product backlog）

product backlog，是一份包含系统所需的一系列事项要求，并将它们按优先级排列的清单。包括功能性和非功能性的客户需求，以及技术团队产生的需求。

虽然产品需求列表有多种来源，但是确定优先级持续是产品主管的独有职责。

一个产品待办列表项是个足够小的工作单元，团队可以在一次冲刺迭代周期内完成。

敏捷流程

XP，Scrum都是常见的敏捷流程；我们则以scrum作为介绍对象。Scrum一词源自橄榄球队，争球。

采用敏捷流程，软件生成得以按规律的步调进行，并由一系列固定长度的迭代过程开发出产品。

冲刺（sprint）

冲刺，是指完成特定的任务，使开发阶段得以进入审查环节的一段时期。

规划会议是每次冲刺的起点。在规划会议上，产品主管和开发团队商定此次冲刺所要完成的任务列表和相关的验收标准。

冲刺周期由敏捷教练决定

冲刺开始后，开发团队接手主持工作

冲刺结束时，团队将已经完成的工作提交给产品主管。产品主管将依照冲刺会议上设定的标准，决定是否接受这些工作成果。

产品主管（the product owner）

在划分产品待办列表的优先级和罗列需求时，产品主管代表客户利益、拥有最终的决定权。团队必须随时可以联系到他，特别是在冲刺的规划会议期间。

冲刺开始后，产品主管不再管理团队，也不应当再变更任务。

产品主管的主要职责是平衡有竞争关系的利益相关者之间的关系。

敏捷教练（The scrum master）

敏捷教练，是团队和产品主管之间的协调者，他的工作职责不是管理团队，而是通过以下方式，帮助团队和产品主管

1. 消除团队和产品主管之间的障碍
2. 激发团队的创造力，给团队授权
3. 提升团队生产率
4. 改进工程，工具和实践
5. 确保团队取得进展的信息实时更新，让各个成员均可见

敏捷团队（the scrum team）

敏捷团队通常由5-9人组成

成员通常由多个职能部门或学科的人员组成（游戏行业，程序，架构师，qa，策划，美术等）

在冲刺期间，团队通过自我管理的方式实现冲刺目标；团队在实现目标的方法上有选择自主权，并对目标负责。

其他名词

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

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

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

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

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

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

主要流程图

比较详细的流程图如下

用我们软件行业的图如下。当然游戏行业的流程，主要是：策划设计，美术设计，程序编码，debug，codereview，profile/performance，优化，发布/部署，测试等等。上线后，还有监控等产品流程。

测试流程

对于手游行业，着重说一下如下测试流程（ios和andriod都有提审过程，国内的andriod和渠道相关）：

手游测试一般有封测、内侧、公测等三个阶段；有一种说法：“软件产品永远都是β（beta）版本，永远都处于测试阶段！”。

封 测

封测是指在很小范围的测试，主要是为了发现问题、解决问题。一般情况下，通过一个渠道或者几个渠道进行测试，大部分封测都会在测试结束后删档。下面先说明封测一般是怎么操作的，然后再深入探讨一些跟封测相关的话题。

内 测

内测其实就是大规模推广，这次测试就不会再删档了。在这个阶段会接入大量的联运渠道，在市场推广层面的力度也会非常大。对于非顶级的游戏来说，内测可能就是这个产品收入的最高峰。如果产品数据没有足够的竞争力，渠道就会减少用户的导入，等到公测的时候就很难再有较大的提升了。

公 测

公测其实跟内测没有特别本质的区别。之所以需要这么一个测试，主要是从市场层面考虑，把公测包装成一次事件，进行集中的大规模营销和推广工作。用一个高级一点的词就是“事件营销”。

测试内容举例

手游客户端：

内容测试，比如：bug测试，一般公司会有相关的规定，将bug分成4级，针对每个测试阶段，都有相应的质量要求。

安全性测试，防外挂，加固，比如：漏洞测试；反外挂，防作弊；so/dll加密混淆，反调试，资源文件保护等。

性能测试，比如：分别测试ios和andrioid，资源内存分配，函数级性能分析和优化等

兼容性测试，比如：覆盖ios和andriod，主要机型，覆盖品牌，分辨率，多系统，cpu，gpu等。

对于手游服务端：

协议安全性测试，比如：协议是否安全（加密，混淆），是否存在盗刷风险，配置项是否加密等。

全链路构建真实压测场景，比如：支持构建单场景和上下文场景，按场景分配压力大小。

参数配置效率高，比如：可视化参数配置，简单快捷，新手易操作，无技术门槛。

高并发能力，比如：百万级并发压力，随开随用，支持全国压力源，多IP分布式压力。

全面性能监控，比如：多维度监控数据，支持报告实时查看，全方位助力问题瓶颈定位。

维护流程

渠道版本维护

一款游戏上线后，随着时间的延续，会有很多商业化版本不断更新，会持续修复上线问题。比如，会陆续推出一些资料片；通过玩家的行为分析（游戏会收集相关的日志，通过后台大数据分析得来），更新相关的玩法，推出多个活动等等。

多语言版本维护

随着渠道的扩充，不同国家版本的需求也会提出来。多语言版本，出了会有相应的翻译，客户端ui调整外；还会推出对于本地文化的商业活动，适当删减游戏内容，甚至在玩法上也会有些许微调。

衮服与合服

衮服

是指不更新游戏版本，经常开新服，合区之后，再开新区等等。衮服可以短时间内分摊导入的用户量，并且不至于造成玩家过于集中在老服等好处；但是也会造成运营成本的上升等问题。手游与页游开服节奏较快，可能出现一天开多哥服务器或者每天一服，部分玩家在之前的服务器中已经创建有角色幷参与到游戏中，又到新区进行游戏，这样的用户可以叫做滚服用户。

不过，很多大公司，针对不同的游戏类型，在技术上做了不同的解决方案，比如，大通服，充分利用云计算的能力，避免或减少衮服的负面问题。

合服

合并多个“鬼服”为一个服，将一些人少的服合并起来，可以激活玩法，聚集人气；不过每次合服都伴随着一定数量的玩家流失。

合服需要注意以下问题：

1. 合服需求（登录是否需要选服，保留和备份哪些数据，合服补偿等）。

2. 先进行合服预演（清除排行榜，删除和恢复账号规则等）。

3. 根据需求制定合服计划（合服排期，预热活动计划等）。

4. 合服前准备测试账号（如果需要充值首冲配方的需要准备充值过的账号或者其他需求）。

5. 确认合服后区服的平台，客户端的连接 IP 和端口（合服数据合并后配置，也可以在数据合并的时候选择几个区服配置先进行测试）。

6. 合服后登陆测试账号确认数据是否显示正常，充值是否能正常到账。通过平台发放邮件和道具能正常收到邮件，点击领取正常进入背包。

7. 以上操作先在外网测试服测试通过后，才可以到正式服发布。

跨服

一款游戏经过一段时间的运营，大多会涉及到跨服的玩法；一方面跨服可以解决部分“鬼服”的问题，另一方面可以带动整个跨服区域内的生态，向好的方法发展。跨服，从字面上讲就是跨过服务器，也就是不在自己服务器。

比如，一些竞技类游戏，期初的战场，都是本服的；但随着段位的提升，或人数的衰减，会越来越需要跨服来激活玩法。

跨服功能，要求不同服务器之间可以数据交互，一致性、可用性要求都比较高，为此，什么数据可以跨，什么数据不能跨，允许多大程度的回档等，是跨服的固有问题域内容。

常用的Scrum流程软件工具

Jira/Jira Agile

JIRA 是Atlassian公司出品的项目与事务跟踪工具，这个词来自日语单词，即“Gojira”，意思是哥斯拉。现在Jira，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。Jira提供了丰富的功能，其中包括：可用于backlog的自定义过滤器、项目报告的可视化表示、以及可定制的Scrum板。当然，如果您不太熟悉Scrum的话，可能需要花上一定的时间来测试，熟悉和掌握该软件的各项功能。

Jira的主要功能：

问题追踪和管理：

　　用它管理项目，跟踪任务、bug、需求，通过jira的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多。

问题跟进情况的分析报告：

　　可以随时了解问题和项目的进展情况。

项目类别管理功能：

　　可以将相关的项目分组管理

组件/模块负责人功能：

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

项目email地址功能：

　　每个项目可以有不同的email（该项目的通知邮件从该地址发出）

无限制的工作流：

　　可以创建多个工作流为不同的项目使用

与Confluence联动

Jira的基本概念

JIRA 中涉及的角色

1 管理人员

根据 JIRA 系统提供的数据，更加准确地了解项目的开发质量和状态，以及整个团队的工作效率。

2 项目管理者

可以针对登记进 JIRA 系统中问题，进行评估，分配缺陷；还可以通过 JIRA 系统的统计报告了解项目进展情况以及团队的工作量、工作效率等信息。

3 开发人员

在 JIRA 系统中查看分配给自己的问题，及时进行处理，填写处理情况并提交工作量记录。

4 测试人员

根据测试情况，在 JIRA 系统中及时快速的记录问题并对开发人员处理后的问题进行验证和跟踪。

任务类型

故事：从用户的角度来看，这是一个要求。

错误：这是产品中的缺陷，需要由开发人员修复。可以使用自己的问题类型跟踪它，以区别于其他类型的工作。

史诗：史诗是一个包含其他问题的大问题。

问题

问题是Jira里最重要的概念。它的英文是Issue，也就是Jira介绍里所说的事务，对应我们日常项目管理过程中的各种工作项。而在问题里最重要的是问题的类型，把问题类型定义好，我们使用Jira管理项目就迈出关键的一部。一个问题可以是软件的缺陷，一个项目的具体任务，一个需要解决的技术难题或者是需要审批的报销单据等。如下图

JIRA 跟踪问题（Issue），这些问题可以是 bug，功能请求或者任何其他想要跟踪的的任务；每一个问题有一些关联的信息：

问题类型（Issue Type）

摘要（summary）

问题描述（description）

问题所属的项目

问题关联的项目组件（component）

问题影响的项目版本（affect version）

问题将被解决的项目版本（resolved version）

问题发生的环境

问题的优先级

问题的报告者

问题的指派处理人

问题的当前状态

问题相关的历史记录

问题类型

JIRA 系统可以用于跟踪多种不同类型的问题。系统管理员可以根据需要添加。JIRA系统缺省提供的问题类型如下：

Bug'缺陷'：测试过程、维护过程发现影响系统运行的缺陷

New Feature'新需求' ：对系统提出的新功能

Task'任务' ：需要完成的任务

Improvement'改进意见' ：对现有系统功能的改进

优先级

在 JIRA 系统中用优先级来表示问题的严重级别。系统管理员可以在 JIRA 系统中添加优先级，JIRA 系统缺省的优先级为'紧急'，'严重'，'一般'，'次要'，'无关紧要'5个级别：

状态（Status）

每个问题有一个状态，用来表明问题所处的阶段，问题通过开始于 open 状态，然后开始处理/Progress，再到解决/Resolved，然后被关闭/Closed。根据情况的不同，您可以根据项目来定制问题状态以及工作流。JIRA 系统提供的缺省状态如下：

Open ：表示问题被提交等待有人处理。

In Progress ：问题在处理当中，尚未完成。

Resolved ：问题曾解决，但解决结论未获认可，需要重新分派解决。

Reopened ：问题解决，等待结果确认，确认的结果是“Reopened”或者“Closed”。

Closed ：问题处理结果确认后，置于关闭状态。

解决（Resolutions）

一个问题可以用多种方式解决，系统管理员是可以在 JIRA 系统中定制解决方式。JIRA系统默认的解决方式如下：

Fixed ：问题已经解决。

Won’t Fix ：问题未解决 – 将不会解决的问题。

Duplicate ：重复的问题。

Incomplete ：问题描述得不够准确、完全。

Cannot Reproduce ：问题重现失败，或者无足够的信息重现问题。

项目

JIRA的项目是根据你的企业组织需要定制的，是问题的集合。

例如,一个JIRA项目可以是:

一个软件研发项目

一项市场推广活动

一个技术服务/帮助台系统

一个需求管理系统

一个网站需求调查系统

每一个问题属于一个项目。每一个项目有一个名字和一个关键字（如：WEB），以后属于这个项目的问题的关键字就会包含 WEB（如：WEB-100，WEB-101）。值得注意的是，在 JIRA 系统中有一个权限‘Administer Projects’，通常将这个权限赋给项目负责人，拥有这个权限的 JIRA 用户就可以管理项目的‘版本’和‘组件’。

实际设置Jira中的项目相对简单，只需要在创建项目时选择好项目类型。项目的类型决定了项目管理过程中采用哪些概念。一般的开发项目建议选择software“Scrum开发方法”就可以了。

创建项目时也可以选择“创建与共享配置”选项，这个选项在公司中尤为起作用。系统配置管理员只需要建一个符合公司规范的项目模板，其他项目就会复用相关的项目配置，能大大减轻项目配置的功能量。

如下图：

1 项目版本

在一个项目上，一般会有多个版本，如：1.0alpha、1.0beta、1.0、1.2、2.0。

JIRA 系统中的问题涉及到两个版本字段：

影响版本— 可以清晰地反映出这个问题在哪个版本中出现错误。例如, 一个软件的缺陷可能影响了产品的1.1和1.2版。

修复版本— 可以反映出报告的问题将在哪个版本，或已经在哪个版本中修复了。例如, 软件缺陷影响了产品的1.1和1.2版，这个缺陷已经在2.0版中修复了。注意没有修复版本的问题会被归类到'未规划'。

版本可以有3个状态: 已发布,未发布或已归档。版本可以设置发布日期,而JIRA会自动将到期而还没有发布的版本高亮显示出来，并标注上'超期'标志。

2 项目模块

一个项目模块是这个项目中问题的逻辑分类集合。每个项目都可以根据你企业组织的要求设置多个模块 (也可以不设置模块)。

例如, 一个软件研发项目可以设置'文档','邮件系统','用户界面'等模块。一个网页设计项目可以设置'产品','联系我们','专业服务'等模块:

项目中的问题可以隶属于一个或多个模块，当然也可以不属于任何模块。

面板

面板包含2种类型，“Scrum”类型和“看板”类型。2者最大的区别是是否有计划。

“Scrum”有计划，一般会设置1-4周为1个sprint，纳入到sprint里的问题被投入人力全力解决。没有纳入sprint的等待下一个sprint再解决。通过较短的sprint周期，兼顾了计划性和灵活性。

“看板”没有计划，新增的问题可随意调整优先级。比较适合“领导说了算的”管理模型。问题的优先级可随时调整，计划可随时调整的管理情况。

Scrum的看板会有Backlog和sprint 2个概念。新建的问题会先进入Backlog（任务池），纳入到冲刺计划的问题会进入“sprint”中。

“sprint”的面板，可以方便跟踪sprint里各个问题的进展情况。

Dashboard（仪表盘）

Jira提供数据大屏的功能，帮助管理人员提供分析展示功能，发现项目进行过程中可能存在的问题，找到改进的地方。可以通过简单的配置就可以提取Jira的数据生成图表，并进行展示。配置数据大屏的功能很简单。只需要点击“添加小程序”，选择想要展示的图标并进行相关配置。

添加小程序的步骤如下：

1. 点击“添加小程序”
2. 选择小程序
3. 配置小程序（配置筛选器，筛选出想要展示的数据）

工作流

JIRA 是基于工作流进行的，而且他也提供了很强大的工作流管理。JIRA 提供的默认工作流为五个状态：Open，Close，Resolve，In Progress，ReOpen。而我们真正使用的时候，这几个状态往往满足不了需求，例如，一个正在进行的任务，突然发现不符合条件进行，需要挂起，那么应该放到哪个里面呢？

GreenHopper看板上面会把Story，Task，Sub-Task等都列上来，而对于Story和Task在我们的思路里，是不希望它们是一样的处理流程，例如，对于Story我们只希望它从Open到Resolve或Close即可，不需要进入In Progress。基于这些问题，我们需要自己创建一个适合我们项目开发的工作流。

而 JIRA 正是提供了自定义的工作流，让你自己去设置工作流，以满足工作的需要。下面来看一下具体的配置。

首先，把默认工作流中用不到的状态去掉，然后保存。

到此处为止，我们就把不需要的状态已经删除了。当然，为了完成我们自己的工作流，还需要添加一个状态。

Redmine

Redmine 是用Ruby开发的基于web的项目管理软件，是用ROR框架开发的一套跨平台项目管理系统，据说是源于Basecamp的ror版而来，支持多种数据库，有不少自己独特的功能，例如提供wiki、新闻台等，还可以集成其他版本管理系统和BUG跟踪系统，例如Perforce、SVN、CVS、TD等等。这种 Web 形式的项目管理系统通过“项目（Project）”的形式把成员、任务（问题）、文档、讨论以及各种形式的资源组织在一起，大家参与更新任务、文档等内容来推动项目的进度，同时系统利用时间线索和各种动态的报表形式来自动给成员汇报项目进度。

下面是主界面的截图

左侧是我的工作台，指向我的任务，问题/缺陷等；右侧是项目组内的其他进展提示。

下面是问题界面的截图

日历界面的截图，这个是我一直很喜欢的

对于敏捷开发团队，如想高效且协同的工作，必须要标的每项子任务的起始时间，将任务按人员，资源，假期等约束情况排列好；否则，每周进度，容易出现混乱的情况。如下图的甘特图，直观的显示出了任务排程情况，当然这里没有project等专业工具那样，可以设定任务的顺序关系（4种链接关系）。

还可以制作wiki，制作新闻，上传文档等，用于项目组的知识和信息共享，这点也很重要；不过大的组织，一般倾向于使用更加专业的系统，如confluence。

PingCode

PingCode 是国内顶级能够实施Scrum方法的软件之一。作为国内最标准的Scrum 产品，PingCode不仅支持Scrum框架所必需的基本元素，而且几乎能够解决所有敏捷项目管理相关的问题，并且还支持通过插件来补充实现与其他主流开发工具的打通，以实现敏捷开发过程中的需求管理、测试管理、缺陷管理、项目集管理、目标管理、知识库管理、自动化管理等全过程管理。

ONES

ONES 企业级研发管理工具包含 ONES Project（项目管理工具）、ONES Plan（项目集管理）、ONES Wiki（知识库管理）、ONES TestCase（测试用例与测试计划管理）、ONES Pipeline（持续集成与交付管理），以此产品矩阵贯穿整个研发流程，帮助研发团队进行有序的任务及需求管理、测试用例管理、知识沉淀及文档协作、以及整合 DevOps 工具链进行高效率的研发协同，促进参与产品开发的各角色成员进行良好的协作。研发团队通过制定长期项目管理和短期迭代规划，跟踪研发进度和质量，帮助团队快速交付产品。