基于scrum的敏捷开发流程总结

本文主要来源于华为软件开发流程，同时根据在创业团队的实践在细节上稍有修改。

需求管理

先了解几个概念：

IR(Initial Requirement):原始需求。这种需求来自客户，一般由产品经理/需求经理编写。如果是研发内部产生的需求，可以不需要有IR。

SR(System Requirement):系统需求。架构师对IR进行分析以后，结合系统设计，将需求描述成一个个要实现的子系统或者模块，比如：提供用户权限管理系统/模块，要求满足用户、角色、权限管理，满足3A/4A要求。

AR(Allocation Requirement):分配需求/分解需求。架构师或者高级工程师分析SR，将SR分解成一条条的可以分配给开发人员去实现的需求。注意，AR分解完成的时候，每个AR的预估工作量也应该给出。AR的分解没有非常明确和固定的分解方式，需要根据人员、项目时间要求进行把握，在笔者经历的项目中，通常有以下几个原则：

• 一个AR的工作量不要超过一轮迭代的单人工作量。比如，如果一轮迭代安排一个月（以22个工作日计算），那么一个AR的工作量不要超过22人/天，不然会出现一个AR需要两轮迭代完成的情况，敏捷禁止在一轮迭代中出现半成品。
• 一个AR尽量由一名开发人员完成。比如，需要完成用户的增删改查功能，可以分两个AR：

        SR001-AR001:提供用户增删改查Web API。

        SR001-AR002:前端实现用户增删改查功能。

一个典型的AR可以是下面的格式（xx项目迭代跟踪表.xlsx）：

SR号	AR号	AR描述	迭代周期	设计	开发	测试	是否已交付
SR001	SR001-AR001	提供用户增删改查接口	迭代一
SR001	SR001-AR002	提供用户增删改查操作界面	迭代一

CR(Change Requirement):变更需求。项目开发的后阶段，可能因为客户需求变化或者系统实现方案有变化造成需求变更，这种需求属于变更需求，同样需要跟踪。

迭代开发

AR是方案设计阶段的出口，也是开发阶段的入口。

项目经理拿到AR列表以后，需要根据AR之间依赖关系、结合团队一轮迭代可以完成的工作量，对AR进行分配和排期。

这里根据具体公司组织架构，分配方式略有不同，通常，项目经理要列出一轮迭代需要完成的AR列表，根据模块划分将AR分给开发组长，由开发组长来分配给团队内具体的开发人员，分配好后，填写上面的跟踪表。

迭代过程要包含基本的质量控制流程，以笔者经历的项目为例，如果一轮迭代安排一个月时间(22个工作日)，那么大致将迭代内各阶段时间安排如下：

1.设计串讲：1天 。

  参与人员：设计、开发、测试，

  入口条件：设计文档。

  出口条件：设计、开发、测试对需求及实现方案理解达成一致。

  任务：给开发、测试串讲AR实现总体方案，这个流程主要针对方案设计与开发人员由不同人完成的团队，小团队中不一定需要，可把时间留给其他流程。

2.开发详细设计：3天

   参与人员：开发。

    入口条件：设计文档，开发与设计对需求及实现方案理解达成一致。

    出口条件：模块数据流向图或者接口调用流程图，总之要能体现代码层面的设计思路。

    任务：这一阶段要根据高级工程师设计的总体方案，进行接口级别的设计，可以直接指导编码实现，时间可以根据复杂程度做      适当调整，不一定要安排满3天。

3.开发反串讲：1天

    参与人员：开发、设计

    入口条件：模块数据流向图或者接口调用流程图。

    出口条件：设计、开发对代码设计理解一致。

    任务：开发给设计讲解自己的代码设计，设计提出问题及建议，防止实现与设计不一致。

4.编写测试用例：2天

    参与人员：开发、测试

    入口条件：开发、测试

    出口条件：测试用例

    任务：编写测试用例，有的团队直接由测试完成，有的会让开发编写，可以根据实际情况安排，重要的是双方达成一致理解。

5.编码：6天

    参与人员：开发

    入口条件：详细设计（指的是开发自己完成的代码层面的设计）

    出口条件：代码

    任务：根据设计完成编码工作

6.code review：2天

    参与人员：开发人员、高级工程师或者模块owner。

    入口条件：编码已完成

    出口条件：review意见及修正

    任务：完成code review，并修改review comments。

7.开发自测：3天

    参与人员：开发

    入口条件：用例已完成；代码已完成走读。

    出口条件：用例自测通过。

    任务：开发根据测试用例进行自测

8.联调：3天

    参与人员：有调用关系的模块开发人员

    入口条件：自测已完成

    出口条件：联调通过，能完成集成验证。

    任务：模块间联调完成

9.产品验收：1天

    参与人员：开发、产品、测试

    入口条件：已完成联调

    出口条件：产品验收确认书

    任务：开发给产品演示本AR开发的成品，产品检查是否与产品设计一致，如有不一致的地方要提出，如果时间够，就修改，        否则作为下一轮迭代的补充需求完成。

迭代回顾

持续改进是敏捷开发的一个重要需求，敏捷团队在一轮迭代完成以后应进行一次回顾，迭代回顾有以下原则：

1. 只用于找出改进措施，不用于表扬和批评，建议考评负责人不参与。
2. 迭代回顾会议引导人只做引导，杜绝一言堂，要让项目成员畅所欲言。
3. 从亮点和待改进点两个角度提出问题，包含开发流程的各个环节，不限于开发人员。
4. 每一项待改进点要有责任人，以及闭环日期。

一个典型的迭代回顾记录表参考如下：

	亮点	待改进点	改进措施	责任人	完成日期
管理	1.xxx 2.xxx	1.xxx 2.xxx	1.xxx 2.xxx
开发技能
测试
产品