21.Scrum敏捷框架

一、Scrum的起源与背景

1、敏捷宣言

敏捷开发方法的起源可以追溯到2001年，当时一群软件开发专家在犹他州的雪鸟度假村聚集，发布了著名的《敏捷宣言》。这份宣言强调了四个核心价值观和十二条原则，旨在提高软件开发的灵活性和响应能力。敏捷宣言的核心价值观包括：个体与互动高于流程与工具、可工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划。

敏捷项目管理有两种最为主流的理论框架：Scrum 和 Kanban。其它敏捷方法还有精益软件开发、极限编程（XP）、动态系统开发方法（DSDM）、功能驱动开发（FDD）、Crystal(水晶方法)、TDD(测试驱动开发)、DSDM(动态系统开发)。

2、Scrum框架的诞生

Scrum框架作为敏捷方法的一种，由Jeff Sutherland和Ken Schwaber在20世纪90年代初提出。这个名字源自橄榄球中的“scrum”（争球），象征着团队紧密合作、共同推进项目的理念。Scrum通过规定角色、事件和工件，提供了一个结构化的工作流程，帮助团队在不确定性中有效地工作。

两位大神在上个世纪90年代早期开发了Scrum，并在2010年发布了第一版的《The Scrum Guide》。两人同时也是2001年发表的《敏捷宣言》的合著者，经历都很传奇。Jeff是生物统计学博士、飞行侦察员、西点军校毕业、还参加了越战，Ken有着长达40年的开发生涯。

一、Scrum是什么

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

Scrum是一个轻量级的敏捷框架，通过自适应的方案来帮助人们解决复杂问题，创造价值。

Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一。《Scrum-Guide》里还说明了：Scrum 框架故意不完整，仅仅定义了实施 Scrum 理论所需的部分。

它是一种灵活、适应性强的项目管理方法，Scrum的核心目标是让团队能够迅速响应变化、持续改进、及时交付高质量的产品，并保持高度的透明度和协作性。

Scrum 基于经验主义和精益思维。 经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本。

Scrum框架由三个角色、五个活动和三个工件组成：

1. Scrum角色：

• 产品负责人（Product Owner）：负责定义产品的需求和优先级，并确保团队始终关注最重要的任务。

• Scrum Master：负责确保Scrum框架得以正确实施，帮助团队解决障碍，提升工作效率。

• 开发团队（Development Team）：由多功能成员组成，负责具体的产品开发和增量交付。

2. Scrum活动：

• Sprint规划会议（Sprint Planning）：定义Sprint的目标和任务。

• 每日站会（Daily Scrum）：团队成员每天简短汇报工作进展、问题和计划。

• Sprint评审会议（Sprint Review）：展示Sprint成果并收集反馈。

• Sprint回顾会议（Sprint Retrospective）：团队反思Sprint过程，提出改进措施。

• Sprint（冲刺）：开发工作周期，通常为2到4周。

3. Scrum工件：

• 产品待办列表（Product Backlog）：按优先级排列的所有需求和功能。

• Sprint待办列表（Sprint Backlog）：Sprint中计划完成的任务。

• 增量（Increment）：完成的可交付的工作产品。

Scrum是一个帮助团队协同工作的框架。就像橄榄球队（它的名字的由来）为大型比赛进行培训一样，Scrum 鼓励团队从经验中学习，以自组织的方式去处理问题，并对他们的胜利和失败反思以不断改进。

虽然我们说Scrum 最常被软件开发团队使用，但它的原则和经验教训可用于各种团队合作，这也是 Scrum 如此受欢迎的原因之一。

三、Scrum的江湖地位

Scrum仍然是运用最广泛的敏捷方法（框架），Scrum和Scrum结合其它方法混合使用占比超过75%。

2020敏捷年度报告14th Annual State of Agile Report：；https://stateofagile.com/

四、Scrum怎么做

scrum敏捷框架.rp

1、Scrum3个角色

Scrum 团队需要三个特定角色：产品负责人(Product Ower)、ScrumMaster和Scrum 团队。由于 Scrum 团队为跨职能部门，因此除开发人员之外，开发团队还包括测试人员、设计人员、用户体验 (UX) 专家和运营工程师。

产品负责人(Product Ower)

产品负责人是Scrum团队中的关键角色，负责定义产品愿景、管理产品待办事项列表（Product Backlog），并确保团队的工作始终与客户需求和业务目标一致。Product Owner 负责将 Scrum Team 的工作所产生的产品价值最大化。 产品负责人需要与客户、利益相关者和开发团队密切合作，优先处理待办事项，平衡需求与资源限制。

1个团队 1个PO，善沟通、懂业务、敢拍板（say no 真的需要勇气）、有授权

主要负责构建正确的产品，确定 Scrum 团队交付什么并解释为什么做这些工作。产品负责人是产品方面的佼佼者。他们专注于了解业务、客户和市场要求，然后相应地确定工程团队需要完成的工作的优先顺序。高效的产品负责人应能：

• ● 开发并明确地沟通 Product Goal ；
  ● 创建并清晰地沟通 Product Backlog 条目（items）；
  ● 对 Product Backlog 条目进行排序； 
  ● 确保 Product Backlog 是透明的、可见的和可理解的。

产品负责人并不一定是产品经理。产品负责人专注于确保开发团队为企业带来最大价值。此外，产品负责人是一个个体，这一点非常重要。没有开发团队需要多个产品负责人所提供的的混合指导。

Scrum Master

Scrum Master是团队的服务型领导，负责确保Scrum流程的正确实施，帮助团队克服障碍，提高效率。Scrum Master的职责包括主持每日站会、Sprint规划会议和回顾会议，提供培训和指导，并推动团队不断改进。

