敏捷开发项⽬管理流程
前段时间给⼤家整理了敏捷开发的流程，最近在整理敏捷开发项⽬的流程和管理制度，其整理的项⽬管理规程如下，这份规程也不完全算是敏捷专属的项⽬管理规程，主要是在结合我们公司实际的情况下编写出来的，⼤家在实际嵌⼊到公司的过程中可以参考下，不能照搬。1. ⽬的 规范互联⽹软件产品开发项⽬管理过程，指导开展项⽬研发、管理等活动。 2. 适⽤范围
本章程的作⽤范围为互联⽹软件产品开发⽴项⾄结项管理过程。
1.对项⽬经理开展产品规划及设计活动以及项⽬管理⼿段和应遵循的开发流程提供了指导；
3. ⾓⾊及职责定义
项⽬经理：
进⾏产品开发过程中的业务⽬标、进度、成本、质量控制。
挑选项⽬团队并进⾏团队建设，激发、⿎舞和改进团队的⽣产效率。
识别项⽬⼲系⼈，定期向⼲系⼈汇报，并作为团队和外部的接⼝，屏蔽外界对团队的⼲扰。
确保项⽬中流程被遵循，组织、监督、培训项⽬各实践活动。
产品策划
确定产品的功能，拆分⽤户故事。
需求功能确定优先级。
接受或拒绝开发团队的⼯作成果。
参与产品开发过程中的有关会议。
UI
根据⽤户故事，负责产品的功能交互及界⾯设计
组织开展⼈机交互及⽤户体验，不断跟踪改进，提⾼产品表现⼒。
参与产品开发过程中的有关会议。
开发
根据⽤户故事，负责产品的技术架构设计及功能开发
评估、设计及维护产品相应模块，确保模块的稳定性、易⽤性、⾼效性。
参加产品开发过程中的有关会议。
根据⽤户故事，设计产品测试标准，确保产品品质满⾜市场需求。
合理分配测试资源，组织产品测试并优化测试流程及测试标准，提⾼测试效率。
编写产品测试⽤例，提交测试问题，编写测试总结报告，以测试⾓度来确定产品版本是否发布。
4. 项⽬管理过程
按照互联⽹软件产品项⽬开发过程，可将整个项⽬管理过程分为⽴项过程、规划过程、执⾏与监控过程、结项过程。下⾯分别阐述在每个阶段过程中该如何进⾏项⽬管理。
4.1 ⽴项过程
互联⽹软件产品开发项⽬的⽴项过程，通常是指从准备项⽬启动会到召开会议这个阶段，在⽴项过程中，需要完成项⽬⽬标，需求范围的初步确认，项⽬团队成员，其他资源的安排。
确定项⽬的初步⽬标并达成共识
对于项⽬⽬标，需要和⼲系⼈在以下⼏点上达成共识：
项⽬的背景、⽬标⽤户、核⼼⼈员及产品定位是什么
项⽬的资源投⼊预算是多少
项⽬的资源投⼊是多少
各⼈员在项⽬中扮演的⾓⾊和对项⽬的作⽤是什么
准备启动会议⽂档
⽂档内容包括：
⽤户画像
产品定位
市场策略
业务⽬标
技术可⾏性
研发成本预算
路标规划
召开项⽬启动会
参加⼈员包括：
管理层代表
项⽬经理及项⽬团队
其他⼲系⼈代表
主要议题包括：
申明项⽬⽬标范围及对组织⽬标的贡献。
管理层正式任命PM，设定期望，统⼀思想
⽂档内容的宣讲。
与PM⼩组确定项⽬管理要求
项⽬启动会完成后，需要与PM⼩组成员确定项⽬⽴项机制以及公司项⽬管理要求。
4.2 规划阶段
在规划阶段，团队需要共同完成产品的版本规划，迭代计划 版本规划
从产品的关键特性列表中按照优先级规划产品每个版本需要完成哪些特性，在规划完成后需要在项⽬⼲系⼈内达成共识。具体可参考《版本规划样例》
迭代如何划分
迭代划分是指将特性列表拆分形成⽤户故事列表，并将其对应的主要任务划分到各个迭代中去，形成粗粒度的项⽬迭代计划。这个过程主要考虑以下⼏个因素：
有些任务间是有依赖关系，某个任务的开始或结束是以另⼀个任务的开始或结束为前提，在划分时必须考虑这种前后依赖关系。
在安排每个迭代的任务时，需要对各种因素进⾏综合考虑，如平衡每个迭代中任务的技术难度和价值差异。
除了进⾏初步的迭代任务划分，还需要确定项⽬过程中迭代任务调整的规则，如迭代任务未完成时是将剩余任务延⾄下⼀迭代还是延长迭代周期。
确定⼈员分⼯
项⽬经理需要根据每个⼈员的能⼒和特点，初步拟定⼤致分⼯。在进⾏任务分⼯时需考虑以下因素：
任务难度与⼈员能⼒相匹配，对于明显超出能⼒范围或过于简单的任务容易造成负⾯影响。
耦合度⾼的尽量分配给同⼀个⼈，避免不必要的沟通消耗。
⿎励团队内部“任务认领”，提⾼⼈员的⼯作积极性和主动性。
确定迭代运⾏模式
如⼀周迭代、两周迭代，每个迭代包含的⼯作内容等。
具体的迭代计划可参考《迭代计划样例》
制定其他辅助计划
制定沟通计划、风险计划和质量计划是必要的，沟通计划主要包含以下⼏个⽅⾯：沟通对象、沟通⽅式、沟通频率即可，如：
风险计划包括风险项、负责⼈、重要性、应对措施，如下：
质量计划包括：bug分布满⾜何种条件可以发布，有⼏个致命bug必须停⽌开发新特性等。。
搭建基础技术架构
如果是⼀个全新的项⽬，需要重新开发系统框架，则这个⼯作应该在迭代0完成，否则会影响后期的⼯作开展。系统框架的每次改动必然会导致⼤量的重复⼯作量，从⽽给稳定的团队节奏带来很⼤的⽑刺。
3.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平台中输出。
⽉报
反馈项⽬当⽉的执⾏情况，包括进度、⼈⼒及质量。
反映项⽬存在的问题和风险。
迭代回顾
每⼈讲述本次迭代做的好的地⽅和不好的地⽅
回顾上个迭代不好的地⽅，看看改进情况。
让每个⼈发⾔。
每次迭代回顾会议完成后，可更新燃尽图
3.4 结项阶段
项⽬经理指导产品策划收集总结项⽬的产品运营数据，同时指导团队成员从⾃⾝⾓⾊进⾏总结，包括测试、开发、UI等。
项⽬经理与项⽬团队成员给出项⽬总结报告，内容可参考《项⽬经验教训总结-项⽬团队》，《项⽬经验教训总结-项⽬经理》召开结项会议，各成员进⾏结项汇报。
PM⼩组将过程⽂档和经验教训总结进⾏归档。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议