敏捷项目整体流程框架如图所示。
立项
目的：确定项目是否有实现的价值及是否具备进入实施的条件。
角色：业务方、Scrum团队及评审专家组。
输入：业务方原始需求、商业需求文档（Business Requirement Document，BRD）、立项报告。
输出：初步的产品待办列表、立项评审记录。
执行：具体参见如下内容。
立项前准备
（1）对于从0到1的新系统（从无到有的创新业务、创新产品，没有遗留系统和遗留架构做基础和参考），开发团队需要进行整体的、前瞻性的架构设计并经过架构评审。开发团队需要将架构设计文档上传到文档工具中。
（2）SM确立初始的迭代发布计划，包括定义迭代周期、规划迭代次数及每个迭代主要开发的功能。迭代周期通常为两周，如果是以小需求开发为主的团队（如流程中心团队），其迭代周期可缩短为一周。
（3）PO确立初始的版本发布计划，包括中间版本和最终版本。
（4）规划的内容是颗粒度较大的需求，不进行细节规划，并且包含运营推广的周期和活动。
（5）PO将条目化的需求记录在项目行云空间的“未计划区域”内，并按照优先级进行排序，形成Product Backlog。
立项评审
敏捷项目的立项评审过程参照《企业信息化部研发项目标准立项流程》执行。注：在启动敏捷转型之前，部门已经有了立项流程，在敏捷转型之后，仍然沿用原来的立项流程。
制订整体版本发布计划
目的：确立整体版本和迭代计划。
角色：Scrum团队、业务方。
输入：初步的产品待办列表。
输出：版本发布计划和迭代计划。
时间：立项会议之后。
执行：具体参见如下内容。
（1）Scrum团队和业务方共同对需求进行梳理，规划出多个版本及多个迭代（建议采用用户故事地图的方法进行需求梳理）。在此基础上，Scrum团队和业务方就版本发布日期达成一致。
（2）对于多个用户故事的串联，PO需要绘制业务流程图。
（3）Scrum团队需要制定自己的DoD标准，参考样例如下。
迭代DoD
- 所有代码都已通过静态检测，严重问题都已修改；
- 执行并通过了自动化验收测试和单元测试；
- 所有新增代码都经过同行评审并通过；
- 所有用户故事都有对应的测试用例并且测试用例均通过评审；
- 所有测试用例已经被执行并通过并且测试结果有记录；
- 所有完成的用户故事都通过业务方的验证或者团队能够演示本轮迭代的成果并得到业务方的认可。
发布DoD
- 完成发布规划所要求的重点需求；
- 至少通过一次全量回归测试；
- 修复所有等级为A、B的缺陷；C级、D级缺陷不超过20个。
版本DoD
- 产品文档已全部更新；
- 代码已部署到产品服务器上；
- 运维在验收测试环境上进行冒烟测试并通过；
- 原始需求提交人已验收功能。
每周DoD
- 上周发现的缺陷已经解决；
- 上周新增功能的自动化测试已经加入每周测试集。
每日DoD
- 搭建每日构建环境，进行自动静态代码检查、编译、部署和测试；
- 下班前必须签入（Check In）当天编写的代码，签入的日志要填写清晰；
- 所有新增代码都进行了自测并通过；
- 当天的代码必须经过同行评审（Peer Review）；
- 检入的功能代码必须要有对应的单元测试；
- 对于当天持续集成、构建环境中的问题，要当天解决。
用户故事DoD
- 用户故事的最终描述符合INVEST原则；
- 用户故事被对应的自动化测试用例覆盖；
- 每个用户故事都有对应的验收标准；
- 用户故事得到PO的验证和确认。
项目执行
项目执行过程
敏捷项目执行过程如图所示。
迭代计划会议
目的：确定当轮迭代需要完成的任务及对如何完成达成共识。
角色：Scrum团队。
时间：每轮迭代开始的第一天。
输入：Product Backlog。
输出：Sprint Backlog。
执行：具体参见如下内容。
（1）迭代计划会议Ⅰ：Scrum团队需要计划本轮迭代要做的工作。PO按照优先级从Product Backlog中选出本轮迭代要完成的需求，并逐一向开发团队进行介绍。开发团队最终自己选择本次迭代要开发的需求数量。
（2）迭代计划会议Ⅱ：开发团队要讨论如何实现所选择的需求。开发团队对所选择的需求进一步进行拆分。每个被拆分的需求再被拆分成技术任务并被估算。为保证需求的快速流动，实现持续演示和交付，技术任务的粒度须控制在1天以内，被拆分的需求粒度需控制在3天以内。需求和任务的拆分过程也是对产品进行系统设计的过程。
（3）开发团队参考自身速率，承诺实现与自身能力相匹配的需求数。
（4）开发团队成员认领任务，无须领导指派。
每日站立会议
目的：同步信息，暴露风险和问题。
角色：开发团队、SM。
时间：每天固定时间。
输入：更新后的行云看板。
输出：待跟进事项。
执行：具体参见如下内容。
（1）在每日站立会议召开之前，研发人员要在行云看板里更新各自任务的状态。
（2）开发团队每天在固定时间召开站立会议，由SM和开发团队成员轮流主持，会议时间控制在15分钟以内。
（3）开发团队成员每人简述3个问题：昨天我完成了什么工作、今天我计划做什么工作、在工作中我遇到了什么障碍。
（4）开发团队成员不对问题进行深入讨论，如有必要则另外组会。
迭代开发
目的：产生可交付的增量。
角色：Scrum团队。
时间：迭代计划会议之后。
输入：Product Backlog、Sprint Backlog。
输出：产品增量。
执行：具体参见如下内容。
1．设计
（1）为支持在敏捷过程中不断变更、涌现的需求，设计架构要保持足够的可扩展性，以满足持续部署、按需发布的要求。
（2）在迭代过程中，开发团队需要对当前复杂的或有风险的重点功能进行概要设计，并经过设计评审。开发团队需要将非正式设计文档上传到文档工具中。
（3）在前一个迭代中，UED工程师需要将交互设计、UI设计及前端代码准备好。
（4）PO组织业务方、评审专家或关键目标用户（真实用户）对产品设计原型进行评审，以保证原型符合用户的使用习惯。
（5）PO要进行产品数据埋点设计，并对接研发人员进行实现。
2．编码
1）持续集成
（1）开发团队使用iWork工具平台进行持续集成。
（2）要求持续集成满足一定的频率：研发人员每次提交代码至代码库时触发持续集成，如果在固定时间进行持续集成，每天至少集成2次。
2）代码重构
在每轮迭代中，开发团队都要预留一定时间（如迭代总工时的5%～10%）进行代码重构，以便让代码变得更整洁、易读。
3）代码检查
（1）敏捷项目需要接入静态代码扫描平台。研发人员提交代码至代码库时，工具自动执行静态代码扫描。研发人员每天需要对重要的问题代码进行修正。
（2）针对核心代码，开发人员之间要进行同行评审，也可以采用小组评审的方式。
3．测试
（1）研发人员需要对复杂的、核心的功能进行单元测试。
（2）在每轮迭代中，测试人员都要参与测试，并在迭代前期撰写测试用例。
（3）在每个被拆分的需求完成后，测试人员要及时进行测试，不能累积。
（4）对于前端和后端之间的接口、对外或者其他系统提供的接口，要进行自动化接口测试。
（5）PO要设计并执行用户体验测试用例，针对测试中发现的问题要制定具体改进计划。
（6）A级和B级Bug要求在当前迭代内修改完成。Bug分级标准如表所示。
（7）适合自动化验收测试的项目，利用TAAS平台进行自动化验收测试。
（8）自动化验收测试的适用原则：
- 非一次性项目（有扩展性或后续需要维护）；
- 流程复杂；
- 0级和1级重点系统（主流程）。
需求梳理会议
目的：为研发人员进行更为准确的任务拆分和迭代估算提供依据，为下一次迭代计划会议的有效执行做好准备。
角色：Scrum团队。
时间：推荐在每个迭代的中期进行。
输入：调整前的Product Backlog、新的需求信息。
输出：经过更新的Product Backlog。
执行：具体参见如下内容。
（1）PO可以组织团队全员参加需求梳理会议，也可以单独和部分相关人员进行需求梳理。
（2）以PO为主导，对Product Backlog中的内容进行调整、补充和完善。
（3）在会议前，PO准备好下一个Sprint（最多下两个Sprint）的用户故事。
迭代评审会议
目的：团队演示Sprint成果，获取业务方的反馈。
角色：Scrum团队、项目经理、业务方、相关利益干系人。
时间：迭代的最后一天。
输入：本轮迭代可演示的成果。
输出：业务方、相关利益干系人和PO的反馈。
执行：具体参见如下内容。
（1）Scrum团队需要邀请业务方（包括关键决策人）及相关利益干系人参加迭代评审会议。
（2）开发团队需要演示当轮迭代已完成的功能。PO、业务方及相关干系人对其进行评审和反馈，并做出拒绝或接受的决定。
（3）开发团队需要记录所有的反馈意见。
（4）Scrum团队需要审议DoD的完成情况。
迭代回顾会议
目的：发现迭代过程中的问题以持续改进。
角色：Scrum团队、项目经理。
时间：发生在一个迭代评审会议之后，下一个迭代计划会议之前。
输入：改进建议。
输出：迭代回顾会议的会议纪要。
执行：具体参见如下内容。
（1）SM主持会议。会议要在友好、平等和放松的状态下进行，SM要引导大家畅所欲言。
（2）Scrum团队需要回顾和反思在整个迭代过程中哪些地方做得好，哪些地方还需要改进。
（3）针对发现的问题，Scrum团队要讨论出具体的解决方案。
（4）Scrum团队需要将高优先级改进项作为任务，并纳入下一个迭代进行处理。
结项
目的：按照部门的规范结束项目。
角色：项目经理、PO、业务方。
输入：《项目总结报告》《结项申请》。
输出：结项审批意见。
时间：团队和业务方约定的结项日期。
执行：具体参见如下内容。
（1）在约定的结项日期内，核心功能应已经完成并通过业务方验证。
（2）如有未完成的非核心、非关键业务功能，如用户体验类、优化类等功能，可通过维护或者新立项目的方式进行开发。
（3）结项具体过程参照《结项管理规范》执行（仍然沿用部门原有结项管理规范）。
