敏捷研发流程总图

验收

验证通过

用例评审

3.4冲刺阶段冲刺阶段，每天由Master安排站会，跟进每个项目成员的任务进度。站会的形式不限于“站会”，可由Master与成员1对1跟踪进度，也可以全员会议室坐聊10分钟，或者在迭代沟通群里每人汇报任务进度，具体由Master根据现状安排。发布日的前一天（推荐下午3点）需安排全员站会，跟踪待发布需求任务的最新情况、存在的风险、能否按计划发布（或能否取消发布）。全员参加以便知晓自身负责的任务的相关任务的进度。另外，仪式感很重要，明天要发布了，请紧张起来。3.4.0分支管理（重要）1、一个（或一组需同时上线/取消的）需求拉一个开发分支，以需求号命名。2、测试人员在开发分支测试对应的需求功能，测试通过后合并dev分支。3、测试人员在dev分支进行第一轮回归测试，尽可能多的覆盖已测分支。4、dev分支回归测试通过后，可通知产品进行需求验收。5、dev分支完成回归测试和需求验收后，合并到master分支。6、测试及产品人员在master分支进行第二轮回归测试/验收测试。7、master分支测试通过后，由开发人员打tag，并通知给测试人员。8、测试人员发《测试报告&验收通知》邮件，附带tag标签号。9、需求验收后，测试人员发《上线通知》，附带tag标签号。10、发布验证通过后，测试人员发《上线结果》邮件，附带tag标签号。

评审通过

交   付

提测

公示结束

3.5交付阶段3.5.0发布1、发布的前一天，由Master组织全员站会，跟踪待发布的需求的进度情况。2、发布当天还处于测试中的需求，取消上线。3、全部待发布的需求，应均已通过产品验收。4、由测试人员发测试报告邮件，产品人员答复测试报告邮件说明验收情况。5、全部需求均有邮件答复验收通过后，由测试人员发起上线通知邮件。6、收到上线通知邮件后，由开发人员开始发布流程。7、发布审核、发布操作，使用公司的发布管理系统。3.5.1发布验证1、发布完成后，测试人员或产品人员对发布进行验证，确认发布是否正确。2、完成需求功能的发布验证后，答复上线通知邮件说明发布验证情况。3、全部需求均有邮件答复发布验证通过后，由测试人员发起上线结果邮件。4、Master转发上线结果邮件给需求对应的业务人员，提醒线上验收。3.5.2线上验收1、业务人员对上线的需求进行验收，并答复验收通知邮件说明验收结果。2、若上线的需求验收不通过，记录故障并进行复盘，不紧急可放到下个迭代。3、全部上线的需求均有邮件答复线上验收通过，本次迭代成功结束。3.5.3线上跟踪1、线上验收通过的版本功能，由产品和业务人员持续观察一段时间，排查问题。Master对迭代的责任永存，线上跟踪发现的问题向对应迭代的Master反馈处理。

发布完成

3.2启动阶段启动阶段是迭代冲刺的前期预备工作，决定迭代冲刺的工作内容，非常重要。1、提前确定好新迭代的Master人选。2、由Master创建【Sprint】迭代冲刺和迭代沟通群等。3、预定会议室，包含迭代会、设计评审、用例评审等。3.2.1需求公示（重要！）1、由产品按照优先级拖拽backlog的需求到新Sprint的待办列表，进行需求公示。2、TL及时为需求分配对应的开发/测试人员，促使相关人员尽早进行沟通讨论。3、开发/测试人员阅读被分配的需求内容，描述不准确的地方可直接找产品询问。4、产品人员应该主动与开发和测试人员解说需求内容，讨论可能的实现方案。5、在迭代会之前，产品、开发与测试三方应已充分沟通各个需求内容，并达成一致。6、需求公示的投入产出比极高，充分前期沟通，可大幅降低返工成本。3.2.2迭代会1、只有Master可以组织迭代会。2、（正常情况下）迭代会是需求进入迭代研发流程的唯一窗口。3、由产品轮流发言，只对需求背景或业务痛点进行介绍（而非说明需求内容！），以便让研发成员能够更好的理解需求目标。4、开发/测试人员要对需求细节进行确认，同时确定【业务复杂度】和【技术复杂度】。5、迭代会控制在2个小时以内，平均每个需求评审2分钟，最长不超过6分钟(超时驳回)。6、由Master记录需求的评审结果和备注待确认问题。7、迭代会结束后，由Master发迭代会需求评审结果邮件。8、通过评审的需求，开发人员编写设计文档，测试人员编写测试用例。9、未通过评审的需求，由产品当天进行需求补充和问题确认。10、【业务复杂度】和【技术复杂度】双低的需求，可省略设计和用例文档。

设计评审

线上跟踪

测试

测试通过

计   划

验收通过

严禁！直接找开发/测试人员私下进行需求变更。开发人员和测试人员同样严禁私下接受需求变更，任何变动都要与Master进行确认。

