项目管理过程定义.docx
《项目管理过程定义.docx》由会员分享，可在线阅读，更多相关《项目管理过程定义.docx（22页珍藏版）》请在冰点文库上搜索。
名称：
项目管理过程定义效力状态：
正式制度编号：
技术部-PM-101
项目管理过程定义
当前版本
V2.2
发布日期
2013-03-20
文档变更记录
版本
修订人
修订日期
修订内容
审核人
批准人
V1.0
程琳
2011-08-04
创建文档
EPG
仝永波
V2.0
刘霏
2012-08-30
增加项目策划过程活动，修改敏捷迭代过程活动内容。
EPG
仝永波
V2.1
刘霏
2012-10-24
修订“项目管理计划评审”的描述
EPG
仝永波
V2.2
刘霏
2013-3-5
修改里程碑评审方式，将估算基准功能选择“最小功能”修改为“典型功能”。
EPG
顾滢滢
说明：
1.修订日期格式统一为：
yyyy-mm-dd
2.修订内容中简要记录每次修订涉及的章节及内容。
目录
1. 目的 4
2. 适用范围 4
3. 定义、术语及说明 4
4. 主要角色与职责 4
5. 入口准则 5
6. 输入 5
7. 活动 6
7.1. 流程图 6
7.2. 工作流程 8
7.2.1. 项目策划 8
7.2.2. 敏捷迭代 10
7.2.3. 里程碑评审 13
8. 输出 13
9. 出口准则 13
10. 本过程裁剪规定 14
附录1项目整体估算细则（功能类比估算法） 15
附录2迭代任务估算细则 17
附录3项目数据管理规程 20
附录4禅道迭代建立细则 21
附录5迭代中任务贴条细则 22
1.目的
本文档用于指导和规范项目管理工作，涵盖了项目策划、迭代过程管理、项目监控等内容。
2.适用范围
本文档适用于普信恒业科技发展（北京）有限公司技术部所有软件项目。
3.定义、术语及说明
²迭代：
敏捷过程术语。
指重复反馈过程的活动，其目的是为了逼近所需的项目目标。
²QA：
QualityAssurance（质量工程师）
4.主要角色与职责
流程中的主要活动采用RACI模型对涉及的角色及其职责进行描述，其中：
²R（Responsible）代表执行：
负责执行任务和解决问题的角色。
²A（Accountable）代表责任：
对任务负全责的角色。
²C（Consulted）代表商议：
在任务实施前或实施中提供指定性意见的人员。
²I（Informed）代表告知：
及时被通知结果的人员，不必向其咨询、征求意见。
Task
Roles
产品经理
项目经理
项目团队
QA
高层经理
建立团队
I
A/R
/
I
C
过程裁剪
I
A/R
I
C
I
确定工作范围
A
R
I
I
C
项目估算
I
A/R
R
I
C
制定项目主计划
C
A/R
R
C
C
整合项目计划
C
A/R
R
R
C
项目计划评审
R
R
R
R
A
确定迭代目标及范围
A/R
C
I
I
I
迭代启动会
R
A/R
R
C
I
每日工作及站会
C
A/R
R
C
/
整理周报
I
A/R
R
I
I
迭代回顾会
R
A/R
R
R
I
里程碑评审
C
R
R
C
A
5.入口准则
²《产品需求规格说明书》通过评审。
6.输入
²《项目立项申请单》
²《产品需求规格说明书》
²组织标准过程集
7.活动
7.1.流程图
图7.1-1项目策划流程
图7.1-2迭代流程图
7.2.工作流程
7.2.1.项目策划
7.2.1.1.建立团队
项目经理组建项目团队，按照所需的角色进行分工，绘制组织结构图。
7.2.1.2.过程裁剪
根据《组织标准过程裁剪指南》和《组织标准过程裁剪细则》对生命周期模型、过程、工作产品进行裁剪，裁剪结果体现在《项目管理计划》中的“裁剪说明”章节。
7.2.1.3.确定工作范围
项目经理根据《产品需求规格说明书》和《项目立项申请单》确定项目的工作范围。
项目的工作范围有两部分，一是要交付的工作成果，如IT系统、用户手册等；二是在项目实施过程中产生的项目管理工作成果，如管理文档、过程文档等。
7.2.1.4.项目整体估算
项目经理采用“功能类比估算法”对项目进行整体估算。
详见《附录1项目整体估算细则（功能类比估算法）》。
7.2.1.5.制定项目主计划
7.2.1.5.1.制定总体进度计划
项目经理根据项目的阶段工作量和该阶段可能投入的人力资源确定阶段里程碑。
需要特别注意以下因素：
进度跟该阶段投入人员的知识和技能有关，还可能依赖于外部资源（例如采购）等内容。
制定《项目总体进度计划》，建议使用MSProject。
制定过程中，先制定项目进度计划表（含迭代计划），然后在其中的关键时点处标记出里程碑，并将各里程碑录入到《项目周报》中。
7.2.1.5.2.制定资源配置计划
项目经理按照进度计划及项目阶段，确定项目的资源配置，如设备、外购系统、组件、开发资源、测试资源、生产资源等。
7.2.1.5.3.制定团队所需技能和培训计划
项目经理应根据项目团队成员情况和项目的特点，找出项目组还没有掌握的知识和技能，以及人员变动时，新进成员不具备的相关知识和技能，安排需要的培训，以减少此类问题对项目进展的不利影响。
7.2.1.5.4.制定接口人列表
项目经理在计划中要考虑用户及与项目有关的第三方人员的参与，记录他们可能参与的事务内容、接口方式、所属组织、联系方式等信息。
接口人包括但不限于用户、外部接口人、分包方相关人员等。
7.2.1.5.5.制定风险管理计划
项目经理根据已掌握的项目数据及策划内容，制定《项目风险一览表》，识别项目风险、制定风险应对措施等。
详见《风险管理过程定义》。
7.2.1.6.整合项目计划
项目经理与其他过程的负责人共同整合质量保证计划、配置管理计划、度量与分析计划及测试计划等相关计划。
7.2.1.7.项目管理计划评审
评审过程及方式详见《同行评审过程定义》。
7.2.2.敏捷迭代
7.2.2.1.确定迭代目标及范围
1.在每个迭代启动之前，产品经理应明确此迭代的最终目标及工作范围。
2.项目经理负责制定详细的迭代计划。
3.项目经理发出迭代启动会的会议通知，并附带迭代计划内容供团队成员预读。
7.2.2.2.迭代启动会
启动会的目标是将计划的迭代目标及工作内容做出详细估算并责任到人。
首先，项目经理宣布本次迭代的目标及任务范围。
由产品经理或需求人员讲解需求，并解答团队成员的疑问。
其次，项目经理与项目团队成员一同分析或修正任务，并进行任务估算。
对每个工作任务，先由团队成员独立估算具体工作耗时，然后统一亮出各自估算的耗时，再由耗时最多和最少的两位成员分别陈述自己的解决方案及所需耗时的理由。
如果大家所估算的耗时差异较大，可安排再次估算。
当大家各自估算的耗时都趋于合理时，团队成员自由认领相应的任务。
项目经理需对任务的认领情况做出平衡，必要时可进行任务分配。
最后，当计划内的任务都分配完成后，项目经理在禅道中创建相应的迭代，由项目经理或指定人员录入迭代任务。
团队成员把自己的任务抄写到任务贴条，并张贴到任务板上。
详细的迭代估算过程见《附录2迭代任务估算细则》。
7.2.2.3.每日工作及站会
团队成员执行自己的工作任务，并及时更新禅道上的任务信息。
项目经理应时常监控任务状态，并适时给予必要的指导与纠正。
根据项目进展情况及时更新周报中的《问题事项一览表》及《项目风险一览表》。
项目组成员每天在固定的时间、固定的地点召开站会，会议时间控制在15分钟以内。
站会可以邀请相关干系人参加，但是只有团队成员、PM和PO可以发言。
每位团队成员都要聚焦三个主题：
“我昨天（或今天）完成了什么？
”、“我今天（或明天）准备完成什么？
”、“有什么障碍影响我的进展？
”。
站会上不应讨论与三个主题无关的事情（如技术解决方案等）。
对于简短的问题，可以在站会上讨论并解决。
若问题过于复杂，不能在3分钟内解决的，项目经理应单独安排会议时间解决该问题。
问题及解决情况应及时记录到《问题事项一览表》中。
7.2.2.4.整理周报
每周的最后一个工作日，项目经理应整理《项目周报》。
周报中汇报本周项目进展情况及下周工作计划，反映当前重大问题及重大风险。
在周报中对迭代目标达成率和迭代计划有效性进行度量，并预测近期里程碑的实现日期。
7.2.2.5.迭代回顾会
一个迭代即将结束时，项目经理应提前制定本迭代的汇报提纲，并发出迭代回顾会的会议通知。
迭代回顾会由两部分组织：
一是迭代演示会，由项目团队向产品经理及其他项目干系人展示本迭代开发的产品功能。
二是迭代回顾会，分为两个步骤：
①团队检视，每位团队成员针对项目提出改进点，由全体成员共同讨论项目中存在的最主要问题，并制定项目改进计划。
②个人检视，每位成员先写下自己的一条改进点，然后再写出其他每位成员的一个亮点，每位团队成员将自己所写内容展示给大家，并确定出个人改进计划。
对于改进点和亮点，可以参考个人考核指标中的要求来阐述。
对于会议上提出的事项和待采取的行动应在会议纪要中体现，并通知给相关人。
7.2.3.里程碑评审
依据项目计划，当项目达到里程碑时，项目经理应整理《项目里程碑报告》，并发起里程碑评审。
里程碑评审会议可以和迭代回顾会一起进行。
会议应该邀请业务部门-系统接口人、高层经理参与。
会上总结本阶段的情况，分析偏差，并演示阶段成果。
如果无法召开里程碑评审会，可以通过邮件将里程碑报告汇报给业务部门-系统接口人、高层经理。
8.输出
输出
管理级别
项目总体估算记录表
版本管理
项目总体进度计划
版本管理
项目管理计划
版本管理
禅道中的项目数据
权限管理
项目周报
权限管理
项目里程碑报告
权限管理
会议纪要
权限管理
9.出口准则
²项目结项。
10.本过程裁剪规定
本过程描述的所有活动均不允许裁剪。
附录1项目整体估算细则（功能类比估算法）
1.确定基准功能
首先，从《产品需求规格说明书》（或历史项目）中找出最具代表性的典型功能，以这个功能的指标（综合考虑规模和难度、项目管理、系统测试等因素）作为基准，规定此功能的基准系数为1。
同时估算出此基准功能的单元工作量。
注：
单元工作量包含详细设计、编码、代码走查、单元测试、系统测试及项目管理的工作量。
2.估算整体基准系数
依次将《产品需求规格说明书》中各个功能的综合指标与基准进行比较，得出对应功能的基准系数。
如果组织过程资产中存在同类项目的历史数据时，优先使用组织级历史数据进行估算。
例如：
基准功能系数为1，另一个功能的规模是基准的2倍，难度系统是基准的1.5倍，则：
该功能的基准系数
=规模系数×难度系数
=2×1.5=3。
3.估算总体工作量
各功能的基准系数估算完成后，用所有功能的系数之和乘以基准功能的单元工作量，即可得到当前需求对应的实现阶段工作量。
当前需求实现阶段总工作量
=当前需求所有功能的基准系数之和×基准功能的单元工作量
策划与设计阶段工作量
=当前需求实现阶段工作量×策划与设计阶段所占比率系数
另外，项目经理还需根据项目风险情况及以往经验确定一个预留缓冲比率。
完整需求实现阶段总工作量
=当前需求实现阶段工作量×（1+预留缓冲比率）
4.估算进度
根据工作量估算结果，结合项目可投入的资源，即可得到工作持续时间与迭代个数。
策划与设计阶段持续时间
=策划与设计阶段总工作量/参与人员数
实现阶段进度（以迭代个数表示）
一个迭代的有效工作量
=迭代周期×人员有效投入量
迭代个数
=完整需求总工作量/一个迭代的有效工作量
开发完成后，即进入UAT和试运行阶段，但此阶段的特点是按固定周期而不是按工作量。
所需时间由项目经理和产品经理商议确定，同时确定本阶段的人员投入量。
如果项目人员存在复用情况，则按实际投入的百分比计算。
项目总工期
=策划与设计阶段持续时间+迭代个数×迭代周数×5+UAT持续时间+试运行持续时间
示例：
参见《项目总体估算记录表》。
附录2迭代任务估算细则
敏捷开发时，最佳的估算是由包括将要做此工作的人在内的小组合作得到的。
首先，我们并不确定一项工作将由特定的哪个人来完成。
由于任何工作都可能被任何人完成，因此让每个人都参与估算是非常重要的。
其次，当一个人对工作做出估算时，其他人对他的估算值可能也有意见需要表达。
面对其他的人意见，当事人需要给出解释，以证明这个估算值的合理性。
推荐估算方法：
（项目组可自行决定使用何种方式）
1、估算的尺度：
最佳实践提供了一个很有效的估算尺度序列：
1、2、3、5、8。
这些数字可以被看成是一些桶，同样大小的东西将被倒入相应的桶中。
工作应该被看成是倒入这些桶的沙子。
选择与所估工作量最贴近的一个数字。
虽然0也可以做为一个估算值，但如果估算为0的话，很可能这个工作是不需要做的，而相应的任务也不需要分配。
实际情况往往是比0大一些，比1小一些，因为这里的0×10≠0。
如果有的用户故事规模过于庞大，需要我们使用13、20、40或∞的话，说明这个功能或任务需要拆分成更小的单元，以利于准确的估算，并且能在一个迭代中完成或产生有价值的成果。
2、常用的估算方法
Ø专家意见法
根据专家意见进行评估的一个好处在于它通常不需要太多的时间。
典型情况下，开发人员读一个用户故事，可能问一两个问题澄清一下，然后根据自己的直觉做出估算。
相当于把自己当成一个专家。
Ø类比法
对专家意见的一个替代方案是通过类比进行估算，就像我们说：
“这个用户故事比那个大一些”时所做的一样。
通过类比进行估算的时候，估算者将正在估算的用户故事与一个或多个其他用户故事进行比较。
如果这个故事的规模有两倍，就分配一个两倍的估算值。
以这种方式估算时，不用把所有的用户故事都对一个基线或是通用参数进行比较，而是把每个新用户故事和那些已经估算过的故事进行比较。
即把一个用户故事和一对其他的故事进行比较。
要判定一个用户故事是否应该估算为5点，就看一下它是否比一个你估算为3点的故事大一些，同时又比一个你估算为8点的故事小一些。
Ø分解法
分解是指将一个用户故事或者功能分解为更小、更容易估算的部分。
如果项目中的大部分用户故事都处于可以在2-5天完成开发的范围内，要对一个可能需要100天的用户故事进行估算是很困难的。
解决这个问题的办法，就是把这个大故事或者功能分解成多个小的部分来分别估算。
3.使用规划扑克
敏捷开发小组最佳的规划方法是打规划扑克。
它把专家意见、类比法和分解法融合到一种让人感到愉快的规划方法中，能够快速产生并且可靠的估算。
规划扑克的参与者包括小组的所有成员：
开发人员、测试人员、系统分析员、交互设计师等等。
小组人数一般不应超过10人，如果小组的人数超过10人，最好再分组。
每个小组可以分别估算，从而保证每个小组都不会太大。
PO参加规划扑克，但是不参加估算。
规划扑克开始的时候，发给每个人一叠卡片，每张卡片上写有一个有效的估算值。
例如：
0、1、2、3、5、8、13、20、40、100等等。
对于每个要估算的用户故事或者功能，由协调人（通常由PO或者一名分析人员担任）读出它的说明。
PO负责回答估算者提出的所有问题。
PO回答完问题后，每个估算者私下选择一张代表他的估算值的卡片。
等大家都准备好之后，一起亮出来，让所有参与者都互相看到彼此做出的估算。
如果估算值不同，就让估算值最高和最低的人分别说明他们的理由。
大家可以花几分钟来讨论这个用户故事和对它的估算。
讨论之后，每个估算者重新选择一张卡片进行估算。
很多时候，估算值在第二轮的时候就会汇聚起来。
如果没有的话，就继续重复这个过程。
这个做法的目标是让所有的估算值都汇聚到一个估算值上，将它用作这个故事的估算值。
如果始终无法汇聚，则由协调人酌情选定一个合理值，并询问与此有偏差的估算者是否能接受这个值。
并最终对该合理值达成共识。
附录3项目数据管理规程
Ø电子版数据
版本管理的数据：
参照《配置库管理规程》定义的配置库目录结构进行存放和管理。
权限管理的数据：
由相关负责人做好数据的存放及权限控制。
Ø纸质文档
需要按类别列出，并定义出管理的方式及存放的位置。
如果有密级要求，则按公司的相关规定进行管理。
采购类相关的文档，统一由商务人员管理。
其它的由QA保管，项目结项后统一归档。
附录4禅道迭代建立细则
项目立项后，项目经理（或项目负责人）在该项目有实际工作量投入时，开始在禅道中建立迭代，并记录该迭代计划内、计划外的任务，同时开始提交项目周报。
其中：
1.需求开发阶段，按阶段建立“xx项目－需求开发阶段”的迭代，结束日期可按实际情况随时调整；
2.策划与设计阶段，先按预估时间建立“xx项目－策划与设计阶段”的迭代。
等《项目总体进度计划》确定后，再将该迭代的结束日期修改为确定的时间；
3.实现阶段不建立阶段性迭代，应按照迭代计划创建（如xx项目－Sprint1）；
4.UAT、试运行阶段根据《项目总体进度计划》按阶段建立相应的迭代。
附录5迭代中任务贴条细则
²迭代启动会后，团队成员把自己的任务抄写到任务贴条，并张贴到任务板上。
²每天站会时，需要及时更新任务贴条的完成情况。
²任务贴条可以参照如下格式：
ID：
禅道中的ID；
Name：
任务名称或简洁描述；
Resource：
执行人；
Time：
估计剩余时间（单位：
小时）。
第22页共22页
升级会员 