基于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描述迭代周期设计开发测试是否已交付
SR001SR001-AR001提供用户增删改查接口迭代一    
SR001SR001-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
  
开发技能     
测试     
产品     

  

       

 

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页