(完整版)项目管理部项目管理流程草案

1、项目管理部项目管理流程草案 版本 所属部门 编写人 V1.0 项目管理部 冯林 角色说明：PM （项目经理）PO （产品经理）TL （技术主管）SA （架构师） QA （测试人员）UED （用户体验设计）DEV （开发人员） 敏捷管理流程 具体实施步骤： *第一阶段：需求建立阶段* *第二阶段：需求提交阶段* *第三阶段：需求评审阶段* *第四阶段：技术方案时间确定阶段 * *第五阶段：开发阶段* *第六阶段：测试阶段* *第七阶段：上线阶段* *第八阶段：总结阶段* 第一阶段：需求建立阶段 1.1 提出需求构想 参与方：项目经理，产品经理，运营 描述：产品经理或项目经理或运营人员根据目前的数

2、据，市场需求，产品趋势， 市场动向等方面，提出下一阶段产品改进或新产品的构想或规划，进行讨论， 了解该产品的实现方式是否可行，是否满足市场需要，是否有成功案例，产品 生命周期有多久，带来的效益如何。 方式：各种资料收集 1.2 产品构想私下讨论 参与方：项目经理，产品经理，运营，产品负责人 描述：将现状和目标明确，讨论是否可行。 方式：私下讨论 第二阶段：需求提交阶段 2.1 需求文档编写 参与方：产品经理 描述：根据市场需求和产品目标，编写相应产品文档，上传到 wiki 上并共享给 大家。 方式：编写文档 2.2 产品文档初审 参与方：产品经理经理，项目经理，产品经理，各部门经理。 描述：产

3、品经理发出产品文档初稿给各部门主管及项目经理，提出相关审核意 见，反馈到 wiki 中，进行保留，然后根据反馈情况进行文档修改，部门负责人 根据需求定义，目前的工作安排情况，分配人力资源。并确定相关的技术负责 人（TL） 方式：邮件或会议 第三阶段：需求评审阶段 3.1 产品文档共享 参与方：项目组成员，产品经理，项目经理，技术主管， QA，UED ，其他干系 人 描述：将修订版的需求文档发送给项目组成员。共享项目文档，准备会议，进 行需求评审 方式：邮件结合 wiki 3.2 需求评审 参与方：项目组成员，产品经理，项目经理，技术主管， QA，UED ，其他干系 人 描述：进行需求评审会议，

4、确定需求的可行性，项目组成员根据需求 方式： kickoff 会议 3.3PRD 更新及最终确定 参与方：产品经理 描述：根据需求评审会议上多方的反馈，进行 PRD 的编辑及修改，最终根据成 员的反馈进行修改和定版 方式：自行编写 第四阶段：技术方案时间确定阶段 4.1 工作分解 参与方：技术负责人，技术人员，项目经理， QA， UED 描述：根据需求文档，进行工作任务分解，将功能模块化，对模块进行估期和 管理，分配给相关技术人员。 方式：会议或私下，工作分解文档或 jira 4.2 任务分配排期 参与方：项目经理，技术负责人， QA ，UED 描述：根据工作分解的模块，根据目前的工作情况，将

5、拆分的工作包分给相关 技术人员和 QA 。并根据之前的排期进行甘特图的编辑，确定时间周期 方式：会议或私下， project 排期或 jira 4.3 共享时间进度排期表 参与方：项目经理，产品经理，技术主管，项目组成员， QA ，其他干系人，部 门经理 描述：将排期结果发送给项目组成员 方式：邮件 第五阶段：开发阶段 5.1 迭代开发 参与方：项目经理，技术主管，项目组成员 描述：根据排期进行开发工作，技术主管负责协调各方资源确保时间点的确立 方式：私下沟通 5.2 迭代站立会议 参与方：项目经理，产品经理，技术主管，项目组成员， QA 描述：每周或每个版本的迭代工作内容确定后，周知项目组成