主要负责帮助产品负责人和开发团队中的每个人理解和拥抱Scrum的价值观、原则和实践。Scrum master 是其团队中在 Scrum 方面的佼佼者。

他们负责对团队、产品负责人和企业进行 Scrum 流程方面的培训，并寻找方法细调他们在此方面的实践。高效的Scrum 主管应深入了解团队正在执行的工作，并可协助团队优化其透明度和交付流程。作为最主要的推动者，此角色负责安排冲刺规划、每日短会、冲刺审核和冲刺回顾所需的资源（人力和物力）。

• 敏捷价值观和规则的守护者，通过激发潜能和减少干扰，持续提高团队绩效
• P（performance）=P（potential）-I（interference））

Scrum 团队

5~9人跨职能、自组织、小团队

团队由一组跨职能的专业人员组成，负责在每个Sprint内交付可工作的产品增量。团队成员通常包括开发人员、测试人员、设计师等，他们共同承担责任，协作完成任务。开发团队需要具备自组织能力，能够在没有外部干预的情况下决定如何完成工作。

负责以正确的方式构建产品，执行具体工作任务。Scrum团队是具体工作的执行者，成员通常为 5 到 7 名。确定团队规模的一种方法是亚马逊首席执行官 Jeff Bezos提出的著名“两个披萨原则”（团队应该足够小，以便分享两个披萨）。团队成员具有不同的技能，并且彼此互相锤炼，因此没有人会成为交付工作的瓶颈。

强大的Scrum 团队遵循自我组织原则，且会在处理项目时采取明确的“我方”立场。团队的所有成员会互相帮助，以确保成功完成冲刺。

Scrum团队可推进每个冲刺的计划。他们将自己的历史速度用作指导，预测他们认为自己在迭代过程中可以完成的工作量。保持迭代长度固定，使其能随时间推移做出更加准确的预测。

自主团队的成员必须能够自我管理，以完成他们的目标，而由开发人员进行排序的工作计划（Developer-Ordered Work Plan，Scrum Pattern之一，将在单独的文章中介绍）指出，开发团队必须能够自由地以他们认为合适的方式安排他们生产阶段的工作。Sprint目标是产品负责人用于影响开发团队潜在工作顺序的唯一机制（通过Sprint目标所传达的重要性来推断紧迫性）-- 当然，只有在得到开发人员同意后才可以。

Developers 所需的特定技能通常很广泛，并且会随着工作领域的不同而变化。 但是， Developers始终要负责：
● 为 Sprint 创建计划， 即 Sprint Backlog；
● 通过遵循 Definition of Done 来注入质量；
● 每天根据 Sprint Goal 调整计划； 
● 作为专业人士对彼此负责。

2、Scrum 3个工件

工件是我们完成的事情，就像是解决问题的工具。在 Scrum 中，这三个工件分别是产品待办事项、冲刺（Sprint）待办事项，以及对“已完成”定义的增量变化。

它们是 Scrum团队中的三个常量，我们会不断地对其进行重新审视，并投入额外的时间进行改进。

产品待办事项（Product Backlog）（PBI）

产品待办事项集合，整个产品的用户故事集合，这些用户故事可以来自甲方客户、终端用户、PO自己对产品的理解、研发团队等。分为功能性和非功能性需求，包含所有需要开发的功能、缺陷修复和技术重构。产品负责人负责管理和更新产品待办事项列表，确保其反映最新的业务需求和客户反馈。产品待办事项列表是Scrum团队工作的基础，为团队提供了清晰的工作方向。

　　承诺：产品目标：Product Goal

Product Goal 描述了产品的未来状态，可以作为Scrum Team 制定计划的目标。Product Goal 在Product Backlog 中。Product Backlog 的其余部分涌现，用来定义“做什么”将实现 Product Goal。

产品是传递价值的载体，它具有明确的边界、已知的利益攸关者和定义明确的用户或客户。产品可以是一种服务、实体产品或其他更抽象的东西。Product Goal 是 Scrum Team 的长期目标。他们必须先实现（或放弃）一个目标，然后再开始下一个目标。

一个初始化Product Backlog的好方法是就是将其表达为包含许多Sprint Goal的列表，由产品负责人和开发团队一起随着时间的推移将其渐渐细化为PBIs。

冲刺待办事项（Sprint Backlog）（SBI）

每次冲刺之前，在冲刺规划会议（我们将在后文进行讨论）中，团队从产品待办事项中选择为进行冲刺而处理的项目。冲刺待办事项可能较为灵活，可以在冲刺期间发展。但是，基本的冲刺目标（团队希望通过在当前冲刺中实现的目标）不能受到影响。

Sprint待办事项列表是从产品待办事项列表中选出的、计划在当前Sprint内完成的工作项。开发团队在Sprint规划会议上确定Sprint待办事项列表，并在Sprint期间逐步完成。Sprint待办事项列表帮助团队集中精力，确保在规定的时间内交付可工作的产品增量。

PO根据交付价值，将优先级最高的用户故事放入迭代。

任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。

　　承诺：冲刺：Sprint Goal

Sprint Goal 是 Sprint 的单个目标。尽管 Sprint Goal 是 Developers 的承诺，但它为实现该目标所需的确切工作方面提供了灵活性。Sprint Goal 还创造了连贯性和专注点，鼓励 Scrum Team 一起工作而不是分开独自行动。

Sprint Goal 在 Sprint Planning 事件中确定，然后添加到 Sprint Backlog 中。当Developers 在 Sprint 期间工作时，他们将 Sprint Goal 铭记在心。如果需要做的工作与预期的不同，他们将与Product Owner 协作，在不影响 Sprint Goal 的情况下，协商本次Sprint Backlog 的范围。

