Scrum敏捷项目管理

Scrum基本原理：

1. Scrum是经验型方法，是”可能性的艺术“ 2. Scrum使得所有事项充分可见，使“秘密交易”最小化 3. Scrum的运作基础是个人和团队的承诺，而非严密的规划及控制。相对于强行控制计划，其忠诚度、自组织和员工责任感是更为有效的机制 4. 团队成员只有事先集体负责，承诺在固定时间内交付实际产品后，才算真正掌握Scrum

ScrumMaster

ScrumManager主要职责:

1. ScrumMaster与传统项目经理区别：从传统的控制者到引导者的转变 2. ScrumMaster需要对团队作出承诺，让团队感受到有人全心全意关注其工作，在任何情况下提供保护和援助。 3. ScrumMaster使团队在Sprint过程中免受干预 4. 产品负责人谈论业务需求和目标，团队则讲技术。由于产品负责人很难掌握技术，ScrumMaster的主要职责之一就是教会团队谈论商业需求和目标。团队与产品负责人之间的公分母是产品Backlog

ScrumMaster职责：

1. 排除产品开发和负责人之间的障碍，确保产品负责人直接推动开发工作 2. 教授产品负责人如何实现投资回报最大化，以及如何利用Scrum达成目标 3. 激发创造力和放权，从而改善开发团队的环境 4. 千方百计提高开发团队的生产力 5. 改善工程实践和工具，确保每个功能增量都具备潜在可交付性 6. 向各方确保团队工作进展实时更新并高度可视

Scrum高效率探究

限期30天Sprint的固有压力，团队成员表示“需有所付出”的相互承诺，自组织原则及跨职能责任，有助于团队成功履行职责承诺机制条理化，增加相互责任心，团队凝聚效应

“限定时间”可向团队灌输“可能”的艺术，避免过分追求完美 “增量交货”的举措改进工程实践 “放权”和“自组织”能够激发创造力，提升员工满意度

(*****) 当人们不能聚在一起面对面交流时，往往会将自己的问题抛给他人 (****) 预估的目的是为了解每个需求自身及相对于其他需求的规模。该信息有助于划分产品Backlog的优先等级，并将之分入各个Sprint

Scrum运行无需过于宽泛的计划，但需足以引导Scrum的经验性过程的检查与适应循环，若成本/收益及假设性数据引导适应环境更有意义地展开，项目必可收益

团队

团队从被管理到自我管理的转变十分困难，但在生产力和工作愉悦度方面的回报显著

在我们的生活和工作经历中，受他人管理的习惯根深蒂固。

Scrum真理：成功的开发需要不断检查和调整

本质：内心深处，认为自己应在一开始便完美安排各事项，确保计划得以严格实施。需要适应调整时，责备自己为实现妥善安排全部事项。从开始就预知结果的人不会存在。

(**) 总体度量，即在最合适的日期交付最佳、最优质的系统。实施其余度量法时应保持谨慎，确保其支持总量度量，避免削弱其效果。我们在设计度量系统时应考虑人类固有的、为取悦他人不计后果的欲望。（e.g. 代码量不应作为绩效考核标准） (***) 团队通常难以用产品负责人能理解的语言与之交流，若产品负责人只谈商业，团队只谈技术，双方无法交流，也就没有协作

Scrum报告

每个Sprint结束时还需产生正式报告

Scrum报告：

1. 第一份列出上一次Sprint开始时的产品Backlog 2. 第二份为新Sprint开始时的产品Backlog 3. 第三份是“变更报告”，详细列出前两份报告的差别 4. 第四份为产品Backlog的“剩余时间报告”（Burndown Report）

变更报告总结以下内容：

1. Sprint中发生及Sprint审核的情况 2. 项目针对Sprint审核结果所做的适应调整 3. 未来Sprint重构的原因 4. 发布日期或内容重新制定的原因 5. 为何团队在Sprint中完成的需求量比预期少 6. 在产品Backlog中，未完成工作的优先等级重排情况如何 7. 团队为何比预期生产率高（低）

不使用术语，却教会管理层使用Scrum，属于只是一种表现形式。

Scrum扩展项目

Scrum of Scrums

Scrum实践扩展成功的关键：

1. 在扩展前构建必须的基础设施（构建扩展基础设施的非功能性需求必须在扩展开始前完成） 2. 建构基础设施的同时确保交付商业价值 3. 优化原始团队的能力，向其余团队分派至少一名初始团队成员

项目扩展为多个团队的产品Backlog中应加入以下非功能性需求：

1. 分解业务结构以支持整洁界面的多团队开发 2. 分解系统结构以支持整洁界面的多团队开发 3. 必要时，定义并实施特定开发环境，支持多团队并置或分布的环境

敏捷 Scrum 实施的10个流程步骤

1、确定产品负责人（Product Owner）；

