该文档的主要目的是为了在团队中实施敏捷开发,加速产品交付周期,为敏捷开发提供相应的规范流程指导而产生的流程设计。运维
本文将适用于全部的开发、测试、产品、运维人员及管理者。测试
product owner也叫产品经理,负责整理user story(用户故事),定义商业价值,对其进行排序,制定发布计划,对产品负责。编码
scrum master也叫敏捷专家或者敏捷大师, 因涉及到工做量评估和分派任务等工做,通常设计
由敏捷团队中的开发负责人担任该角色。主要负责的工做有召开各类会议,协调项目以及部分研发工做。3d
scrum team即敏捷开发团队,由不一样技能的成员组成,经过紧密协同,完成每一次迭代的code
目标,交付产品。blog
sprint及敏捷中的每一次迭代冲刺。排序
在整个项目管理中,核心的角色有产品经理、项目经理、研发团队和测试团队四种角色,这项目管理
四种角色对应于敏捷开发中的product owner、scrum master、scrum team(DEV和QA)。这几种角色之间牢牢围绕产品的需求展开协做,取得成果。开发
【流程解释】:
sprint制定的目标是否合理,开发、测试之间的配合是否顺畅,直接致使了最终交付物的质
量。所以,本文根据过往的产品开发经验,总结出一套适用于敏捷流程的节奏。
每一个sprint采用6+3+1的节奏。其含义为:一个sprint包含6天开发工时,3天测试工时,1天上线及next sprint冲刺。
核心代码在正式编码以前,须要经过TC(技术委员会)或者Senior Engineer的技术评审,
评审经过以后,须要按照评审经过的方案进行coding。
coding完成以后,通知TC或者Senior Engineer组织code review。code review经过以后,才容许将代码合并到公共的开发分支。
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中打上标签。