Sprint Goal 在PBI之间建立连贯性（译者注：而不是一堆散落的PBI），这有助于创造有价值的产品增量。

开发团队对Sprint目标做出承诺。这个Sprint目标可以帮助开发团队众志成城，并有助于建立利益相关者对团队的信任。

产品增量（Product Increment）

• PI必须符合验收成果
• PI必须处于可发布状态

　　完成定义： Definition of Done
Definition of Done 是当 Increment 符合产品所需的质量度量标准时对其状态的正式描述。 当一个 Product Backlog 条目符合 Definition of Done 时，就会产生一个 Increment。

如果一个 Product Backlog 条目不符合 Definition of Done ，那么它就 不能发布，甚至不能在 Sprint Review 中展示它。相反， 它返回到 Product Backlog 中以供将来考虑。

增量是每个Sprint结束时交付的可工作的产品部分，必须达到“完成的定义”（Definition of Done）标准，也称作最小的可用软件 MVP（Minimum Viable Product）。增量应具有可用性和价值，能够为客户或利益相关者提供可见的进展。增量的交付是Scrum的核心目标，通过不断交付小的、可工作的部分，团队能够更快地获得反馈并进行调整。

在完成以上三个工件的时候，团队可以选择定义很多变体，因为工件维护最好保持开放态度。比如“已完成”、“故事点”重新定义能更好的提升效率和品质，那你完全可以根据需求进行新的定义。

3、Scrum 5个活动仪式

Scrum 框架中一些更为人所知的组件包括 Scrum团队定期举行的一系列会议。在这些仪式中，我们可以看到团队之间的最大差异。

例如，有些团队发现举行所有这些仪式既繁琐又重复，而另一些团队则将这些仪式作为必要的登记手段。我们的建议是，在两次冲刺阶段使用所有仪式，然后看看其效果。接着，你可以进行快速回顾，看看可能需要进行哪些调整。

以下是Scrum 团队可能参加的所有重要仪式清单：

需求梳理会(Backlog Grooming Meeting)

有时也被称为待办事项梳理，它由产品负责人负责。

• 形式：PO组织需求评审，技术专家组织技术方案评审（按需）。
• 参与：PO、需求提出方、技术专家
• 目的：准备好计划会需要的需求，检查需求质量。若有问题，在计划会之前改完。
• DoD：

1. 需求的价值是否清晰？如何衡量？DoD？
2. 需求的优先级是否明确？
3. 需求依赖关系是否梳理清楚?
4. 运营方案是否Ready（按需）？比如内容、AB测试规则、流量来源等
5. 需求是否有初步的估算？
6. 需求的大小是否合理 ？

Sprint计划会(Sprint planning meeting)2h（一个月的sprint一般会议时长最多8小时，4 个小时用于选择故事和4个小时估算分配。）

Sprint规划会议为冲刺设定目标和方向。在冲刺规划会议上，Scrum团队会讨论优先级和估算工作量并确定在接下来的冲刺周期内要完成的工作（并确定冲刺目标）。产品负责人会优先展示产品待办列表中的项，团队成员则评估这些项的可行性并承诺在冲刺期间完成它们。冲刺规划的目标是确保团队有一个清晰的工作计划，并且每个成员都了解他们的任务和责任。开发团队使用Sprint Backlog来定义如何完成这个Sprint目标的细节。如果开发团队认为他们不能完成Sprint目标，就应该和产品负责人一起对Sprint目标再次斟酌。Sprint计划会的一个关键产出就是，开发团队应该能够解释如何完成Sprint目标，以及如何知道自己已经实现了这个目标。解释的能力来自于对未来工作的透彻理解，这就提高了团队在Sprint中实现Sprint目标的概率。并且，可将产品待办事项中的特定用途故事添加到冲刺中。这些故事应与目标始终保持一致，且 Scrum 团队也承诺可在冲刺期间完成。 

会议通常由产品负责人、Scrum Master和开发团队共同参加。本次会议由 Scrum MAster主持，在规划会议结束时，每位 Scrum 成员均需清楚在冲刺期间可以交付的内容，以及如何交付增量变化。

会中

1. 进行需求讲解。
2. 挑选PBI（product backlog item），也就是由客户选出重要的PBI。
3. 拆解PBI到SBI（sprint backlog item）。
4. 讨论每个SBI的工时。
5. team挑选本次Sprint任务。

• PO宣讲Sprint Goal (如果你的团队够成熟，也可以试试在会上群策群力定目标)
• PO按优先级逐条宣讲需求
• 团队讨论，确保充分理解需求后拆分任务
• 任务拆分的原则是拆分到人、不重不漏、大小合适
• 团队对拆分任务进行估算( 理想人天)
• 估算的分值可以是0.5、1、2、3、5、8、13、20、40、100……
• 之所以采用斐波那契数列，是因为它几乎以61.8%（黄金分割）递增，使人能清晰分辨差异
• 20以后的估算已经非常不准确，所以不是严格的数列
• 团队根据历史速率和当期的资源情况承诺交付范围
• 启动Sprint

会后

• 团队将任务录入JIRA等项目管理系统
• ScrumMaster检查看板确保信息完整准确
• 与团队最终确认冲刺计划
• 发Sprint启动邮件周知干系人

输出

• Sprint Goal
• Sprint Backlog
• 拆分的任务
• 信息完整准确的看板
• 冲刺计划邮件

冲刺（Sprint）