2、组建敏捷小组（Scrum Team）；

3、确定敏捷教练（Scrum Master）；

4、拟定产品需求（Product backlog）；

5、评估产品需求；

6、冲刺规划会；

7、工作透明化；

8、每日站会；

9、冲刺评估；

10、冲刺回顾；

1、确定产品负责人（Product Owner）

产品负责人必须知道自己带领的团队需要做什么产品以及取得什么成果。一个项目团队中可以有多个产品经理，每个负责产品中一个模块的功能，但产品负责人只能有一个，作为所有产品经理的代表，决定产品的发展方向。

2、组建敏捷小组（Scrum Team）

一个项目团队可以有多个敏捷小组，负责产品中一个功能模块的开发，比如这个组开发前端界面，这个组开发支付功能，再有一个组开发社交功能。同时，一个小组的人数最好控制在3-9个人，超过9人的话人数越多沟通路径越多，不利于团队间的沟通，降低工作效率。

3、确定敏捷教练（Scrum Master）

敏捷教练的作用是对成员进行敏捷培训，做好工作进度的管控，优化项目流程，解决成员遇到的阻碍，最终目的是提高整个敏捷小组的工作效率，保证顺利交付

如果团队只有一个敏捷小组，那么由项目经理作为敏捷教练；如果有多个小组则有多个Scrum Master ，简称SM，项目经理对每个敏捷小组和SM统筹管理。

比如，一个软件研发团队中可能有三个敏捷小组，分别是前端开发、后端开发、测试，小组中高级工程师或者技术专家作为SM，而项目经理需要对SM进行敏捷培训，SM再给小组成员做培训，形成整个敏捷团队

4、拟定产品需求（Product backlog）

这一项主要由产品负责人负责，首先，他权衡各个需求后排列出需求的优先顺序；其次，负责向团队清楚地表达产品待办列表；第三点，确保产品待办列表是可见的、透明的，所有人都清楚下一步该做什么工作；最后，在创建产品待办列表的同时，还需要包括测试描述，这些测试描述将在“完成”时验证产品的完整性。

同时PO也会听取团队对列表的建议，适当的进行调整，例如在描述需求后如果开发团队表示工作太多或太少，可以与PO重新协商，开发团队也可以邀请技术专家参加。产品待办列表代表的是各方的业务需求，当发生变更时，或利益相关者如果想要改变产品待办列表的优先级，必须向PO提出请求。

产品待办列表的内容和顺序中是透明可见的，没有人可以强迫开发团队做列表范围以外的需求工作。

5、评估产品需求

团队会通过需求评审会来对产品负责人提的需求进行评审，产品负责人和团队中的技术专家一起参与，评估每一个需求需要什么技术、多少人、时间来完成，对于不合理的需求提出改进意见或者直接驳回，会探讨以下问题:

1）该需求是否细分到了可以评估的程度？

2）需求文件的信息足够么，是否描述清楚？

3）这个需求是否有价值？等等

最终目的是保证每个需求切实可行。另外，Scrum用点数代替人天和人时评估需求的工作量，对应的数字采用斐波那契数列（1，2，3，5，8，13，21……），这个数列的规律是前两个数的和是下个数的值，从而更好地比较需求之间的差异，再通过对比来评估出较为准确的工作量。

6、冲刺规划会

每个迭代周期就是一个Sprint，也就是冲刺。冲刺周期都是固定的，一般是1-3周。在冲刺规划会上，团队成员、敏捷教练和产品负责人坐在一起，规划冲刺的内容。

7、工作透明化

Scrum提倡工作透明化，团队外的人员可以参加内部会议，每个成员的工作都是公开透明，最常见的做法是准备一块白板，上面分成三栏：待办事项、在办事项、完成事项。把待办事项写到便笺纸上，随着进度的推进，将相应的便笺纸转移到其他栏目。也可以用PingCode、Jira等不错的项目管理软件来记录事项，起到跟白板一样的效果。

8、每日站会

会议要求全员参加，时间地点固定，时长一般不超过15分钟，且站立进行，每个团队成员只回答以下问题：

1）你昨天做了什么去帮助团队完成冲刺？

2）今天你打算做什么来帮助团队完成冲刺？

3）什么因素阻碍了团队效率？

成员只反馈进度、规划、问题，提高会议的效率，不占用大家的过多时间，具体的事项会后讨论。通过反馈，敏捷教练把控好项目进度，帮成员解决阻碍。

9、冲刺评估

在冲刺结束前，团队成员给产品负责人展示项目成果，接受评价。这是一场公开的会议，任何人都可以是参与者，不仅仅包括产品负责人、敏捷教练和开发团队，还包括利益相关者、管理人员与客户。

10、冲刺回顾

