1 概述
1.1 编写目的
该文档的主要目的是为了在团队中实施敏捷开发，加速产品交付周期，为敏捷开发提供相应的规范流程指导而产生的流程设计。
1.1 主要读者
本文将适用于所有的开发、测试、产品、运维人员及管理者。
2 敏捷开发团队中的角色及名词解释
2.1 product owner
product owner也叫产品经理，负责整理user story（用户故事），定义商业价值，对其进行排序，制定发布计划，对产品负责。
2.2 scrum master
scrum master也叫敏捷专家或者敏捷大师， 因涉及到工作量评估和分派任务等工作，一般
由敏捷团队中的开发负责人担任该角色。主要负责的工作有召开各种会议，协调项目以及部分研发工作。
2.3 scrum team
scrum team即敏捷开发团队，由不同技能的成员组成，通过紧密协同，完成每一次迭代的
目标，交付产品。
2.4 sprint
sprint及敏捷中的每一次迭代冲刺。
3 敏捷开发的基本流程
3.1 项目管理流程图
在整个项目管理中，核心的角色有产品经理、项目经理、研发团队和测试团队四种角色，这
四种角色对应于敏捷开发中的product owner、scrum master、scrum team（DEV和QA）。这几种角色之间紧紧围绕产品的需求展开协作，取得成果。
3.2 敏捷流程
【流程解释】：
- product owner负责整理user story，形成左侧的product backlog。
- 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制订出这一迭代要完成的story列表，sprint backlog。
- 迭代计划会议：scrum team对每一个story进行分解，分解的标准是完成该story的所有任务中都有明确的任务负责人及完成工时的估计。
- 每日例会：每天scrum master召集站立会（daily meetings），scrum team成员回答昨天做了什么，今天计划做什么，有什么问题，并且在任务看板中更新各自的燃尽图（sprint burn down）。
- 演示回顾会议：sprint结束之后，召开演示会议，相关人员受邀参加 ，team向大家展示本次迭代所取得的成果，并在会议上进行sprint回顾，发现不足，总结经验，制定改进计划，下一个迭代进行持续改进。会议期间反馈的问题，由product owner和scrum master共同记录下来，形成新的story。
3.3 sprint的节奏控制
sprint制定的目标是否合理，开发、测试之间的配合是否顺畅，直接导致了最终交付物的质
量。因此，本文根据过往的产品开发经验，总结出一套适用于敏捷流程的节奏。
每个sprint采用6+3+1的节奏。其含义为：一个sprint包含6天开发工时，3天测试工时，1天上线及next sprint冲刺。
3.4 核心代码code review
核心代码在正式编码之前，需要通过TC（技术委员会）或者Senior Engineer的技术评审，
评审通过之后，需要按照评审通过的方案进行coding。
coding完成之后，通知TC或者Senior Engineer组织code review。code review通过之后，才允许将代码合并到公共的开发分支。
3.5 代码分支管理与代码合并规则
1） 代码不允许在master上直接开发。
2） 每次迭代开发开始之前，scrum master负责从master上拉去新的代码分支，然后将代码分支告知scrum team所有人员。
3） scrum team成员基于第二步scrum master告知的本迭代的开发分支，拉取属于个人的开发分支，并在个人开发分支的基础之上进行开发。
4） scrum team成员开发自测完成之后，向scrum master发起代码合并请求（从个人代码分支合并到本迭代的开发分支）。
5） scrum master收到代码合并请求之后，对代码进行评审。评审通过之后，执行合并操作。如果合并的过程中发生冲突，需要对应的开发人员解决冲突之后再提交到远程仓库。
6） 代码合并到开发分支上之后，开始对代码进行编译打包，并且提交测试。
7） 分支代码测试通过之后，在规定的上线窗口期，对分支代码进行上线。上线成功且稳定之后，需要在上线当天，将开发分支的代码由scrum master合并至master之上，并且在tag中打上标签。