6、员及干系人 方式：邮件， jira 共享，会议 5.3 里程碑会议 QA 参与方：项目经理，产品经理，技术主管，项目组成员， 描述：每个阶段完成后或每个里程碑点完成后，周知大家，进行下一阶段任务 方式：邮件， jira 共享，会议 第六阶段：测试阶段 6.1 产品自测 参与方：项目经理，产品经理，技术主管，项目组成员， QA 描述：提交测试的需求，产品进行自测。 方式： jira 提交 bug ，邮件 6.2QA 测试 参与方：项目经理，产品经理，技术主管，项目组成员， QA 描述：提交测试的需求， QA 进行测试，确认测试结果，进行测试迭代，覆盖 测试内容 方式： jira 提交 bug ，

7、邮件 第七阶段：上线阶段 7.1 提交上线 参与方：项目经理，产品经理，技术主管，项目组成员， QA ，运维 描述：技术提交上线方案，标明相关干系人，需求出处，更新功能点，更新路 径 方式： jira 更新单或纸质更新单 7.2 更新流程确认开始更新 参与方：项目经理，产品经理，技术主管，项目组成员， QA ，运维 描述：技术提交上线方案，运维人员进行线上服务更新，更新后通知相关人员 方式： jira 更新单或纸质更新单 7.3 线上回测 参与方：项目经理，产品经理，技术主管，项目组成员， QA ，运维 描述：QA在线上回测，重大功能无问题，功能需求实现，确认，如线上回测 影响其他功能或有重大

8、功能或需求没有时间，进行回滚 方式： jira 更新单或纸质更新单 第八阶段：总结阶段 8.1 上线邮件 参与方：项目经理 描述：汇总上线功能，影响业务，功能点发送邮件给公司员工或重要邮件组。 告知功能上线。 方式：邮件 8.2 数据统计 参与方：项目经理，产品经理，技术人员 描述：根据上线需求进行数据统计工作，埋点，分析，总结 方式：私下沟通，邮件 8.3 项目总结 参与方：项目经理，技术人员， QA 描述：根据项目情况给出项目总结，有点，不足，问题。汇总 QA测试文档, 提醒技术人员更新技术文档及接口文档。 方式：共享 wiki ， word jira ， wiki 敏捷项目管理流程 St

9、ep1 产品需求立项 1.1 需求构想，在工作及业务中收集需求 1.2 整理需求，将多方的需求整合整理汇总，进行细化和编写 1.3 进行需求评审，在产品部门内部进行需求平很，初步确定需求可行 1.4 共享需求文档，通过 confluence 能行需求共享，分享给大家，大家在 confluence 中进行评论和回复，提出自己意见，初步确定产品的思路和可行 性。 1.5 产品立项，通过立项会议进行产品立项工作， PM 召集 PO,DEV,SA,TL,QA,UED 成员一起讨论需求。明确目标和工作。提出反馈意 见，如无大异议，该项目正式成立，创建 jira 项目及 confluence 项目页，将

10、文档和内容共享 Step2 软件设计 2.1 将需求模块化细分，明确该需求分为几个 spring ，明确每个 spring 的目 标和工作内容，对 spring 进行 backlog 的分解。 2.2 产品经理通过 confluence 的需求编辑分出优先级。 2.3. UED 进行原型设计，制作保真模型、绘制使用流程图、设计视觉界面。 PO 根据对原型的反馈，完善需求文档及需求列表。（ 保真模型实例 流程图实例 视觉界面实例） 2.4. 讨论后的需求由 PM 在 Confluence 上整理 2.5. PM PO TL SA QA 需求评审，确保真正了解需求 需求评审不是目的，是否真正理解了

11、需求（系统要实现什么）才是关键 评审的形式不限，建议由非 PO 人员讲解 如果所有人已经达成了对需求的一致理解，则评审不是必须的 Step3 架构设计、项目计划 参与角色： PM PO TL SA QA UED DEV NOP 可能的输出：架构设计文档、 Release Plan 、 Roadmap 、测试策略、测试计 划、部署方案 3.1. SA 做概念和架构设计 概念设计，可以看成是为什么要做这个产品或模块，强调的是产品的路线规划、 市场趋势、客户价值、技术趋势等 架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、 多少组件、不同层次和组件之间关系是什么 我们经常把概念

