Scrum 项目管理办法

武汉研发中心 项目管理办法

1. 概述

本文主要目的是将对开发模型、研发角色、开发过程及活动、项目度量、辅助工具、绩效考核等研发流程与管理方法进行定义，以制定出适用于武汉研发中心特点的项目管理办法，用来指导开展项目研发、管理等活动。

2. 适用范围

本章程的作用范围为武汉研发中心研发团队及销售人员。

1.对产品经理开展产品规划及设计活动提供了指导；

2.对项目经理遵循的开发流程及项目管理手段进行了指导；

3.对开发、测试员工的日常开发活动及内容进行了指导；

4.对销售人员承诺客户产品交付时间上提供了流程指导；

3. 总体介绍

武汉研发中心将使用敏捷开发模式—Scrum，此套模式在软件行业内已发展十分成熟，它是一种兼顾计划性与灵活性的敏捷开发流程，是一个规则简单的敏捷项目管理框架，整个开发过程由3种角色、5类会议、6个过程产物组成，确保每次迭代后交付的是客户最想要的或商业价值最高的产品特性，同时Scrum规则使团队以敏捷开发的方式去思考，从而提高生产力，减少每天无激情的劳动。

2012年武汉研发中心将学习、推广、实践Scrum，实施过程一定会存在各种各样的阻力，因此实施原则为：先僵化试行，再优化调整，最后固化执行。

4. 术语

术语 解释

Scrum 一种敏捷项目管理与流程

产品负责人 产品负责人或策划者，类似产品经理岗位

Scrum Master 敏捷活动管理者或教练，类似项目经理岗位

User Story 用户故事，从系统各种用户的各自使用场景角度来描述的功能要求，类似需求规格说明

Sprint 冲刺，指某一次迭代开发阶段

产品计划会 产品特性计划会，类似产品范围规划活动

产品特性列表 产品特性列表，产品特性计划会议后的输出

Sprint计划会 Sprint计划会议，类似项目需求澄清、任务分解活动 Sprint任务列表 迭代任务列表，Sprint计划会议后的输出

每日简会 每日简会，类似日工作汇报活动

Sprint评审会 Sprint评审会，类似软件集成活动

Sprint回顾会 Sprint回顾会，类似项目回顾及反思总结活动

任务墙 任务墙，任务跟踪的白板工具

燃尽图 燃尽图，进度跟踪的图表工具

障碍列表 障碍列表，风险记录跟踪的工具

5. 流程介绍

上图引用自《火星人敏捷开发手册》

 开发模型

使用迭代式增量开发模型，此开发模型适用于产品需早期可见、对需求响应快、减低研发风险、需求范围模糊或变化快等特点的项目，与武汉研发中心目前承接的销售解决方案相关产品的研发及发布特点相匹配。

 Scrum项目角色

 产品负责人

决定产品特色、发布时间、内容；对产品的利润收益负责；根据市场价值区分产品的特性并排列优先次序，他有权更改产品特色、优先次序、中途取消Sprint，接受与拒绝Sprint成果；

 Scrum Master

保障敏捷项目流程被遵循；激发、鼓舞、改进团队生产效率；项目各实践活动的组织、监督、培训；与产品负责人及测试人员建立用户可能接受的产品使用标准；

 Scrum Team

1.设计开发人员

自由结对；交叉评审；自由选择User Story开发并对任务质量负责；

2.测试人员

配合产品负责人完成User Story定义并拥有批准是否完成的权限；向产品负责人展示工作成果；部署各阶段测试环境；提交、跟踪产品缺陷并对产品质量负责；

3.美工

根据Scrum Team定义的User Story开发界面原型、静态页面；

 项目过程活动

过程活动 过程产出

产品计划会 产品特性列表

在项目开始的时候开展产品计划会，产品负责人要向Scrum Team讲解产品愿景，并提交一份根据市场价值排序后的产品特性列表，并提出计划以何种方式来实现。Scrum Team需在会议中对所列特性做技术可行性确认、识别风险及障碍，然后对每个特性的发布时间与标准做一次粗略估计，因而形成产品特性列表

过程活动 过程产出

Sprint计划会 Sprint任务列表

在迭代开始前开展Sprint计划会，当产品负责人选择了产品特性列表中的一些高优先级产品特性纳入本次迭代后，这些特性就需要在会上被细化成为User Story，研发团队从产品负责人那尽量获得信息以预估本次迭代的可行性，然后将User Story分解为更细化的设计、原型、编码、测试等任务，并详细估算出工作量，最后在会议中开发人员自由结对并对User Story进行认领与许诺，因而形成Sprint任务列表。

过程活动 过程产出

Sprint 任务墙

有固定不变的Sprint时间（建议4~6周），这样可形成更好的节奏。在Sprint中完成User Story的功能设计、原型开发、编码、代码评审、测试、修改缺陷等等细化后的任务。Sprint中所有任务卡片都贴在任务墙，使每个路过的Scrum Team都可以看到，由各自的任务负责人更新状态。

过程活动 过程产出

每日简会 燃尽图

障碍列表

在Sprint中，团队每天早上开展不超过15分钟的简会（建议站立），会议原则为不讨论问题只汇报状态，议题只有3个：昨天做了什么？今天要做什么？有什么问题或风险？

燃尽图 在每日简会后更新，它显示了Sprint中累积剩余的工作量，是一个反映工作量完成状况的趋势图，Scrum

Master 会根据任务进展情况每天更新累积工作量，直至所有工作量完成，Sprint就成功结束。

障碍列表在每日简会后更新，它显示了本次Sprint中的问题与风险，促使Scrum Master跟踪与控制。

过程活动 过程产出

Sprint评审会 交付可商用的产品版本

