关于scrum:什么是Scrum高效能管理框架Scrum核心精髓

有点长，冀望你能通过本文彻底理解 Scrum。

在本文中，我首先回顾了下个性团队，指出个性团队的一些问题，接着进入正题介绍 Scrum 的定义、特色、劣势，而后讲述了 Scrum 的 3 个角色，接着是框架、流程、5 个会议和 3 个工件，最初列了一些我在应用 Scrum 时遇到的一些问题，心愿能触发你的思考。

回顾个性团队

个性团队是一个长期稳固、跨职能、跨组件，继续端到端交付用户价值的团队，负责把一个个「以用户为核心的性能」变成一个个可交付的产品增量。从这张图中，我发现这个过程有点糙。有点怎么把大象装冰箱里的感觉。一些问题没有答复，比方：

• 这三个人都是啥角色
• 都负责什么？
• 怎么配合
• 日常工作是什么？

上面我来介绍下 Scrum 的框架，平时我就是用它帮我解决这些问题的。

Scrum 的定义和特色

Scrum 的定义

Scrum 是一个用于开发和保护简单产品的框架，是一个增量的、迭代的开发过程，目标是让开发人员像打橄榄球一样迅猛并充斥激情，通过团队单干，进步工作效率。通过团队间的无效交互，为企业发明价值。

Scrum 的特色

• 迭代开发：有固定周期的迭代，每个迭代都交付一些增量的可工作的性能。
• 增量交付：每个迭代完结前，实现新的增量的交付。
• 自组织团队：自组织治理工程过程和进度，决定本人如何发展工作，决定谁来做什么
• 高优先级的需要驱动：研发团队要从待办列表最上层的高优先级的需要开始开发

Scrum 的劣势

• 疾速反馈：个别 1 - 2 周一个迭代周期，也是一个反馈周期
• 尽早交付：高优先级需要及时满足
• 危险升高：短周期继续反馈，问题及时修改
• 适应变动：小步快跑，一直修改
• 继续改良：一直反思、回顾、优化
• 客户称心：始终与用户进行沟通，一直反馈修改需要

Scrum 的人员和角色

3.1 产品负责人 PO(Product Owner)

PO 角色定义

确定产品的方向和愿景，定义产品公布的内容、优先级及交付工夫，为产品盈利负责。保护产品需要清单，代表利益相关者的利益，代表业务方。

• 个别产品经理负责，或者由相熟畛域业务想转产品经理的研发人员负责。因为产品经理自身曾经是所有业务的接口人，相熟畛域常识、熟悉业务是其本职工作，所以产品经理负责 PO 更正当。
• 不倡议仍然写代码的研发人员负责。写代码和负责整个业务都是须要全身心注入的工作。
• 不倡议 SM 专任

总体准则，「谁了解用户」「谁相熟畛域业务」，「谁能代表业务方」、谁来负责 PO。

PO 主要职责

• 帮公司失去最高投资回报，指引团队做最有价值的工作，为产品的 ROI 负责
• 确定产品的性能，定义实现的规范，验证交付的工作成绩
• 决定公布的日期和公布内容
• 依据市场价值、用户价值调整产品性能和优先级
• 承受或回绝开发团队的工作成绩；
• 参加五个会议：产品待办布局会，迭代打算会议, 每日站立会，迭代评审会，迭代反思会

PO 日常工作

• PO 参加产品布局，对接内、内部利益干系人
• 对产品待办梳理、优化、优先级排序
• PO 负责制订迭代打算，确认团队每个迭代实现的性能、优先级和预期交付日期
• PO 加入每日站立会，听取状况，理解停顿，廓清需要。
• PO 必须每天可能解答问题，并进行验收测试。
• Sprint 内，PO 还要确定下个迭代的打算，交付性能、优先级程序以及交付日期。
• Sprint 完结时，PO 要参加迭代展示会 (show case) 和 Sprint 反思会。

3.2 麻利教练 SM (Scrum Master)

Scrum Master 角色定义

• 是团队的 Scrum 教练和组织者，与 PO 严密单干，保障的是麻利开发的流程和秩序。整个团队保障停顿和后果。
• 是规定的执行者，是团队中的服务型领导。促使团队依照 Scrum 形式运行，为 Scrum 过程负责的人
• 个别可由更相熟麻利开发模式及施行流程的 PMO 来负责

Scrum Master 主要职责

• 帮忙员工及干系人了解并施行 Scrum
• 领导团队采纳 Scrum，治理 Scrum 流程，确保流程的贯彻执行
• 组织召开每一个会议，解决团队在开发过程中遇到的问题
• 找到妨碍团队高绩效的阻碍，并解决
• 确保团队外部沟通顺畅、高效
• 团队和内部的接口人，保障团队专一和工作节奏，爱护开发团队不受烦扰
• 保障各个角色及职责良好合作
• 保障开发过程按计划进行

Scrum Master 日常工作