sprint是Scrum的核心，指一个固定长度的工作周期（通常为2到4周），在此期间团队集中精力完成预定的工作。每个Sprint结束时，团队应交付一个可工作的产品增量。Sprint的目标是通过短期的、可控的工作周期，降低风险、提高灵活性。

但国外知名敏捷教练 Dave West 建议，工作越复杂，未知因素就越多，而冲刺就应该越短。

一旦确定了冲刺的特定时间间隔，就必须在整个开发期间保持一致。这有助于团队吸取经验教训，并将这些洞察应用于未来的冲刺。

Scrum每日站会(Daily Standup Meeting)15min

每日站会是团队每天举行的短会，通常不超过15分钟。会议旨在让团队成员分享工作进展、计划和遇到的障碍。通过每日站会，团队成员保持同步，共同朝着冲刺目标努力，及时发现和解决问题，确保工作顺利进行。

这是每天在同一时间（通常是早晨）和地点举行的超短例会，以确保此会议简洁明了。很多团队试图在15 分钟内完成会议，但这只是一个参考。此会议也被称为“每日短会”，它强调需快速举行会议。

每日站会不仅提高了团队的透明度，还增强了成员之间的信任和协作。

每日短会的其中一种常见举行方法是让每个团队成员在实现冲刺目标的过程中回答三个问题：

我昨天做了什么？

我今天打算做什么？

是否存在障碍？

目的

改善沟通、同步进度、发现障碍、促进快速决策

会前

• 是否有阻塞、堆积？
• 重点需求进展是否顺利？当前的Milestone是什么？
• 是否有延期或其他影响Sprint目标的风险？
• 是否有并行过多？
• 团队是否在按优先级处理需求？
• 是否有中断？
• 是否有未反映在看板上的需求？
• 昨天站会暴露的问题和风险是否解决？
• 今天需要重点关注的人是哪一个？
• 除了日常站会内容，今天有没有需要和团队特别强调的话( 如回顾会总结的Focus Issue)？

会中

• 宣布站会开始，检查人员是否整齐，明确迟到的惩罚
• 围绕”做了啥、有啥问题、计划做啥“，适度展开讨论
• 发言的原则是每人一次，限制时间
• 主导更新任务状态及进度，始终确保聚焦（状态、剩余工时、Milestone时间）
• 问问题，把重点事项以及需要多人协同的工作略作展开
• 碰到不符合Scrum 理念的做法询问原因，及时纠正或者表明“未来想要的状态”
• 更新及解读燃尽图
• 做站会总结（重申当天目标）
• 明确会后会议时间( 如果需要)
• 宣布站会结束

会后

• 会后的Action记录
• 提醒团队更新JIRA（其他项目管理工具）
• 简单回顾自己的站会表现
• 注意时间，准备下一个站会

 每日Scrum会这一仪式有助于团队成员产生团队认同感。它将他们聚集在一起，重新关注他们的共同目标和共同身份。它增强了团队士气。

然而，我们发现会议很快会变成大家陈述昨天和第二天的日程表。每日短会的理论基础是：它可以分散日常会议的注意力，这样团队就可以在当天剩下的时间里专注于工作。

因此，如果它不幸沦为了每日日程表阅读会，则应果断做出改变以求创新。

Sprint评审会、演示会(Sprint Review Meeting)1h/1Week，以一个月的 Sprint 来 说，最多为 4h

在Sprint结束时，团队会举行Sprint评审会议，以观看增量演示或检查增量。开发团队向产品负责人和利益相关者展示工作成果，以征求他们的反馈意见。Sprint评审会议的目的是评估产品增量的完成情况，讨论改进建议，并为下一个Sprint做准备。

尽管在多数情况下都会发布增量，但产品负责人仍可决定是否发布增量。此次审核会议也是产品负责人根据当前冲刺重新处理产品待办事项之时，当前冲刺可为下一次冲刺规划会议提供相关信息。

目的

展示成果、对齐目标、收集反馈、激活团队

会前准备Demo

• 团队准备“可用的软件”，其他方面功夫，花的时间越少越好
• PO准备效果反馈数据，包括本迭代的以及上一迭代Demo时未能反馈的
• 未尽事宜 ( 如果有 不能报喜不报忧 )
• Demo的人选( 建议轮流 )

会中

• 控制时间，营造氛围（不是吐槽，营造一个“开放共建”的氛围）
• 节奏要快
• 不要花里胡哨的演讲，不要PPT
• 重申Sprint目标
• 团队演示重要功能(细碎的Bug和微不足道的小功能就算了)
• PO反馈是否通过，以及业务目标是否达成
• 如果当前不能反馈最终业务效果，则顺延至下一SprintDemo时反馈

会后

• 着眼于未来
• 产品Roadmap是否需要调整的输入
• 更新产品地图（ Release Plan ）
• 相关的信息一定要同步到位，因为有可能会影响最终产品的交付时间或者交付范围
• Retro的输入

处理无法演示的工作

• 员工自带解决方案，多问问题：你做完了吗？你怎么知道做完了呢？把RD逼疯 W(￣_￣)W
• 性能测试报告、日志、录屏都行，能传递信息就行

Sprint回顾会(Sprint Retrospective Meeting)一个月的 Sprint 来说，最多为 3 个小 时会议时长

Sprint回顾会议是团队在每个Sprint结束后进行的反思和改进会议。团队成员一起讨论在Sprint期间的表现，识别成功和不足之处，并制定改进措施。通过持续的反思和改进，团队能够不断提升工作效率和质量。

我们的思路是创造一个地方，让团队能够专注于哪些工作进展顺利和哪些地方有待改进，而不是专注于出了什么问题。

目的

回答：我们如何才能在下个Sprint中做的更好？