通过举行回顾会议来盘点本次冲刺中所存在的问题、遇到的阻碍、做得好与不好的地方、提出建议和整改方法，对流程规范进行优化，提高下次冲刺的工作效率。

二、Scrum实施过程中常用的5大Scrum管理工具/软件

敏捷开发中非常强调公开、透明、直接有效的沟通，这也是“可视化的管理工具”在敏捷开发中如此重要的原因之一。

通过“可视化的管理工具”让所有人直观的看到所有需求池、UserStory、Task、燃尽图和Bug的状态及之间的流动。为使团队成员快速适应敏捷开发流程，将流程标准固化到可视化的管理工具。

这里分享国内外的5款顶级敏捷开发管理工具。

1、国内顶级 Scrum 管理工具PingCode

这是国内最好用的敏捷开发Scrum工具之一，曾在2021年获得由36氪发布的研发项目管理榜TOP1，被广泛用于敏捷开发项目管理。在Scrum 项目管理方面具备如下能力：

• 需求管理：史诗/特性/用户故事三级体系，根据优先级、故事点形成待办列表
• 产品规划：根据产品目标及项目需求排期，有序规划产品路线图、迭代和版本
• 迭代管理：将需求和Bug分配到迭代，通过燃尽图、速率图等跟踪迭代进度
• 版本管理：支持多版本共存，新增功能和修复对应版本，让发布更有计划
• 开发管理：拆分用户故事为任务，开发人员领取任务完成Coding
• 构建部署：工作项关联代码托管、CI/CD工具，跟踪开发、构建及部署进度
• 工时统计：估算、填报任务工时，可视化度量项目和团队工作量

除此以外，PingCode 还是一站式研发管理工具，包含需求收集、需求池管理、优先级排序、产品路线图、kanban/瀑布/敏捷项目管理、测试用例管理、缺陷管理、团队知识库、效能度量，与gitlab、jinkens、飞书等外部工具集成。

针对国内用户25人以下免费，支持saas、私有部署等购买方式，价格仅为Jira的30%-40%。【官网：https://datayi.cn/w/YoXY34K9 】

2、国外顶级Scrum管理工具Jira

Jira是全球范围内软件开发的先驱。该品牌于2002年由Atlassian公司在澳大利亚创立，最初是一个问题跟踪工具，此后逐渐发展为多任务的项目管理软件，能够很好的支持敏捷开发项目管理。

Jira 同样是国外能够实施Scrum方法的知名软件，Jira提供了丰富的功能，其中包括：可用于backlog的自定义过滤器、项目报告的可视化表示、以及可定制的Scrum板。

当然，如果您不太熟悉Scrum的话，可能需要花上一定的时间来测试，熟悉和掌握该软件的各项功能，因为Jira 上手会比较难，这也是很多人诟病的点。

除此以外，自从2020年停售国内本地版后（一定意义上对国内用户禁售），所以这可能会带来一定的风险，但也丝毫不影响其地位。

不得不说，Jira 在国外使用的体验比在国内使用要好很多，因为售后服务国内是没有原厂的，所以如果有国外团队，Jira是个不错的选择。【官网：Atlassian.com】

3、G2网站第二的项目管理软件monday

Monday 是国外的一款产品，在项目与团队管理方面，Monday提供了自定义通知、以及自动化的功能，可方便用户更加专注于需要完成的各项任务。

通过其出色的跟踪功能，我们可以跟踪与项目相关的所有任务与进度。Monday能够创建并可视化还各项任务，以方便团队的共享和稳步推进。同时，它还能够轻松地创建backlogging，以方便用户对手头的任务进行排序。

Monday的一项缺点是：用户无法通过创建专门的燃尽图，来跟踪sprint的进度。不过，它能够提供简单的图表和报告，以方便用户粗略地了解整个sprint的状况。以及国内的服务支持服务可能不如国外。【官网：monday.com】

4、软件项目管理ActiveCollab

ActiveCollab是国外的一个项目管理软件，它支持规划，组织，沟通和合作Scrum项目的项目管理工具。Scrum Master可以将工作分解为可操作的任务，并进行适当的人员分配。

ActiveCollab提供免费版。付费版起价为每个月9美元，最多可支持三个用户。【官网：ActiveCollab.com】

5、专业的Scrum工具easyBacklog

easyBacklog是受Scrum团队青睐的免费迭代待办事项（Sprint backlog）管理工具。这个Scrum工具可以帮您轻松创建并且比较不同版本的迭代待办事项，还支持不同任务的成本估算和预算分配。

但是，这个软件没有专用的移动应用程序，这就导致您无法随时随地办公。easyBacklog的主要功能：用户故事支持按主题分组、拖放优先级、燃起图与燃尽图、多种颜色分类等；【官网：easyBacklog.com】

敏捷转型虽然很难，但值得，许多软件开发公司都在极力的向着敏捷转型。