项目管理过程定义.docx

名称：项目管理过程定义 效力状态：正式 制度编号：技术部-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-dd2. 修订内容中简要记录每次修订涉及的章节及内容。目录1.目的42.适用范围43.定义、术语及说明44.主要角色与职责45.入口准则56.输入57.活动67.1.流程图67.2.工作流程87.2.1.项目策划87.2.2.敏捷迭代107.2.3.里程碑评审138.输出139.出口准则1310.本过程裁剪规定14附录1 项目整体估算细则（功能类比估算法）15附录2 迭代任务估算细则17附录3项目数据管理规程20附录4禅道迭代建立细则21附录5迭代中任务贴条细则221. 目的本文档用于指导和规范项目管理工作，涵盖了项目策划、迭代过程管理、项目监控等内容。2. 适用范围本文档适用于普信恒业科技发展（北京）有限公司技术部所有软件项目。3. 定义、术语及说明 迭代：敏捷过程术语。指重复反馈过程的活动，其目的是为了逼近所需的项目目标。 QA：Quality Assurance（质量工程师）4. 主要角色与职责流程中的主要活动采用RACI模型对涉及的角色及其职责进行描述，其中： R（Responsible）代表执行：负责执行任务和解决问题的角色。 A（Accountable）代表责任：对任务负全责的角色。 C（Consulted）代表商议：在任务实施前或实施中提供指定性意见的人员。 I（Informed）代表告知：及时被通知结果的人员，不必向其咨询、征求意见。TaskRoles产品经理项目经理项目团队QA高层经理 建立团队IA/R/IC过程裁剪IA/RICI确定工作范围ARIIC项目估算IA/RRIC制定项目主计划CA/RRCC整合项目计划CA/RRRC项目计划评审RRRRA确定迭代目标及范围A/RCIII迭代启动会RA/RRCI每日工作及站会CA/RRC/整理周报IA/RRII迭代回顾会RA/RRRI里程碑评审CRRCA5. 入口准则 产品需求规格说明书通过评审。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. 制定总体进度计划项目经理根据项目的阶段工作量和该阶段可能投入的人力资源确定阶段里程碑。需要特别注意以下因素：进度跟该阶段投入人员的知识和技能有关，还可能依赖于外部资源（例如采购）等内容。制定项目总体进度计划，建议使用MS Project。制定过程中，先制定项目进度计划表（含迭代计划），然后在其中的关键时点处标记出里程碑，并将各里程碑录入到项目周报中。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倍，则：该功能的基准系数=规模系数难度系数=21.5=3。3. 估算总体工作量各功能的基准系数估算完成后，用所有功能的系数之和乘以基准功能的单元工作量，即可得到当前需求对应的实现阶段工作量。当前需求实现阶段总工作量=当前需求所有功能的基准系数之和基准功能的单元工作量策划与设计阶段工作量=当前需求实现阶段工作量策划与设计阶段所占比率系数另外，项目经理还需根据项目风险情况及以往经验确定一个预留缓冲比率。完整需求实现阶段总工作量=当前需求实现阶段工作量（1+预留缓冲比率）4. 估算进度根据工作量估算结果，结合项目可投入的资源，即可得到工作持续时间与迭代个数。策划与设计阶段持续时间=策划与设计阶段总工作量/参与人员数实现阶段进度（以迭代个数表示）一个迭代的有效工作量=迭代周期人员有效投入量迭代个数=完整需求总工作量/一个迭代的有效工作量开发完成后，即进入UAT和试运行阶段，但此阶段的特点是按固定周期而不是按工作量。所需时间由项目经理和产品经理商议确定，同时确定本阶段的人员投入量。如果项目人员存在复用情况，则按实际投入的百分比计算。项目总工期=策划与设计阶段持续时间+迭代个数迭代周数5+UAT持续时间+试运行持续时间示例：参见项目总体估算记录表。附录2 迭代任务估算细则敏捷开发时，最佳的估算是由包括将要做此工作的人在内的小组合作得到的。首先，我们并不确定一项工作将由特定的哪个人来完成。由于任何工作都可能被任何人完成，因此让每个人都参与估算是非常重要的。其次，当一个人对工作做出估算时，其他人对他的估算值可能也有意见需要表达。面对其他的人意见，当事人需要给出解释，以证明这个估算值的合理性。推荐估算方法：（项目组可自行决定使用何种方式）1、估算的尺度：最佳实践提供了一个很有效的估算尺度序列：1、2、3、5、8。这些数字可以被看成是一些桶，同样大小的东西将被倒入相应的桶中。工作应该被看成是倒入这些桶的沙子。选择与所估工作量最贴近的一个数字。虽然0也可以做为一个估算值，但如果估算为0的话，很可能这个工作是不需要做的，而相应的任务也不需要分配。实际情况往往是比0大一些，比1小一些，因为这里的0100。如果有的用户故事规模过于庞大，需要我们使用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回答完问题后，每个估算者私下选择一张代表他的估算值的卡片。等大家都准备好之后，一起亮出来，让所有参与者都互相看到彼此做出的估算。如果估算值不同，就让估算值最高和最低的人分别说明他们的理由。大家可以花几分钟来讨论这个用户故事和对它的估算。讨论之后，每个估算者重新选择一张卡片进行估算。很多时候，估算值在第二轮的时候就会汇聚起来。如果没有的话，就继续重复这个过程。这个做法的目标是让所有的估算值都汇聚到一个估