• 最终目的一定不是界定责任，打某人的板子。
• 人总是更乐意去做他们发自内心认同的的事情。
• 让团队自己发现问题永远是比直接给团队“解决方案“更有效的。
• 永远提醒团队不要满足现状，我们还可以做的更好。

会前

• 收集Sprint信息

1. 效率情况：燃烬图分析 、Brake/需求插入情况、Team Velocity及投入度的趋势
2. 质量情况：故障率、Bug解决速度趋势、Bug环境分布等。
3. 上一个Sprint的Focus Issue落实情况 （参考DoD）

• 提前准备好一些问题，引导团队自己引出对于某个事件/现象的看法。

1. 在这次Sprint周期中，哪些方面你做得很好？为什么好？哪些方面还可以改进？为什么？
2. 如果再次做同类事情，你会怎么去做？
3. 通过这次交流，对我们后续的工作有何指导？
4. 我们收获了哪些规律、原则、方法论？

会中

• 分享Sprint完成情况
• 分享上一个Sprint的Focus Issue落实情况
• 头脑风暴 Good/Need Improve
• 每人一张post，每张post写一点，方便同类合并
• 每个人都要表达
• 一个人认同跟十个人都认同的情况是完全不同的，不能因为之前有人表达过了，就不说了
• 投票决定下个Sprint Focus issue 2~3个
• Focus issue要有DoD

会后

• 如果不能落地，回顾会不如不开 ！
• Focus Issue上白板
• 需要外部支持的事项反馈
• 会议记录

Sprint goal还有其他功效？

杰夫.萨瑟兰（Jeff Sutherland）补充说，除了让团队保持专注外，Sprint目标还会促进蜂拥模式（Swarming，Scrum Pattern之一，将在单独的文章中介绍）的使用。我们能不能让大家一起做一件事？他说道：

2007年在硅谷，Palm正在开发一个网络操作系统，后来被惠普公司收购。前几个Sprint，团队做得很好，但在几个Sprint之后，他们似乎遇到了困难。PBIs没有完成。开发人员的积极性很低，而且很早就回家了。他们请我来，我请产品负责人和Scrum Master花了一个小时来采访团队成员，了解他们为什么没有积极性。我们发现，原因是他们不理解做的这些低层级的PBI要解决什么问题。

我们花了一个下午的时间来清理Product Backlog，清晰地展示出了高层级故事和分解出来的较低层级故事之间的联系。当开发人员了解到Sprint的目标是将网络操作系统的性能提高10%时，他们就有动力去完成低层级的故事，速度也恢复了正常。

理解为什么要实现PBI，对开发人员来说至关重要，特别是对专家级的开发人员来说，如果他们找不到自己工作的理由，就会宁愿去冲浪。

要注意的问题

例如，替代解决方案、需要但未知的知识、隐藏的任务、误解的需求、需要进一步细化的需求、开发人员之间的依赖关系，或者以阻塞形式出现的问题可能会在团队的日常工作中不断浮现出来。除了工作之外，团队成员缺勤（如病假）可能会迫使团队重新考虑其工作计划。

时间箱

 固定时间、固定活动

优势：专注、增加创造力、时间的价值实现程度、可用时间

MVP

最小可交付价值
最小可售单元
最小可行性产品

如何开始使用Scrum？

实施Scrum的第一步

开始使用Scrum的第一步是组建一个跨职能的Scrum团队，明确每个角色的职责，包括产品负责人、Scrum Master和开发团队。接下来，需要制定产品待办列表，列出所有需要完成的工作项，并由产品负责人优先排序。在进行第一次冲刺规划会议时，团队需要确定冲刺目标和具体的工作任务，确保每个成员都清楚他们的任务和责任。

常见的挑战与解决方案

在实施Scrum的过程中，团队可能会遇到一些挑战。常见的挑战包括角色不明确、缺乏管理支持、团队成员缺乏Scrum知识等。解决这些挑战的方法包括：

• 角色培训：确保每个Scrum角色的职责清晰，并提供必要的培训和支持。
• 管理支持：获得管理层的支持和认可，确保Scrum的实施得到组织的全力支持。
• 持续学习：鼓励团队成员不断学习Scrum知识，通过阅读书籍、参加培训和加入Scrum社区等方式提升技能。

持续学习与社区资源

Scrum是一个不断演进的框架，团队需要持续学习和改进。利用Scrum社区资源，如Scrum.org、Scrum Alliance等，可以帮助团队获取最新的知识和最佳实践。加入Scrum社区，通过参加活动、阅读博客、观看视频和参与讨论，团队可以不断提升自己的Scrum实践水平。此外，定期的内部培训和知识分享也有助于团队保持敏捷和高效。

适用场景

对于需求很明确的产品，比如一些传统产品或成熟的产品，需求非常明确，不会轻易改动需求，那么更适合瀑布开发模式。

而对于那些易变的需求，不能明确客户需求，不晓得用户心里到底想要什么，需要通过不断测试，实践来明确需求的，这种更适合 Scrum 开发。

敏捷开发中的概念非常多，是不是全部都要照着做呢？
答案是不一定。可以根据公司情况适当的裁剪一些步骤，或者灵活的修改一些做法。
上面写到的敏捷开发概念、步骤，是一种标准的做法。
比如在一些小公司做开发，步骤太多，就会显得繁琐，不够灵活做事。所以可以根据公司情况适当的调整。

Scrum的3个基本原则

Scrum基于三个基本原则：透明性、检查和适应。这些原则支持了迭代工作的概念，使团队能够通过小步实验来学习和改进。