• Scrum Master 领导团队成员听从 Scrum 流程和应用麻利工具
• Scrum Master 组织召开五个会议
• Scrum Master 加入每日站立会。例会上听取状况，甄别危险和问题、提供帮助。
• Scrum Master 解决团队在开发过程中遇到的问题
• Scrum Master 帮团队扫清高效能的阻碍

3.3 研发团队 Team(Scrum Team)

研发团队角色定义

负责在每个迭代的结尾交付潜在可公布的“实现”产品增量

由组织构建并受权, 来组织和治理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效劳。

• 他们是自组织的, 没有人 (即便是 Scrum Master 都不能够) 通知开发团队如何把产品 待办事项列表变成潜在可公布的性能。
• 开发团队是跨职能的, 团队作为一个整体领有发明产品增量所须要的全副技能。
• Scrum 不认可开发团队成员的头衔, 无论承当哪种工作他们都是开发者。此规定无一例外。
• 开发团队中的每个成员能够有专长和专一畛域, 然而责任归属于整个开发团队
• 开发团队不蕴含如测试或业务剖析等负责特定畛域的子团队。

研发团队的主要职责

• 负责自组织地交付用户故事
• 做交付过程中的所有工作
• 摆布估算流程
• 决策「如何实现」

研发团队日常工作

• 了解迭代待办，拆分工作项
• 评估工作量、开发产品、实现代码编写且自测通过
• 团队做技术决策：技术调研、架构设计
• 自领迭代工作、团队决定任务分配
• 评审测试用例
• 产品上线交付用户价值

Scrum 框架和流程

• 【PO】和所有利益相干人密切合作，从用户角度以及公司业务思考问题和决策
• 【PO】创立产品愿景、产品路线图；梳理最有价值的产品性能，
• 【PO】把最有价值的产品性能保护到一个依照优先级排列的产品待办列表(Product Backlog)
• 【PO】负责细化产品待办列表中的所有用户故事
• 【SM】召开产品待办布局会，PO 依照优先级形容要做的产品待办，团队进行了解、发问，PO 针对问题进行细化；团队会后进行工作了的预估和安顿。
• 【SM】召开迭代布局会，PO 依照优先级逐条具体解说本次迭代要实现的产品待办，研发团队依照优先级筛选要实现的产品待办，直到下个迭代工作量达到饱和，同时创立关联的工作待办列表，并和产品待办关联。
• 【研发团队】自组织召开每日站立会，SM 和 PO 必须加入；每个人讲完本人的进度后，更新工作看板内容。PO 帮忙接到迭代中的问题；SM 解决影响团队高效能的问题。
• 【SM】召开迭代评审会，研发团队进行 show case，承受评估；PO 以用户故事是否能胜利交付来评估工作实现状况。
• 【SM】召开迭代反思会，总结哪些做的好，要保留；哪些做得不好，要改良

Scrum 5 个会议

5.1 产品待办布局会（Backlog Grooming Meeting）

• 开会时间：通常是迭代打算会开始前 3 天
• 参加人员：PO，SM，研发团队
• 散会指标：咱们下个迭代要做的内容，开发团队确认工作故事点
• PO 把下次迭代将要实现的用户故事、依照优先级形容给在场的人员
• 团队明确指出需要不明确或者有问题的中央，PO 记录，会后补全、廓清
• 开发团队评估工作故事点
• 开发团队创立子工作并关联

5.2 迭代打算会（Sprint Planning）

• 开会时间：迭代开始的第一天
• 参加人员：PO，SM，研发团队
• 会议指标：决定咱们下个迭代要做哪些内容。
• PO 确认待办事项整顿会议上的问题都曾经解决，性能曾经欠缺或者有余。产品性能列表曾经依照客户价值优先级排序。
• PO 逐条具体解说要实现的产品待办，尤其是之前存在问题的待办。
• 开发团队依据待办事项整顿会议会后评估的工作量，从高到低筛选待办，直到本次迭代工作量达到饱和。
• PO 参加探讨并答复和需要相干的问题，但不烦扰估算后果。
• 最终产生迭代待办事项列表（Sprint Backlog）
• 队员认领工作

5.3 每日站会（Daily Scrum）

• 参加人员：PO，SM，研发团队
• 会议指标：理解团队现状
• 每日 Scrum 通常不超过 15 分钟。
• 每日 Scrum 中可能有简要的问题廓清和答复，但不探讨。每日 Scrum 既不是向管理层汇报，也不是向产品负责人或者 ScrumMaster 汇报。它是一个开发团队外部的沟通会议，来保障他们对现状有统一的理解。

开发团队是自组织的，通过每日站会来确认他们依然能够实现迭代的指标。每一个开发团队成员须要提供以下三点信息：

• 昨天我实现了什么
• 明天我打算实现什么
• 有什么问题

5.4 迭代评审会（Sprint Review）