12、设计和架构设计一起做，并统称为架构设计 实例 1 ：支付平台架构设计文档、实例 2 ：阿波罗客户端架构设计 3.2. PO 、 PM、 TL 把设计文档、需求列表综合考虑，制定版本计划（冲刺计 划）、 Release Plan （Roadmap ） 设计文档关注的是技术实现的先后顺序 需求列表关注的是业务的优先级 Release Plan 或者 Roadmap 为综合以上因素后的开发计划 实例 1 ：运河冲刺计划、实例 2：支付平台 Roadmap 33 同时，QA作出测试计划，NOP要作出部署方案 实例 1 ：Apollo 测试计划、实例 2：注册流程改造项目部署方案 3.4. 如果 Kic

13、k Off 时申请的资源不足、或者发生了变化，那么在此需要重新 组建团队。 Step4 迭代冲刺 参与角色： PM PO TL SA QA UED DEV 可能的输出：详细设计文档、 API 文档、测试文档、测试用例、冲刺计划、冲 刺总结 4.1. 项目开工会，如果所有团队成员对项目情况都非常了解，则这个会不是必 须的。 所有团队成员参加，团队成员介绍、项目背景介绍、项目目标、大致的计划时 间点，以及迭代前准备阶段的安排和任务分工等 4.2. 建立开发环境，如果已有环境，则这个步骤不是必须的。 开发工作机环境搭建（统一字符集、统一 IDE 版本） SVN 连续集成环境（ Hudson 、 Ba

14、mboo ） 代码 Review （ Fisheye 、Crucible ） JIRA wiki 申请 DEV 环境和 QA 环境 4.3. 冲刺计划会 PM PO TL SA QA UED DEV （ 实例 1：赶牛 V2.4.1 冲刺计 划、实例 2 ：支付平台 Sprint2 冲刺计划 ） 确定冲刺时间（一般为 13 周）或者版本发布时间 明确冲刺目标（完成需求列表中优先级最高的几个需求） 重新讨论、确定本次迭代需要实现的需求，达成共同理解 若有必要的话，则继续细化需求 对需求进行优先级排序 明确任务责任人（包括开发、测试）和任务完成时间点 在 JIRA 上跟踪任务 根据需求优先级和依赖

15、关系，严格按照需求驱动制定计划，尽量减少需求并行 开发 4.4. 开发、测试。每日站立会议。 PM TL QA DEV （UED） 每天定时进行站立会议 沟通昨天做了什么，今天要做什么、有什么问题 会议不超过 15 分钟 使用 GreenHopper 共享任务版，移动任务 4.5. 坚持代码 review 、撰写测试用例 DEV 、QA 使用 Fisheye 和 crucible 做代码检查 使用 Testlink 管理测试 代码规范 JavaScript 开发规范（上海） 代码规范（ .Net ）（上海） UED 部门代码规范 网站页面加入 WEBTRENDS SDC 日志统计代码规范 Ja

16、va 编码规范 1.0 （北京） 4.6. 输出技术文档、 QA 文档 实例 1 ：奔月相关技术文档、奔月相关测试文档 实例 2 ：阿波罗技术文档、阿波罗测试文档 实例 3 ：炒股大赛技术文档、炒股大赛测试文档 4.7. 冲刺评审会 PO PM DEV TL QA 团队与 PO 沟通冲刺完成了哪些工作 Demo 4.8. 冲刺回顾会 PM DEV QA TL PO （实例：支付平台冲刺回顾） 指出哪些方面 good ，哪些方面 bad 提出改进建议，并在下个迭代中实践 Step5 发布、维护 参与角色： PO、PM、QA、TL、DEV 、NOP 可能的输出：产品推广计划、 5.1. 产品推广计划讨论 BA PO 讨论产品的推广计划 5.2. 发布计划会 PO PM QA TL DEV NOP 确定发布时间、发布方式（升级 /下载新的客户端 / 直接覆盖上线） 确定上线计划 实例 1: 个股行情页上线计划 实例 2: 金牛港股奔月行情接入上线计划 5.3. 参考各个部门