当Sprint中的每个任务完成后开展Sprint评审会，将Sprint成果向产品负责人进行展示，获得通过评价，记录缺陷，待返工完成后达到可交付使用的版本。本次Sprint交付后产品负责人可修改产品特性列表的特性与优先顺序，获得下一次的Sprint目标。

过程活动 过程产出

Sprint回顾会 回顾总结报告

会议上可对本次Sprint过程中的人、关系、过程、工具、设计、代码等等维度进行反省总结，选择并拟定改进计划，输出回顾总结报告。并在下一次Sprint回顾会时跟踪上一次会议提出事项的改进结果。

会议的经典议题：我们应该保持做什么事情？我们应该停止做什么？我们应该做什么？

6. 项目辅助工具

目前业界已提供了一些针对敏捷项目管理的辅助系统，敏捷管理系统对项目过程资产有一定的收集与存储功能，对分布式团队的任务管理也提供了支持，但是在实施Scrum的初期，建议使用常规的管理工具即可，避免走入工具影响过程的困境。

 常规的项目管理工具：Excel版的产品特性列表、Sprint任务列表、障碍列表、燃尽图，配合白板、水笔、彩色便签

 持续构建、自动化测试工具：暂不考虑

 缺陷管理工具：JIRA

 支持分布式团队管理的工具：暂不考虑

7. Scrum的度量分析

Scrum强调项目开发与交付的节奏，每次Sprint（迭代）的开发周期是固定的，也就是强制要求了Sprint的结束时间点，在此时间点内未达到交付条件或不具备商用条件的User

Story将被放弃，只能在下一次的Sprint中重新计划与实现。因此在进度问题上只存在已完成或未完成，所以度量项将不包括进度维度。

根据武汉研发中心特点制定了项目级、个人级的度量项，每次迭代项目将由质量管理人员负责采集、发布。

度量项 度量与采集方法 度量分析

Sprint计划工作量

每次Sprint计划任务的工作量之和（人天）

采集：在Sprint计划会议后使用Sprint任务列表汇总 统计历史Sprint工作量偏差情况，为Sprint工作量估算提供参考；

Sprint实际工作量 每次Sprint实际完成任务的工作量之和，需计算变更与加班工作量，单位为人天

采集：在Sprint过程中，每周采集，Sprint评审会后汇总

Sprint有效代码量 每次Sprint的增量代码规模

采集：在Sprint评审会后使用代码统计工具收集 统计历史Sprint生产效率（公式：Sprint代码量/Sprint实际工作量），单位为 行/人天，为Sprint人力资源计划提供参考

Sprint测试用例数 每次Sprint的测试用例数之和

采集：在Sprint评审会后统计 统计历史Sprint每千行代码测试用例数，为测试用例覆盖情况提供参考

Sprint缺陷数 每次Sprint通过测试活动所发现缺陷数量之和

采集：使用缺陷管理工具统计缺陷数 统计历史Sprint缺陷密度（公式：Sprint缺陷数/Sprint有效代码量），单位为个/千行，为Sprint质量情况提供参考

个人工作量 Sprint里个人承担的的工作量

采集：在Sprint计划会自认领的任务工作量，但Sprint评审会前未完成的任务不算入个人工作量 获得个人工作量，为个人绩效的工作量维度提供量化考核数据 个人有效代码量 个人在Sprint中负责的增量代码规模

采集：在Sprint评审会后使用代码统计工具收集 获得个人生产率（公式：个人有效代码量/个人工作量），为个人绩效的效率维度提供量化考核数据

个人缺陷数 Sprint中，通过测试活动所发现的个人缺陷数量

采集：使用缺陷管理工具统计缺陷数 获得个人缺陷密度（公式：个人缺陷数/个人有效代码量），为个人绩效的质量维度提供量化考核数据

8. Scrum团队开发人员绩效考核办法

 考核原则：考核过程要透明公开，考核数据要量化客观，考核范围要有可比性，考核结果及时激励，激励方案相对公平。

 考核频率：每次Sprint都做考核数据采集，在每次Sprint回顾会上公布个人考核得分，使员工及时得到工作评价与差距认知。

 考核范围：考核对象为普通开发人员，按产品团队分别考核，同一个产品团队成员间的工作才具有可比性，考核结果才能相互激励。

 激励频率：综合考虑激励的操作性与及时激励的必要性，建议激励频率为每季度激励一次，将季度中所有Sprint的个人考核得分累计，得到季度绩效排名。

 激励方式：建议设立额外的绩效奖金。绩效奖金的来源可由公司考核产品绩效后打包产品绩效奖金，管理人员根据考核排名来制定个人绩效奖金的额度。绩效奖金额度为相对值，具体根据产品绩效奖金打包额有关，与管理人员的奖励原则与侧重点有关。这样才能使绩效考核的激励措施达到相对公平。

指标 指标得分计算方法（单项满分10分） 权重分配 百分制（满分） 备注

工作量 个人工作量 / (Sprint计划工作量/团队开发成员数)

比值 小于 0.8 2.5分

比值 等于 0.8~1.2 5分

比值 大于 1.3 10分 40% 40 个人工作量与人均计划工作量比值，阶梯得分

效率 (团队开发成员数 - 个人生产率的正序名次 + 1) / 团队成员数 * 10 30% 30 相对排名得分

质量 (团队开发成员数 - 个人缺陷密度排名的正序名次 + 1) /

团队开发成员数 * 10 25% 25 相对排名得分

态度 直接上级主观评价0~10分 5% 5 保证管理人员的影响力

注：

1. 可根据考核方向的偏重，来调整各指标的权重比例，也可根据历史度量数据来修正指标得分的计算方法。