说明：1.修订日期格式统一为：yyyy—mm—dｄ2.修订内容中简要记录每次修订涉及的章节及内容。

目录1. 目的 (3)2. 适用范围 (3)3. 定义、术语及说明 (3)4. 主要角色与职责 (3)5. 入口准则 (4)6. 输入 (4)7. 活动 (5)7.1. 流程图 (5)7.2. 工作流程 (7)7.2.1. 项目策划 (7)7.2.2. 敏捷迭代 (9)7.2.3. 里程碑评审 (11)8. 输出 (12)9. 出口准则 (12)10. 本过程裁剪规定 (12)附录1 项目整体估算细则（功能类比估算法） (13)附录2 迭代任务估算细则 (15)附录3项目数据管理规程 (18)附录4禅道迭代建立细则 (19)附录5迭代中任务贴条细则 (20)1.目的本文档用于指导和规范项目管理工作，涵盖了项目策划、迭代过程管理、项目监控等内容。

2.适用范围本文档适用于普信恒业科技发展（北京）有限公司技术部所有软件项目.3.定义、术语及说明✧迭代：敏捷过程术语.指重复反馈过程的活动,其目的是为了逼近所需的项目目标。

✧QA：Quaｌitｙ Assｕｒance（质量工程师）4.主要角色与职责流程中的主要活动采用RACＩ模型对涉及的角色及其职责进行描述，其中：✧R（Rｅsｐoｎsiｂｌｅ）代表执行:负责执行任务和解决问题的角色。

✧A(Accountabｌe）代表责任：对任务负全责的角色.✧C（Coｎsulteｄ）代表商议：在任务实施前或实施中提供指定性意见的人员。

✧I（Inｆｏｒmeｄ)代表告知：及时被通知结果的人员，不必向其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.制定总体进度计划项目经理根据项目的阶段工作量和该阶段可能投入的人力资源确定阶段里程碑。

需要特别注意以下因素：进度跟该阶段投入人员的知识和技能有关,还可能依赖于外部资源(例如采购）等内容。

制定《项目总体进度计划》，建议使用MＳ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分钟以内。

站会可以邀请相关干系人参加,但是只有团队成员、ＰM和ＰO可以发言。

每位团队成员都要聚焦三个主题：“我昨天（或今天）完成了什么?"、“我今天（或明天)准备完成什么？”、“有什么障碍影响我的进展？”。

站会上不应讨论与三个主题无关的事情（如技术解决方案等）。

对于简短的问题，可以在站会上讨论并解决。

若问题过于复杂，不能在３分钟内解决的，项目经理应单独安排会议时间解决该问题。

问题及解决情况应及时记录到《问题事项一览表》中. 7.2.2.4.整理周报每周的最后一个工作日,项目经理应整理《项目周报》.周报中汇报本周项目进展情况及下周工作计划，反映当前重大问题及重大风险。

在周报中对迭代目标达成率和迭代计划有效性进行度量,并预测近期里程碑的实现日期。

7.2.2.5.迭代回顾会一个迭代即将结束时,项目经理应提前制定本迭代的汇报提纲,并发出迭代回顾会的会议通知。

迭代回顾会由两部分组织：一是迭代演示会，由项目团队向产品经理及其他项目干系人展示本迭代开发的产品功能。

二是迭代回顾会，分为两个步骤：①团队检视,每位团队成员针对项目提出改进点，由全体成员共同讨论项目中存在的最主要问题，并制定项目改进计划。

②个人检视,每位成员先写下自己的一条改进点,然后再写出其他每位成员的一个亮点，每位团队成员将自己所写内容展示给大家，并确定出个人改进计划。

对于改进点和亮点，可以参考个人考核指标中的要求来阐述。

对于会议上提出的事项和待采取的行动应在会议纪要中体现,并通知给相关人。

7.2.3.里程碑评审依据项目计划，当项目达到里程碑时，项目经理应整理《项目里程碑报告》，并发起里程碑评审。

里程碑评审会议可以和迭代回顾会一起进行.会议应该邀请业务部门－系统接口人、高层经理参与。

会上总结本阶段的情况，分析偏差，并演示阶段成果。

如果无法召开里程碑评审会，可以通过邮件将里程碑报告汇报给业务部门－系统接口人、高层经理。

8.输出9.出口准则项目结项。

10.本过程裁剪规定本过程描述的所有活动均不允许裁剪.附录1 项目整体估算细则（功能类比估算法）1.确定基准功能首先，从《产品需求规格说明书》（或历史项目)中找出最具代表性的典型功能，以这个功能的指标（综合考虑规模和难度、项目管理、系统测试等因素）作为基准，规定此功能的基准系数为１。

同时估算出此基准功能的单元工作量.注：单元工作量包含详细设计、编码、代码走查、单元测试、系统测试及项目管理的工作量。

2.估算整体基准系数依次将《产品需求规格说明书》中各个功能的综合指标与基准进行比较，得出对应功能的基准系数。

如果组织过程资产中存在同类项目的历史数据时,优先使用组织级历史数据进行估算。

例如：基准功能系数为1,另一个功能的规模是基准的2倍,难度系统是基准的1。

5倍，则:该功能的基准系数=规模系数×难度系数=2×1。

５=3。

3.估算总体工作量各功能的基准系数估算完成后,用所有功能的系数之和乘以基准功能的单元工作量,即可得到当前需求对应的实现阶段工作量.当前需求实现阶段总工作量=当前需求所有功能的基准系数之和×基准功能的单元工作量策划与设计阶段工作量＝当前需求实现阶段工作量×策划与设计阶段所占比率系数另外，项目经理还需根据项目风险情况及以往经验确定一个预留缓冲比率。

完整需求实现阶段总工作量=当前需求实现阶段工作量×（1+预留缓冲比率）4.估算进度根据工作量估算结果,结合项目可投入的资源，即可得到工作持续时间与迭代个数。

策划与设计阶段持续时间＝策划与设计阶段总工作量/参与人员数实现阶段进度(以迭代个数表示）一个迭代的有效工作量=迭代周期×人员有效投入量迭代个数＝完整需求总工作量/一个迭代的有效工作量开发完成后,即进入UＡT和试运行阶段,但此阶段的特点是按固定周期而不是按工作量.所需时间由项目经理和产品经理商议确定,同时确定本阶段的人员投入量。

如果项目人员存在复用情况，则按实际投入的百分比计算。

项目总工期＝策划与设计阶段持续时间＋迭代个数×迭代周数×5+UＡT持续时间+试运行持续时间示例:参见《项目总体估算记录表》.附录2 迭代任务估算细则敏捷开发时，最佳的估算是由包括将要做此工作的人在内的小组合作得到的.首先，我们并不确定一项工作将由特定的哪个人来完成。

由于任何工作都可能被任何人完成，因此让每个人都参与估算是非常重要的。

其次，当一个人对工作做出估算时，其他人对他的估算值可能也有意见需要表达。

面对其他的人意见，当事人需要给出解释，以证明这个估算值的合理性。

推荐估算方法：（项目组可自行决定使用何种方式）1、估算的尺度：最佳实践提供了一个很有效的估算尺度序列：１、２、３、5、8。

这些数字可以被看成是一些桶,同样大小的东西将被倒入相应的桶中。

工作应该被看成是倒入这些桶的沙子.选择与所估工作量最贴近的一个数字.虽然0也可以做为一个估算值,但如果估算为0的话，很可能这个工作是不需要做的，而相应的任务也不需要分配.实际情况往往是比0大一些,比1小一些,因为这里的0×1０≠0。