近期根据我们DevOps开发团队敏捷开发项⽬的实践经验，将完整流程整理如下，这份规程也不完全算是敏捷专属的项⽬管理规程，主要是在结合我们公司实际的情况下编写出来的，⼤家在实际过程中可以参考。

1. ⽬的

　　规范软件产品开发项⽬管理过程，指导开展项⽬研发、管理等活动。

2. 适⽤范围

　　本章程的作⽤范围为软件产品开发⽴项⾄结项管理过程。

　　1.对项⽬经理开展产品规划及设计活动以及项⽬管理⼿段和应遵循的开发流程提供了指导；

　　2.对项⽬团队的⽇常管理活动及内容进⾏了指导；

3. ⾓⾊及职责定义

Scrum Master——项⽬负责⼈、项⽬经理

　　保护团队不受外界⼲扰，是团队的领导和推进者，负责提升 Scrum 团队的⼯作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner ⼀起将投资产出最⼤化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

Product Owner——产品负责⼈、产品经理

　　确定产品的功能，拆分⽤户故事。

　　需求功能确定优先级。

　　接受或拒绝开发团队的⼯作成果。

　　参与产品开发过程中的有关会议。

UI

　　根据⽤户故事，负责产品的功能交互及界⾯设计

　　组织开展⼈机交互及⽤户体验，不断跟踪改进，提⾼产品表现⼒。

　　参与产品开发过程中的有关会议。

开发

　　根据⽤户故事，负责产品的技术架构设计及功能开发

　　评估、设计及维护产品相应模块，确保模块的稳定性、易⽤性、⾼效性。

　　参加产品开发过程中的有关会议。

测试

　　根据⽤户故事，设计产品测试标准，确保产品品质满⾜市场需求。

　　合理分配测试资源，组织产品测试并优化测试流程及测试标准，提⾼测试效率。

　　编写产品测试⽤例，提交测试问题，编写测试总结报告，以测试⾓度来确定产品版本是否发布。

4. Scrum中的产出物

Product Backlog——Backlog 待开发项，积压的任务。

　　产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。

Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度通常是⼀⾄两周。

　　在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产⽣本次 Sprint 要完成的 “已定 Product Backlog”。

　　已定 Product Backlog是 Sprint 计划会议的产物，它定义了团队所接受的⼯作量，在整个 Sprint 过程中它将保持不变。

User Story、Task——⽤户故事、任务

　　⽤ User Story 来描述 Sprint Backlog ⾥的项⽬，User Story 是从⽤户的⾓度对系统的某个功能模块所作的简短描述。⼀个 User Story 描述了项⽬中的⼀个⼩功能，以及这个功能完成之后将会产⽣什么效果，或者说能为客户创造什么价值。⼀个 User Story 的⼤⼩和复杂度应该以能在⼀个 Sprint 中完成为宜。如果 User Story 太⼤，可能会导致对它的开发横跨⼏个Sprint，此时就应该将这个 User Story 分解。为了能够及时，⾼效地完成每个 Story，Scrum 团队会把每个 Story 分解成若⼲个 Task。每个Task 的时间最好不要超过8⼩时，保证在1个⼯作⽇内完成，如果 Task 的时间超过了8个⼩时，就说明Task的划分有问题，需要特别注意。

障碍 Backlog——问题列表，积压的待处理事务。

　　列举了所有团队内部和团队相关的和阻碍项⽬的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

5. 项⽬管理过程

　　按照产品开发过程，可将整个过程分为项⽬启动、需求设计、开发测试、上线、运营跟进。下⾯分别阐述在每个阶段过程中该如何进⾏。

5.1 需求启动

　　通常是从准备项⽬启动会到召开会议这个阶段，需要完成项⽬⽬标，需求范围的初步确认，项⽬团队成员，其他资源的安排。

　　确定本次开发的初步⽬标并达成共识

　　对于项⽬⽬标，需要和⼲系⼈在以下⼏点上达成共识：

　　项⽬的背景、⽬标⽤户、核⼼⼈员及产品定位是什么

　　各⼈员在项⽬中扮演的⾓⾊和对项⽬的作⽤是什么

5.2 需求设计

　　将确定的需求整理并输出WIKI⽂档及产品原型

　　召开需求启动会，参加⼈员包括：项⽬经理及项⽬团队、其他⼲系⼈代表

　　主要议题包括：申明本期开发⽬标范围及对组织⽬标的贡献。

　　设定期望，统⼀思想

　　⽂档内容的宣讲。

5.3 开发测试

A、迭代N的需求细化

　　考虑每个迭代需要完成的⽤户故事；

　　⽤户故事需包含⼏个部分，⼯作量评估、功能性需求、⾮功能性需求。

　　⽤户故事编写完成后需要在团队内部进⾏需求评审，⼀⽅⾯是为了向团队成员解读该需求，另⼀⽅⾯团队成员也可在评审时给出指导性意见。

B、测试⽤例评审

　　测试⼈员根据⽤户故事要求编写对应的测试⽤例，并组织项⽬团队进⾏测试⽤例评审。根据评审意见修改测试⽤例

C、开发

　　将⽤户故事的需求开发的过程。

D、开发⾃测

　　在开发过程中，每完成⼀个功能点，都需要及时的进⾏开发⾃测并通知产品策划⼈员进⾏验收体验。

　　代码提交可通过更新Jira任务的状态来关联Gitlab中代码的提交及状态更新。

E、验收

　　开发完成后，产品策划需要对开发完成的成果进⾏验收，验证其是否符合⽤户故事的要求，验证通过后⽅可流到测试环节，否则需与开发详细讨论其不符合性，其验收的checklist可做⽐较。

F、测试和回归

　　提交测试时，必须要有正确的版本。测试⼈员根据测试⽤例进⾏测试，在Jira中提交测试bug，并根据测试的⾓度给出产品是否发布的意见。

G、bug修改

　　在Jira中获取分配给⾃⼰的bug进⾏修改。

H、预⽣产发布

　　迭代⼀定版本后，在发布⽣产之前进⾏预⽣产测试。

5.4 上线

　　预⽣产测试通过后发布⽣产。

5.5 运营跟进

　　每⽇站⽴会

　　组织者轮流担任，负责控制节奏，记录问题，以备会后跟踪。

　　每⼈讲⾃⼰昨天做了什么，有什么问题，今天的计划是什么；

　　其他⼈了解别⼈的⼯作情况，并发现指出可能存在的问题。

　　对于发现的问题，⿎励认领，其余由项⽬经理指定责任⼈。

　　时间通常控制在15分钟内。

　　会议期间，更新任务墙。

　　周报：（1、反馈项⽬计划的执⾏情况，强调本周⼯作要达成的⽬标；2、暴露出项⽬的问题，特别是需要领导或其他团队需要协助的问题。周报可在IT平台中输出。）　　迭代回顾：每⼈讲述本次迭代做的好的地⽅和不好的地⽅，回顾上个迭代不好的地⽅，看看改进情况。

6. 总结阶段

　　项⽬经理指导产品经理收集总结项⽬的产品运营数据（度量指标），同时指导团队成员从⾃⾝⾓⾊进⾏总结，包括测试、开发、UI等。

　　由PM将过程⽂档和经验教训总结进⾏归档并制定改进产品计划。下载本文