• 透明：所有工作过程和成果必须对所有参与者可见。确保所有团队成员和利益相关者对项目的进展和问题有清晰的了解。透明性确保团队成员能够及时发现和解决问题。
• 检查：团队定期检查工作进展和工件，以发现潜在的偏差或问题。以确保团队朝着正确的方向前进。检查使适应成为可能。
• 调整：：根据检查结果，团队需要迅速调整工作计划和方法，以减少进一步的偏差并提高效率。

Scrum的五大价值观

Scrum框架不仅关注工作流程和工具，还强调团队的价值观。Scrum的五大价值观是承诺、勇气、专注、开放和尊重。这些价值观为团队的行为和决策提供了指导，确保团队成员在协作中保持高度的诚信和互信。

• 承诺：团队成员承诺完成他们的任务和目标。
• 勇气：团队成员勇于面对挑战和变化，敢于提出问题和建议。
• 专注：团队成员专注于当前的冲刺目标，避免分心。
• 开放：团队成员对新想法和反馈持开放态度，乐于分享和沟通。
• 尊重：团队成员相互尊重，认可彼此的贡献和能力。

Scrum与其他敏捷方法的结合

Scrum可以与其他敏捷方法结合使用，以满足特定项目的需求。例如，Scrum与看板（Kanban）结合，可以帮助团队更好地管理工作流和任务优先级。看板方法强调视觉化管理，通过看板板展示任务状态，Scrum团队可以更清晰地看到工作进展和瓶颈，从而进行及时调整。此外，Scrum还可以与极限编程（XP）结合，利用XP的技术实践来提高软件开发的质量和效率。

PDCA 循环：

Scrum 里有 PDCA 循环思想。Sprint 是一个迭代周期。里面的任务(task)也可以看作是一个更小的开发周期。

为什么需要跨职能团队

Scrum团队如果不能自主工作，就是因为它不具备完成复杂任务网络所需的所有技能。如果依赖团队外部人员的技能，团队就不能真正“拥有”手头的工作。这样团队对工作的完成时间就没那么有掌控力了，并且最终工作的质量也会受到影响。大多数复杂的开发工作都需要有来自不同领域（如人类工程学、工程卓越和质量保证等）的众多人才。然而，跨越团队边界协调这些职能的成本很高，因为只有在那些共享当前工作背景的人之间才能存在有效沟通 -- 这通常只有同一个团队的成员才能做到。

在团队创建初期，关注技能的覆盖度是很好的，但更重要的是，团队成员要对愿景有共同的热情，并愿意学习新鲜事物。因为事情会随着时间的推移而变化，团队不可能从一开始就预见到所有的长期技能需求。

scrum对如何处理能力缺失的问题没有提及，它相信这些都是常识可以搞定的 ：例如，向其他团队寻求帮助，或把大的工作外包出去，不过外包出去的工作结果就不好说了，有可能会让团队大吃一惊。如果团队偶尔需要这样的帮助，还是可以理解的。但如果团队发现他们经常要依赖外部的帮助，那么他们就应该把这看作是一种阻碍，并采取措施（如培训、重组或招聘）来补救这种情况。

例如，一个由软件程序员组成的团队可能会发现自己正在构建一个不属于自己专业领域的产品，如制药或航空航天。我们很想在团队中为每个弱势能力指定一个负责人，也许可以咨询外部领域专家。然而，团队代表可能不知道他们有多少不知道的东西，甚至可能不知道该向领域专家提出什么问题；反过来，大多数领域专家把领域专业知识当做隐性知识（译者注：已经成为专家潜意识的一部分），所以他们可能也没有办法意识到软件人员真正想要的洞见是什么（译者注：因为专家不会注意到他们觉得理所当然的事情，即隐性知识）。至关重要的是，团队成员要理解领域因素对实施的影响，并对业务和解决方案的空间都有全面的了解。在最近的一篇文章中，亚马逊的Jesse Watson指出，这两个因素"在一个头骨内"并存是至关重要的。[1] 最好是将专家带入团队，并通过交叉培训扩大知识面。但要记住保持小团队：向团队中增加专家可能会使团队合作减弱到几乎没有的地步。

SCRUM的优势

1、提高灵活性和响应能力

Scrum通过短期的、可控的工作周期和频繁的反馈环节，使团队能够快速适应变化，调整优先级。这种灵活性使得团队能够在不确定的环境中更有效地工作，及时响应客户需求和市场变化。

2、增强团队协作和沟通

Scrum强调团队成员的密切合作和信息共享，通过每日站会、回顾会议等机制，促进团队内部的沟通和协作。良好的团队协作有助于提高工作效率，快速解决问题，确保项目顺利进行。

3、提高产品质量

Scrum通过迭代和增量的开发方式，鼓励团队频繁交付可工作的产品部分，及时发现和修复缺陷。这种持续的改进和反馈机制有助于提高产品质量，减少后期的维护成本。

4、透明度和可见性

Scrum的工作流程和工件使得项目进展和团队工作状态对所有利益相关者透明可见。这种透明度有助于建立信任，确保各方保持一致，及时发现和解决问题。

5、激发团队士气和责任感

Scrum通过自组织和自我管理的工作方式，赋予团队成员更多的自主权和责任感。这种信任和授权有助于激发团队士气，提高工作积极性，推动团队不断进步。

SCRUM的挑战和解决方案

1、角色不明确

在一些团队中，Scrum角色的职责和权利可能不明确，导致角色冲突和责任不清。解决方案：通过培训和指导，明确每个角色的职责和权利，确保团队成员理解和尊重Scrum框架。

2、缺乏经验和技能

