有点长，期望你能通过本文彻底了解 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（上）