1【名称解释】避免理解上的歧义统一定义特定词含义。1.1【迭代】 在一个多方认可的研发周期内，完成一批功能需求的开发、测试、验收、发布等工作。1.2【研发】 “研发”是功能从需求到交付的全过程，不单指编码。1.3【研发人员】包含产品、设计、前端/后端/app开发、大数据开发、测试、DBA&运维等人员。1.4【研发过程】包含需求评审、设计及评审、用例及评审、编码、提测、测试、验收、发布、发布验证。1.5【提测日】（重要！） 需求全天进入测试阶段的日期，即提测日前一天已经完成编码及自测。1.6【缺陷】缺陷是指研发过程中发现的Bug，发布之前应全部修复。暂不修复的缺陷发布后转为故障。1.7【故障】 故障是指线上已知的Bug。故障与需求一起由迭代会进入研发流程，待遇等同于需求。1.8【需求验收】产品经理或业务代表在测试环境对需求进行验收，验收通过才可以安排后续的发布上线流程。1.9【发布验证】 发布完成后，对发布过程进行验证，包括但不限于：代码版本检查、上线功能的验证、主流程回归测试、线上关键数据观察、数据库表结构变更确认、服务器日志跟踪等。1.10【业务验收】发布成功后，发送邮件通知业务人员对上线的需求功能进行验收，并答复邮件反馈验收结果。

发布验证

需求公示

3.4.1编码1、开发人员按照设计进行需求功能的编码工作。2、设计出现变动，需及时同步给相关产品、测试、TL、Master。3、自测/联调通过，并且由其他开发人员codereview通过，编码工作才算完成。4、完成编码工作后，开发人员进行提测。3.4.2提测1、开发人员进行提测操作，告知测试人员可以开始测试。2、测试人员对提测的需求进行冒烟测试，若测试不通过，则进行提测打回操作。3、提测通过邮件或项目管理工具执行，不得以口头/聊天记录等形式传达。3.4.3测试1、测试人员对需求功能进行冒烟测试，冒烟测试通过后，进入正式测试。2、测试人员依据测试用例进行需求的测试工作，如功能测试、接口测试、压力测试等。3、测试过程中发现缺陷（bug），提交缺陷，并进行缺陷跟踪。（缺陷跟踪流程）4、需求对应的测试用例全部执行，且发现的缺陷全部修复成功，此需求测试完成。3.4.4验收1、某个需求的测试工作完成，测试用例全部执行，发现缺陷全部修复，可以进入验收。2、由测试人员和开发人员协助产品人员在测试环境进行需求的验收工作。3、验收失败的需求，开发人员和测试人员继续修复和测试。4、验收通过的需求，才可进行发布线上生产环境。5、原则上验收不可在代码的需求分支上进行，应在master（或至少dev）分支进行。

启  动

自测通过

冒烟通过

6需求变更管理（重要！！）6.1需求变更需求变更需先与Master沟通变更内容和变更必要性，评估风险和工作量后，由Master决策是否接受需求变更和调整排期计划。严禁！直接找开发/测试人员私下进行需求变更。开发人员和测试人员同样严禁私下接受需求变更，任何变动都要与Master进行确认。6.1.1需求插入1、开发阶段：基于优先级，插入高优先级新的需求，可能暂停部分优先级较低的需求。2、测试阶段：（除特殊情况）不接受需求插入。6.1.2需求修改1、未提测：设计文档和测试用例同步修改，重新评估上线日，可延续到下个迭代。2、已提测：（除特殊情况）不接受需求修改，但本次需求可暂停研发。6.2特殊情况特殊情况需进行上报审批，发紧【急变更邮件】给技术总监&测试总监进行审批。【审批失败】研发团队不接受需求变更的要求，但期望变更的需求可以接受暂停研发。【审批通过】由Master评估风险和工作量，调整排期计划，可能暂停部分优先级较低的需求。1、紧急线上故障：发生紧急线上故障，优先解决故障保证业务的运转。2、紧急政策变化：影响公司收益或产生损失的合规性的功能调整。3、紧急需求变更：由产品人员或业务人员基于某些原因发起的紧急需求变更。

编码

冲  刺

阅读需求

3.3计划阶段3.3.1设计评审1、开发人员完成自己负责的需求的设计文档后，发给TL进行汇总。2、设计评审会，由开发人员讲解自己的设计思路，基于设计反讲实现的功能。3、测试人员和产品人员要对设计内容进行确认和提问。4、由Master记录设计的评审结果和备注待确认问题。5、设计评审会结束后，由Master发设计评审结果邮件6、设计评审当天下班前，开发人员需填写需求的【提测日】。        注意【提测日】的统一定义：需求全天进入测试阶段的日期。3.3.2用例评审1、测试人员完成自己负责的需求的设计文档后，发给TL进行汇总。2、用例评审会，由测试人员讲解自己测试用例设计和覆盖的业务需求点。3、开发人员和产品人员要对设计内容进行确认和提问。4、测试人员与开发人员共同挑选冒烟测试用例，作为开发自测用例。5、由Master记录用例评审结果和备注待确认问题。6、用例评审会结束后，由Master发用例评审结果邮件。7、用例评审当天下班前，测试人员需填写需求的版本（上线日）。3.3.3排期公示1、Master跟进每个需求任务的提测日和版本的填写。2、用例评审当天下班前，由大Master发排期公示邮件。3、排期公示时间为24小时。（推荐周五，周末2天时间可作为缓冲）4、公示期间对排期有异议可以直接找Master协调修改。5、排期公示时间结束后，排期正式生效，由大Master发排期公告邮件。排期正式生效后，出现排期变动，需走变更流程。

发布

敏捷研发流程总图

排期公示

迭代会