敏捷开发项目的管理流程
导语：对于敏捷开发项目的管理流程，相关人员要清楚。下面是小编收集整理的敏捷开发项目管理流程，供各位阅读和参考。
前段时间给大家整理了敏捷开发的流程，最近在整理敏捷开发项目的流程和管理制度，其整理的项目管理规程如下，这份规程也不完全算是敏捷专属的项目管理规程，主要是在结合我们公司实际的情况下编写出来的，大家在实际嵌入到公司的过程中可以参考下，不能照搬。
1. 目的
规范互联网软件产品开发项目管理过程，指导开展项目研发、管理等活动。
2. 适用范围
本章程的作用范围为互联网软件产品开发立项至结项管理过程。
1.对项目经理开展产品规划及设计活动以及项目管理手段和应遵循的开发流程提供了指导；
2.对项目团队的日常管理活动及内容进行了指导；
3. 角色及职责定义
项目经理：
进行产品开发过程中的业务目标、进度、成本、质量控制。
挑选项目团队并进行团队建设，激发、鼓舞和改进团队的生产效率。
识别项目干系人，定期向干系人汇报，并作为团队和外部的接口，屏蔽外界对团队的干扰。
产品策划
确定产品的功能，拆分用户故事。
需求功能确定优先级。
接受或拒绝开发团队的工作成果。
参与产品开发过程中的有关会议。
UI
根据用户故事，负责产品的功能交互及界面设计
组织开展人机交互及用户体验，不断跟踪改进，提高产品表现力。
参与产品开发过程中的有关会议。
开发
根据用户故事，负责产品的技术架构设计及功能开发
评估、设计及维护产品相应模块，确保模块的稳定性、易用性、高效性。
参加产品开发过程中的有关会议。
测试
根据用户故事，设计产品测试标准，确保产品品质满足市场需求。
合理分配测试资源，组织产品测试并优化测试流程及测试标准，提高测试效率。
编写产品测试用例，提交测试问题，编写测试总结报告，以测试角度来确定产品版本是否发布。
4. 项目管理过程
按照互联网软件产品项目开发过程，可将整个项目管理过程分为立项过程、规划过程、执行与监控过程、结项过程。下面分别阐述在每个阶段过程中该如何进行项目管理。
4.1 立项过程
互联网软件产品开发项目的立项过程，通常是指从准备项目启动会到召开会议这个阶段，在立项过程中，需要完成项目目标，需求范围的初步确认，项目团队成员，其他资源的安排。
确定项目的初步目标并达成共识
对于项目目标，需要和干系人在以下几点上达成共识：
项目的背景、目标用户、核心人员及产品定位是什么
项目的资源投入预算是多少
项目的资源投入是多少
准备启动会议文档
文档内容包括：
用户画像
产品定位
市场策略
业务目标
技术可行性
研发成本预算
路标规划
召开项目启动会
参加人员包括：
管理层代表
其他干系人代表
主要议题包括：
申明项目目标范围及对组织目标的贡献。
管理层正式任命PM，设定期望，统一思想
文档内容的宣讲。
与PM小组确定项目管理要求
项目启动会完成后，需要与PM小组成员确定项目立项机制以及公司项目管理要求。
4.2 规划阶段
在规划阶段，团队需要共同完成产品的版本规划，迭代计划
版本规划
从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性，在规划完成后需要在项目干系人内达成共识。具体可参考《版本规划样例》
迭代如何划分
迭代划分是指将特性列表拆分形成用户故事列表，并将其对应的主要任务划分到各个迭代中去，形成粗粒度的项目迭代计划。这个过程主要考虑以下几个因素：
有些任务间是有依赖关系，某个任务的开始或结束是以另一个任务的.开始或结束为前提，在划分时必须考虑这种前后依赖关系。
在安排每个迭代的任务时，需要对各种因素进行综合考虑，如平衡每个迭代中任务的技术难度和价值差异。
除了进行初步的迭代任务划分，还需要确定项目过程中迭代任务调整的规则，如迭代任务未完成时是将剩余任务延至下一迭代还是延长迭代周期。
确定人员分工
项目经理需要根据每个人员的能力和特点，初步拟定大致分工。在进行任务分工时需考虑以下因素：
任务难度与人员能力相匹配，对于明显超出能力范围或过于简单的任务容易造成负面影响。
耦合度高的尽量分配给同一个人，避免不必要的沟通消耗。
鼓励团队内部“任务认领”，提高人员的工作积极性和主动性。
确定迭代运行模式
制定其他辅助计划
制定沟通计划、风险计划和质量计划是必要的，沟通计划主要包含以下几个方面：沟通对象、沟通方式、沟通频率即可，如：
风险计划包括风险项、负责人、重要性、应对措施，如下：
质量计划包括：bug分布满足何种条件可以发布，有几个致命bug必须停止开发新特性等。。
搭建基础技术架构
如果是一个全新的项目，需要重新开发系统框架，则这个工作应该在迭代0完成，否则会影响后期的工作开展。系统框架的每次改动必然会导致大量的重复工作量，从而给稳定的团队节奏带来很大的毛刺。
4.3 项目执行和监控过程
迭代N的执行
A、迭代N的需求细化
考虑每个迭代需要完成的用户故事；
用户故事需包含几个部分，工作量评估、功能性需求、非功能性需求。具体的可参考《用户故事模板及样例及拆分说明》
用户故事编写完成后需要在团队内部进行需求评审，一方面是为了向团队成员解读该需求，另一方面团队成员也可在评审时给出指导性意见。
B、测试用例评审
测试人员根据用户故事要求编写对应的测试用例，并组织项目团队进行测试用例评审。根据评审意见修改测试用例
C、开发
将用户故事的需求开发的过程。
D、开发自测
在开发过程中，每完成一个功能点，都需要及时的进行开发自测并通知产品策划人员进行验收体验。
E、验收
开发完成后，产品策划需要对开发完成的成果进行验收，验证其是否符合用户故事的要求，验证通过后方可流到测试环节，否则需与开发详细讨论其不符合性，其验收的checklist可以参考《产品验收checklist及模板》
F、测试和回归
提交测试时，必须要有正确的版本。测试人员根据测试用例进行测试，在IT平台中提交测试bug，并根据测试的角度给出产品是否发布的意见，输出《测试报告》
G、bug修改
在IT平台中获取分配给自己的bug进行修改。
H、showCase
阶段性必须有可体验版本进行showCase.需要
确定showCase时间：某个迭代开发、自测完成，准备提交测试前
会议前1-2天发出体验版给到参与人员
会议期间，由项目经理组织大家体验、反馈问题、记录问题。
项目经理根据问题情况，与开发或产品确定问题的解决时间并发出会议纪要。
I、灰度发布
迭代一定版本后，由项目经理与团队共同决定是否需要进行灰度发布。
监控方式
每日站立会
主持人轮流担任，负责控制节奏，记录问题，以备会后跟踪。
每人讲自己昨天做了什么，有什么问题，今天的计划是什么；
其他人了解别人的工作情况，并发现指出可能存在的问题。
对于发现的问题，鼓励认领，其余由项目经理指定责任人。
时间通常控制在15分钟内。
会议期间，更新任务墙，任务墙样式如下：
周报
反馈项目计划的执行情况，强调本周工作要达成的目标
暴露出项目的问题，特别是需要领导或其他团队需要协助的问题。
周报可在IT平台中输出。
月报
反馈项目当月的执行情况，包括进度、人力及质量。
反映项目存在的问题和风险。
迭代回顾
每人讲述本次迭代做的好的地方和不好的地方
回顾上个迭代不好的地方，看看改进情况。
让每个人发言。
每次迭代回顾会议完成后，可更新燃尽图
4.4 结项阶段
项目经理指导产品策划收集总结项目的产品运营数据，同时指导团队成员从自身角色进行总结，包括测试、开发、UI等。
项目经理与项目团队成员给出项目总结报告，内容可参考《项目经验教训总结-项目团队》，《项目经验教训总结-项目经理》
召开结项会议，各成员进行结项汇报。
PM小组将过程文档和经验教训总结进行归档。