新手团队可能缺乏实施Scrum所需的经验和技能，导致Scrum流程执行不力。解决方案：引入经验丰富的Scrum Master或敏捷教练，提供培训和支持，帮助团队逐步掌握Scrum方法。

3、抵触文化变革

某些组织文化可能对Scrum的灵活性和自组织理念存在抵触，影响Scrum的实施效果。解决方案：通过沟通和教育，逐步引导组织接受敏捷文化，强调Scrum的优势和成功案例，获得管理层的支持。

4、过度依赖工具和流程

一些团队可能过度依赖Scrum工具和流程，而忽视了团队合作和沟通的重要性。解决方案：强调Scrum的核心价值观和原则，确保团队保持灵活和敏捷，注重实际问题的解决和改进。

5、持续改进不足

团队可能在实施Scrum一段时间后，忽视了持续改进的重要性，导致效率和质量停滞不前。解决方案：通过定期的Sprint回顾会议，鼓励团队反思和改进，确保持续的学习和进步。

实施 Scrum 会遇到的问题

• Product Backlog 里的需求怎么来？价值大小按照什么排序？
• 每一个 Sprint 里的 Sprint Goal 怎么确定？Sprint 实施时间怎么确定？
• Sprint Backlog 里的每个条目，怎么估算时间？每个开发人员能力不同，开发时间怎么估算？
• 每日站会怎么开？会不会大家对 Scrum 认识不足而流于形式的开会？
• Sprint 评审会怎么开？会不会变成吐槽会，甩锅大会？
• 看到敏捷 2 字，好多主管或工程师就误以为它是快速开发方法？这是对敏捷快速交付的片面理解。
• 还有一个最大的挑战，应该是大家开发习惯的转变。我们知道，要改变一个人脑袋里固有模式和习惯，接受新的理念和方法，总是很难的。

世界上最难的2件事情，一是：把新思想装进别人脑袋里，二是：把别人口袋里的钱装进自己口袋里。
等等各种问题。

但是 Scrum 强调自管理，遇到了问题不要紧，去寻找解决方法，不段的改进。

在实施 Scrum 中，团队的成员初期需要熟悉彼此，开始磨合时，矛盾可能增多。

但是随着不断进行 Sprint，彼此越来越熟悉，改进越来越多，摩擦慢慢会减少，Scrum Team 彼此之间协作也会慢慢进入到最佳状态，

从而不断增加有效产出。

SCRUM的最佳实践

1、定期培训和提升

通过定期的Scrum培训和工作坊，提升团队成员的敏捷思维和技能。这种持续的学习有助于团队更好地理解和实施Scrum方法，提高工作效率和质量。

2、引入经验丰富的Scrum Master

经验丰富的Scrum Master可以提供宝贵的指导和支持，帮助团队克服实施Scrum过程中遇到的挑战。Scrum Master的角色是确保Scrum流程的顺利进行，推动团队持续改进。

3、建立清晰的完成定义

清晰的完成定义（Definition of Done）是确保团队交付高质量产品的关键。通过制定和遵守完成定义，团队能够确保每个增量都达到预期标准，减少后期的返工和维护。

4、保持良好的沟通和协作

良好的沟通和协作是Scrum成功的关键，通过每日站会、Sprint评审和回顾会议，确保团队成员保持同步，及时发现和解决问题。这种良好的团队氛围有助于提高工作效率，推动项目顺利进行。

5、持续反思和改进

Scrum强调持续的反思和改进，通过定期的Sprint回顾会议，团队能够识别成功和不足之处，制定改进措施。这种持续的改进机制有助于团队不断提升工作效率和质量。

SCRUM的适用场景

1、软件开发项目

Scrum最初是为软件开发项目设计的，尤其适用于需求变化频繁、开发周期较短的项目。通过Scrum方法，团队能够快速响应客户需求，频繁交付可工作的产品部分。

2、创新和研发项目

Scrum也适用于创新和研发项目，这类项目通常具有较高的不确定性和变化性。通过Scrum的迭代和增量开发方式，团队能够灵活应对变化，逐步实现项目目标。

3、跨职能团队合作

Scrum强调团队的跨职能合作，适用于需要多种技能和专业知识协作的项目。通过Scrum的团队合作机制，团队成员能够紧密合作，共同推进项目进展。

4、大规模项目和组织

Scrum可以通过Scrum of Scrums等方式扩展，适用于大规模项目和组织。通过这种扩展机制，多个Scrum团队可以协同工作，共同实现项目目标。

5、提升组织敏捷性

Scrum不仅适用于项目管理，还可以用来提升整个组织的敏捷性。通过Scrum的实施，组织能够更快地响应市场变化，提高整体竞争力。

总结来说，Scrum敏捷开发是一种强大的项目管理框架，通过迭代和增量的开发方式，强调团队合作和持续改进，帮助团队在不确定性中高效工作。通过正确理解和实施Scrum，团队能够提高工作效率和产品质量，快速响应客户需求，适应市场变化。

IT项目经理在Scrum中的角色

虽然Scrum框架中没有专门的“项目经理”角色，但传统项目管理的职能和责任仍然在Scrum中得到了体现。在Scrum环境下，IT项目经理的角色通常会被拆解并分配给不同的成员，特别是Scrum Master和产品负责人。然而，项目经理的许多核心职责，如项目的规划、监控、风险管理、沟通等，依然是其工作的重要组成部分。

作为IT项目经理，虽然Scrum的执行工作交给了Scrum Master和开发团队，但你仍然需要具备以下技能和职责：

1. 跨部门沟通与协作