• 开会时间：迭代完结前，通常 1 小时
• 参加人员：PO，SM，开发团队、利益感激人
• 在冲刺完结前，团队成员给产品负责人展现我的项目成绩，承受评估
• PO 给出评估和反馈。以用户故事是否能胜利交付来评估工作实现状况。

5.5 迭代反思会（Sprint Retrospective）

• 开会时间：迭代完结后，通常 1 小时
• 参加人员：PO，SM，研发团队
• 简短的反思会，总结哪些事件做得好，哪些事件做得不好。
• 做得好的要保留，做得不好的要摒弃。
• 会议得出这样的论断：开始做什么、持续做什么、进行做什么

Scrum 3 个工件

产品待办列表

• 产品待办是对产品性能的详细描述。
• 产品待办的起源能够是产品性能需要、缺点、改良、技术升级等
• 产品待办列表是一个具备优先级的需要列表，并对每个需要进行了粗略的估算。
• 产品待办列表是产品需要的惟一起源，开发团队所有工作都来自产品待办列表
• 只有 PO 有权对产品待办列表更改优先级、删除、增加。

好的产品待办列表要做到 DEEP

• 粗细合适的（Detailed appropriately）：待办事项列表顶端的百分之十可能蕴含十分小且剖析得很具体的事项，而其余的百分之九十则不是那么具体。
• 估算过的（Estimated）：团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术危险估算。
• 涌现式的（Emergent）：为了响应学习和变动，要定期梳理产品待办事项列表。产品负责人会一直地更新产品待办事项列表，以反映客户需要的变动、新想法或见解、竞争而导致的变动、呈现的技术阻碍等。
• 排好优先级的（Prioritized）：在产品待办事项列表顶端的事项具备最高优先级，或者是从 1 开始顺序排列。

迭代待办列表

• 来源于产品待办列表：在迭代打算会议上，自组织团队在会议中生成迭代待办列表。团队从产品待办列表中挑选出要在本轮迭代要实现的用户故事，将用户故事转化为具体的工作，每项工作落实到具体的责任人。
• 迭代待办列表是以后迭代须要实现的产品待办列表。

可交付产品增量(Increment)

• 可工作的软件性能增量。
• 须要在迭代评审会议上进行演示
• 迭代完结前，性能增量须要达到团队“实现”的定义的规范
• 无论 PO 决定公布它与否，增量必须可用

Scrum 的思考

学习完了 Scrum，上面的问题，你是否思考过？

• PO 的老板是谁、谁来给 PO 打绩效、考核的规范是啥？
• SM 的老板是谁、谁来给 SM 打绩效、考核的规范是啥？
• SM 是教练，团队成员体现不好，SM 是否有权让其下场劳动？
• SM 是服务型领导，除了服务, 还能领导什么？
• SM 确保团队施行和应用 Scrum。团队胜利肯定要采取 Scrum 么？是否能够采取一部分？
• Team 老板是谁、谁来给团队成员打绩效、考核的规范是啥？团队外部的人还是内部的人？外部的人是否公正，内部的人是否理解其工作内容、成绩和状态？
• 团队绩效和集体绩效啥关系？
• 整个团队运行 Scrum 很好，但产出不迭「鸡」的预期怎么办？
• PO 负责产品代办列表的内容、优先级和交付日期，冀望 Sprint 代办上的内容能尽快解决，但 Team 在做不在「Sprint 代办列表上」的事件如何解决？
• PO 冀望每个有价值的增量做完验证后能及时上线交付，Team 只想每周三公布一次，谁来决定？
• 业务线刚创立初期，PO 想团队能跑得更快些，尽快公布性能收集用户反馈；Team 想打牢根底做好架构未来好保护，一个需要做了两星期，怎么破解？
• 业务有肯定业务量后，PO 想把产品性能齐备；Team 想重构优化产品性能，如何？
• SM 在其它团队带来的需要是否具备更高优先级？
• 迭代中，团队须要出一个报告，当初须要查问数据，这个谁来反对？
• 平安团队排除了安全漏洞，这个谁来负责？
• 线上零碎告警了，解决流程是啥？谁来负责？
• 用户冀望用咱们零碎的时候，心愿当时有文档、两头有培训，后续有反对，这个怎么办？
• 公司的所有零碎要申报知识产权，申请专利，谁来负责？
• 非「循序渐进」的工作放到产品代办列表中，PO 去跟进？还是 SM 去跟进？
• 须要立即解决的事件，是否能够插入迭代中？还是插入一个而后抽出一个同工作量的待办？

下面的很多问题，都是理论工作中的问题。你是否思考过？

参考文章

Scrum 的 4 种会议
https://www.cnblogs.com/jetli…

麻利开发流程之 Scrum：3 个角色、5 个会议、12 准则
https://juejin.cn/post/684490…

麻利开发方法——XP 及 SCRUM
https://zhuanlan.zhihu.com/p/…

研发效力组织能力建设之个性团队 FeatureTeam（上）