在Scrum中，团队需要与多个利益相关者（如客户、业务部门、开发人员等）进行频繁的沟通与协作。IT项目经理需要确保信息的流通畅通无阻，帮助团队在不同部门之间建立有效的沟通渠道。同时，项目经理还需要协调和管理各方期望，确保团队目标与组织目标一致。

2. 风险管理与解决问题

尽管Scrum强调自组织和团队的协作，但IT项目经理依然需要识别项目潜在的风险，并采取预防和应对措施。在Sprint中，项目经理应与Scrum Master密切合作，帮助团队识别和解决障碍，确保项目按时交付。风险管理不仅仅是技术上的挑战，还涉及到团队成员的工作负担、沟通冲突等软性因素。

3. 确保资源的有效分配

项目经理需要确保项目资源（如时间、人员、技术等）能够得到有效分配和使用。即使在敏捷环境下，资源的优化和调度仍然是项目成功的关键。在Scrum中，项目经理应帮助产品负责人与开发团队之间进行资源的协调，确保每个Sprint能够高效地推进。

4. 持续改进与过程优化

敏捷方法倡导持续改进。IT项目经理应鼓励团队从每个Sprint的回顾会议中吸取教训，推动流程优化。通过反思和调整，团队能够不断提升工作效率和交付质量。

5. 监控项目进度与绩效

尽管Scrum强调自管理和自组织，IT项目经理仍然需要对项目的进度进行监控，确保项目不偏离预定的目标。在Scrum中，项目经理可以通过以下几种方式来进行项目跟踪：

• Burn-down图：通过图表直观地显示Sprint的任务完成进度。

• Velocity（速度）：通过评估团队每个Sprint完成的工作量，预测后续的工作量和进度。

IT项目经理的Scrum敏捷技能

为了更好地适应Scrum框架，IT项目经理需要具备一些独特的敏捷管理技能。这些技能不仅帮助项目经理在Scrum环境下发挥作用，还能提升整个团队的工作效率和项目的成功率。

1. 敏捷思维与灵活性

敏捷项目管理的核心是灵活性和快速响应变化的能力。作为IT项目经理，你需要具备敏捷思维，能够快速适应环境变化并调整项目计划。这包括对变化的需求、技术挑战、市场动态等作出灵活的反应，同时保持团队的工作稳定性。

2. 领导力与团队管理

在Scrum中，团队是自组织的，但作为IT项目经理，你仍然需要具备较强的领导力，尤其是在团队面临困难或需要做出关键决策时。项目经理需要激励团队成员，帮助他们明确目标，克服挑战，保持高效协作。

3. 跨职能协作与客户管理

Scrum强调团队的跨职能合作，项目经理必须具备协调不同职能部门的能力。例如，产品负责人、开发人员、质量保证（QA）人员、设计师等都需要紧密合作，以确保产品能够快速迭代并交付。在此过程中，项目经理还需要与客户保持良好的沟通，确保产品符合客户需求。

4. 冲突解决与谈判技巧

在Scrum团队中，成员之间难免会产生分歧或冲突。项目经理必须具备一定的冲突解决能力，能够平衡各方利益，推动团队达成共识。此外，谈判技巧也是项目经理必备的技能之一，尤其是在需求优先级、资源分配等方面。

5. 数据分析与决策能力

敏捷项目管理中有大量的数据和指标（如Burn-down图、Velocity、Sprint成果等），项目经理需要能够分析这些数据，识别潜在的问题，并做出相应的调整。良好的数据分析能力帮助项目经理在不同阶段作出明智的决策。

 

规模化敏捷

总结

Scrum敏捷项目管理是一种强调灵活性、团队合作和持续改进的框架。对于IT项目经理而言，熟练掌握Scrum方法不仅是提升团队绩效和项目成功率的关键，也是适应快速变化的市场需求和技术挑战的必要能力。在Scrum环境下，IT项目经理的角色虽然有所不同，但仍然需要具备跨部门协作、风险管理、资源调配、过程优化等多方面的技能。通过这些技能，项目经理能够更好地支持Scrum团队，确保项目顺利推进，并实现高质量的产品交付。

总之，Scrum不仅是一种项目管理框架，更是一种文化和思维方式，要求项目经理具备灵活应变的能力、强大的沟通技巧、敏锐的风险意识和团队领导力。只有不断学习和实践，才能在Scrum的世界里成为一名真正的高效IT项目经理。

 

相关问答FAQs：

1. 为什么Scrum敏捷开发在软件开发中如此受欢迎？

Scrum敏捷开发之所以在软件开发领域广受欢迎，是因为它能够提供高度灵活性和快速响应能力。通过采用迭代和增量式开发方法，Scrum能够帮助团队更好地适应变化和需求调整，从而提高项目的成功率和交付速度。

2. 在Scrum敏捷开发中，什么是“Scrum Master”角色？

“Scrum Master”是Scrum团队中的一个重要角色，负责确保团队遵循Scrum流程和原则。他们的职责包括解决团队所面临的问题和障碍，促进团队的自组织和自我管理，并协助团队达成既定目标。Scrum Master还负责组织Scrum会议和监督团队的工作进展。

3. Scrum敏捷开发中的“产品负责人”角色有什么职责？

“产品负责人”是Scrum团队中的另一个关键角色，他们代表利益相关者和用户，负责定义和优先确定产品需求，并确保团队根据需求开发可交付的产品。产品负责人还负责管理产品需求的优先级和范围，并与团队合作制定产品的发布计划。他们的目标是确保团队开发出符合用户期望的高质量产品。

 

官方网站

https://scrumguides.org/

 

年度敏捷状态报告

https://stateofagile.com/

 

常见敏捷框架scrum图

 

 

 

(https://www.wrike.com/scrum-guide/scrum-sprints/)