Scrum

Scrum

Scrum 理论

瀑布模型失败的根本原因

瀑布模型的假设：需求在开发开始前是清晰的、完整的、稳定的 与现实不符合

软件开发为什么需要Scrum

• 传统瀑布模型在复杂系统面前系统性失败：需求无法在开始前完全定义，错误反馈太晚，修复成本指数级增长
• Scrum拥抱不确定性，通过短迭代+经验主义替代长计划+预测注意

Scrum定义

由一个跨职能团队在不同阶段完成整个过程。而团队“作为一个整体前进，把球传来传去”

Scrum不是构建产品的一种过程或一项技术，而是一个框架，在这个框架里可以应用各种流程和技术。Scrum能使产品管理和开发实践的相对功效显现出来，以便随时改进

Scrum以整体的形式存在，才能作为其他技术、方法论和实践的容器良好运作

Scrum是一个轻量的框架，它通过提供针对复杂问题的自适应解决方案来帮助人们、团队和组织创造价值

Scrum需要Scrum Master营造一个环境，从而：

1. 一名Product Owner将解决问题所需的工作整理成一份Product Backlog
2. Scrum Team在一个Sprint期间将选择的工作转化成价值的Increment
3. Scrum Team和利益攸关检视结果并为下一个Sprint进行调整
4. 重复

Scrum 33355（或3355）

• 三大理论支柱
  • 透明
    • 过程与工作成果对团队和利益相关者可见
  • 检视
  • 定期审查进展，识别偏差（通过五大事件实现）
  • 适应
  • 及时调整偏离目标或质量的问题
• 五大价值观
  • 承诺
    • 专注目标
  • 专注
  • 聚焦Sprint任务
  • 开放
    • 坦诚面对挑战
  • 尊重
  • 认可成员的能力
  • 勇气
  • 解决棘手的问题
• 三个角色 团队结构
  • Developers 开发人员
    • 跨职能开发，交付可用增量
  • Product Owner
  • 确保框架实施，移除障碍
  • Scrum Master
  • 确保框架实施，移除障碍

团队特性：10人以内，自管理，跨职能，专注单一Product Goal

• 三个工件
  • Product Backlog
    • 定义：产品需求动态清单
    • 承诺：Product Goal（产品愿景）
  • Sprint Backlog
    • 定义：Sprint任务计划（目标+选定的条目）
    • 承诺：Sprint Goal（迭代目标）
  • Increment 增量
    • 定义：符合完成标准的可交付成果
    • 承诺：Definition of Done（完成标准）
• 五大事件
  • Sprint
    • 固定周期（<=1个月），不可变更目标和质量
  • Sprint计划会议 Sprint Planning
    • 确定Sprint Goal与交付计划（时间盒：8小时/月）
  • 每日Scrum会议 Daily Scrum
    • 15分钟站会，调整当日计划
  • Sprint评审会议 Sprint Review
    • 展示增量，调整Backlog（时间盒：4小时/月）
  • Sprint回顾会议 Sprint Retrospective
    • 改进流程与效能（时间盒：3小时/月）

Scrum理论

• Scrum基于经验主义和精益思维。经验主义主张知识源自实际经验以及根据当前观察到的事物作出的判断所获得。精益思维减少浪费，专注于根本（第一性思维）
  • 经验主义强调通过观察具体现象，再通过归纳法（从个别案例推到普遍规律）形成知识 强调证据、实验和可验证性
• Scrum将4个正式事件组合在一起以在一个容器型事件Sprint中进行检视和适应。这些事件之所以起作用，是因为它们实现了基于经验主义的Scrum的三个支柱：透明、检视和适应

三个支柱

• 透明
  • 浮现（Emergent 随着工作的实际推进、团队认知的加深和外界反馈的介入，那些原本未知、模糊或被隐藏的事物，逐步自然显露、生长和明确出来的过程）的过程和工作必须对执行工作的人员和接受工作的人员都是可见的。在Scrum中，重要的决策是基于3个正式工件的感知状态。透明度较低的工件可能大致作出降低价值并增加风险的决策。透明使检视成为可能。没有透明的检视会产生误导和浪费
• 检视
  • Scrum工件和实现商定目标的进展必须经常地和勤勉地检视。以便发现潜在的不良的差异或问题。为了帮助检视，Scrum以5个事件的形式提供了稳定的节奏。检视使适应成为可能。没有适应的检视是毫无意义的
• 适应
  • 如果过程的任何方面超出可接受的范围或所得的产品不可接受，就必须对当下的过程或过程处理的内容加以调整。调整工作必须尽快执行以最小化进一步的偏差

Scrum Team

• Scrum Team由一名Scrum Master，一名Product Owner和Developers组成。在Scrum Team中，没有子团队或层次结构
• Scrum Team规模足够小以保持灵活，同时足够大以便可以在一个Sprint中完成重要的工作，通常只有10人或更少。总得来说，较小的团队沟通更好，效率更高
• 如果Scrum Team变得太大，则应考虑将他们重组为多个具有凝聚力的Scrum Team，每个团队都专注于同一产品

跨职能的Scrum Team

• Scrum Team是跨职能的，这意味着团队成员具有在每个Sprint中创造价值而所需的全部技能
  • 完整技能闭环：具备到端交付价值所需全部能力
  • 这意味着它不依赖于跟其他团队的工作交接，也不用等待其他团队的工作
  • 反例：职能团队，UI团队，业务逻辑团队，测试团队，数据团队等等。团队等待，责任扯皮，交流沟通成本剧增
• 跨职能不是万能药：保持核心技能深度的同时，建立足够的协作带宽

自管理的Scrum Team

• 这意味着团队内部决定谁做什么、何时做以及如何做
• Hackman权利矩阵

微观管理及其危害

• 微观管理一般是指：在对员工的工作管理中，管理者过度关注和控制工作细节的管理风格和管理行为
• 关注细节并非坏事，但一旦过于关注和控制细节，就会带来种种问题
  • 会导致团队成员失去主观能动性
  • 会导致工作中出现决策等待和低效
  • 会影响到团队的积极性和士气

微观管理本纸是管理精度的失控

自管理和自组织

• 自管理
  • 个人或团队在明确目标下，通过自我规划、自我监督、自我调整等方式，自主完成任务的机制
  • 核心：对“行为”的自主控制，强调个体或小单元的主动性和责任感
• 自组织
  • 复杂系统在没有外部指令干预的情况下，通过内部成员或元素的互动，自发形成有序结构和功能的过程
  • 核心：系统层面的“结构或秩序”自发涌现，强调整体动态适应性
• 均强调“去中心化”和“自主化”，反对僵化的外部控制，注重灵活性和适应性

Developers

• Developers是Scrum Team中致力于创建每个Sprint可用Increment的任何方面的人员
• Developers所需的特定技能通常很广泛，并且会随着工作领域的不同而变化，但是Developers始终要负责
  • 为Sprint创建计划，即Sprint Backlog
  • 通过遵循Definition of Done来注入质量
  • 每天根据Sprint Goal调整计划
  • 作为专业人士对彼此负责

Product Owner

• Product Owner负责将Scrum Team工作所产生的产品价值最大化
• Product Owner还负责对Product Backlog进行有效管理，包括
  • 开发并明确地沟通Product Goal
  • 创建并清晰地沟通Product Backlog条目
  • 对Product Backlog条目进行排序
  • 确保Product Backlog是透明的、可见的和可理解的
• Product Owner可以自己做上述工作，或者也可以将职责委托他人。但Product Owner是服最终责任的人

• 为保证Product Owner取得成功，整个组织必须尊重他们的决定。这些决定在Product Backlog的内容和顺序中可见，并在Sprint Review时透过可检视的increment予以体现

• Product Owner是一个人，而不是一个委员会 在Product Backlog中，Product Owner可以代表许多利益攸关者的期望要求。那些想要改变Product Backlog的人可以尝试去说服Product Owner来做到这一点

Scrum Master

• Scrum Master负责按照Scrum指南的游戏规则来建立Scrum 通过帮助Scrum Team和组织内的每个人理解Scrum理论和实践来做到这一点

• Scrum Master对Scrum Team的效能负责 通过让Scrum Team在Scrum框架内改进其实践来做到这一点

• Scrum Masters是真正的领导者，服务于Scrum Team和作为更大范围的组织

  • 服务Scrum Team
    • 作为教练在自管理和跨职能方面辅导Scrum Team成员
    • 帮助Scrum Team专注于创建Definition of Done的高价值Increment
    • 促使移除Scrum Team工作进展中的障碍
    • 确保所有Scrum事件并且是积极的、富有成效的，并且在时间盒内完成
  • 服务Product Owner
    • 帮助找到有效定义Product Goal和管理Product Backlog的技巧
    • 帮助Scrum Team理解为何需要清晰并简明的Product Backlog条目
    • 帮助建立针对复杂环境的基于经验主义的产品规划
    • 当需要或被要求时，引导利益攸关者协作
  • 服务组织
    • 带领、培训和作为教练辅导组织采纳Scrum
    • 在组织范围内规划并建议Scrum的实施
    • 帮助员工和利益攸关者理解并实施针对复杂工作的经验主义方法
    • 消除利益攸关者与Scrum Teams之间的隔阂

用户故事

用户故事模版

• 用户故事是产品列表的基础构件
• 用户故事模版
  • 作为<某类用户> 用户角色 Who
    • 想要功能的是谁
  • 我想<做某事> 功能 What
    • 预期功能是什么
  • 从而<创造出某些价值> 为什么 Why
    • 为什么用户想要这个功能

Ron Jeffries的3C原则

• 卡片 Card
  • 在一堆卡片上写下你期望的软件特性
• 交谈 Conversation
  • 聚在一起对要开发的软件进行深入讨论
• 确认 Confirmation
  • 对完工条件进行确认

用户故事是占位符

• 用户故事的信息量足以提醒团队有东西要完成，但我们刻意地不过多探讨细节直到必需之时
• 需要阐述用户故事细节时，使用召集相关团队成员参与交谈的形式。交谈的目标在于，对故事内容以及所需完成的工作达成共识。相对于依赖书面文档，使用实时对话的方式能高效地达成此目标。它有更多的信息流动

用户故事接收标准

• 交谈中，如果某一刻大家觉得对用户故事已有共识，那就该写验收标准了。找出一列测试，直到所有参与交谈的人都认同测试通过意味着故事按预期实现即可，再用简单易懂的话记录下来
• 接收标准回答：“我们如何得知它何时已完工”
• 理想情况下，团队应该可以根据接收标准写出自动化测试，甚至是在功能实现之前（TDD Test-Driven Development）位于产品列表下方的故事可能不会很快被实现，接收标准可以降低精度

用户故事INVEST原则

• 独立性 尽可能的让一个用户故事独立于其他的用户故事
• 可协商性 一个用户故事的内容要是可以协商的，用户故事不是合同
• 有价值 每个故事必须对客户具有价值（无论是用户还是购买方）
• 短小 一个好的故事在工作量上要尽量短小，至少要确保的是在一个迭代或Sprint中能够完成
• 可测试性 一个用户故事要是可以测试的，以便于确认它是可以完成的

DoD Definition of Done

• 用于描述一个用户故事、任务或功能何时可以被认为真正“完成”。它是团队对完成工作的标准化定义，确保开发过程中每个增量都符合质量要求并准备好交付
• 提高透明度 DoD明确了完成的标准，减少了团队之间的沟通误解
• 保证质量：通过对代码质量、测试和文档的明确要求，确保产出的增量软件可用且可靠
• 支持验收流程：DoD是验收用户故事或功能的依据
• 防止技术债：通过明确完成标准，避免开发过程中留下未解决的问题

BDD Behavior-Driven Development

• 行为驱动开发（BDD）是一种基于敏捷的软件开发方法论，其核心思想是通过定义软件的行为来驱动开发过程。BDD的重点是增强团队对需求的理解，并确保开发的软件满足业务目标

• BDD是从测试驱动开发（TDD）演化而来的，强调在开发开始之前，用自然语言描述软件应如何行为。通过让技术人员、业务人员和测试人员围绕共同的需求语言进行协作，消除了沟通中的协议

BDD的实践流程

1. 编写用户故事
   • 采用用户故事模版描述功能需求
2. 定义验收标准
   • 通常以场景的形式定义
     • Scenario[场景描述]
     • Given[初始状态]
     • When[执行的操作]
     • Then[预期的结果]

Backlog

产品Backlog

• 是Scrum的核心，是按重要性排序的需求或故事的列表

Product Backlog 动态需求池

• Product Backlog是一份涌现的和有序的清单，它列出了改进产品所需的内容。它是Scrum Team所承担工作的唯一来源
• 能够被Scrum Team在一个Sprint中完成的Product Backlog条目被认为准备就绪，在Sprint Planning事件中可供选择。它们通常在精化后获得这种透明度
• Product Backlog精化是将Product Backlog条目分解并进一步定义为更小更精确的行为。这是一项持续进行的活动，为Product Backlog条目增添细节，例如描述、优先顺序和规模，这些属性通过随工作领域而变化

用户故事地图

• 用户故事地图是一门在需求拆分过程中保持全景图的技术

• 敏捷软件开发中使用用户故事地图来发现、管理需求

故事地图解决的问题

• 全局视角的缺失
  • 传统的待办事项列表（Backlog）往往只关注单个功能，缺乏对整体产品的全局视角，导致团队难以理解产品的整体结构和用户体验流程
  • 用户故事地图通过横向展示用户活动，纵向排列功能细节，提供了产品的全貌地图，帮助团队更好地理解用户的使用路径
• 需求优先级难以确定
  • 在复杂的项目中，众多需求可能让团队难以确定哪些功能应优先开发
  • 用户故事地图通过将用户故事按照用户活动和任务进行组织，清晰地展示各功能的相对重要性，便于团队合理安排开发顺序
• 缺乏用户需求聚焦
  • 开发过程中，团队可能过于关注技术实现，忽视了用户的真实需求
  • 用户故事地图强调从用户角度出发，确保开发的功能真正满足用户需求，提升用户满意度
• 难以理解功能之间的关系
  • 在大型项目中，不同功能之间的关系可能复杂，团队难以把握
  • 用户故事地图通过结构化的方式展示功能之间的关联，帮助团队更好地理解和管理这些关系
• 发布计划不明确
  • 在敏捷开发中，确定每次发布的功能范围至关重要
  • 用户故事通过清晰地展示各功能的优先级和依赖关系，帮助团队制定合理的发布计划，确保每次发布都能为用户提供有价值的功能

Sprint

• Sprint是Scrum的核心，在这里创意转化为价值
• 它们是固定时长的事件，为期一个月或更短，以保持一致性。前一个Sprint结束后，下一个新的Sprint紧接着立即开始
• 实现Product Goal所需的所有工作，包括Sprint Planning 、Daily Scrum、Sprint Review和Sprint Retrospective，都发生在Sprint内

Sprint长度

• 时间短：“敏捷”——短反馈周期=频繁交付=频繁客户反馈=错误方向持续时间短=学习改进速度快
• 时间长：更多时间作充分准备、解决问题、达成目标，不会被接二连三的会议压的不堪重负
• 当前，Scrum周期通常为2个星期

计划会议

Sprint计划会议准备

• 所有重要的backlog条目都已经根据重要性被评分，不同的重要程度对应不同的分数。分数只是用来根据重要性对backlog条目排序
• 所有人都可以编写添加条目，但只有Product Owner才能决定优先级

Sprint计划会议目标

• 以终为始
  • sprint目标（尽可能简单的语言，团队成员认同）
  • 团队成员名单（以及他们的投入程度，如果不是100%的话）
  • Sprint backlog（即Sprint中包括的故事列表）
  • 确定好Sprint演示日期
  • 确定好时间地点，供举行每日Scrum会议

Product Owner必须参加计划会议

• 每个故事都含有三个变量，它们两两之间都对彼此有着强烈依赖

  • Scope 范围 这个功能具体要做多少东西？包含哪些细节？
  • Estimate 估算 实现这些东西需要多长时间、多大技术难度？
  • importance 重要性 这个功能对业务有多关键？排在前面还是后面？

• 三个变量不包含质量，因为内部质量必须最好，外部质量可以简陋一些

• 范围和重要性由重要性由产品负责人设置。估算由团队设置

• Sprint计划会议上，经过团队和产品负责人面对面的对话，这三个变量会逐步得到调整优化

  

计划会议

• 定下每日例会的时间和地点：这必须是每一个成员都能接受的时间和地点
• 确定技术故事：需要完成但是不属于可交付的东西（独立于具体业务之外的基建工作）如
  • 安装持续构建服务器
  • 编写系统设计概览

计划会议产物 Sprint信息页

• Sprint goal
• Sprint backlog
• Estimated velocity 预估速率
• Schedule
• Team

Sprint管理

白板Scrum任务板 Scrum Board

一个最标准的 Scrum 看板通常是一个二维的矩阵：横向是流程，纵向是故事。

1. 纵向：泳道 (Swimlanes) —— 承载“故事”

看板的每一行通常被称为“泳道”。

• 每一行的最左侧，贴着“用户故事 (User Story)（图纸里的大白框，比如“微信支付”）。
• 这意味着，这一整行里的所有小卡片，都是为了完成这一个大故事服务的。
• 白色贴纸是故事 黄色贴纸是task

1. 横向：列 (Columns) —— 任务的生命周期

这是看板的灵魂，所有的“任务 (Task)”（图纸里的黄色小框）都会在这些列中从左向右移动。最经典的列分为三档（团队可以根据需要增加）：

• To Do (待办)： 计划会上拆解出来的所有子任务，一开始全堆在这里。
• In Progress / Doing (进行中)： 程序员正在敲代码、或者正在画图的任务。
• To Verify / Testing (待验证/测试中)： 很多团队会加这一列。代码写完了，交由测试人员找 Bug，或者等待其他同事做代码审查（Code Review）。
• Done (已完成)： 任务彻底搞定，符合 DoD（完成的定义）。

跟踪进度——燃尽图

纵轴 (Y轴) —— 剩余工作量 (Estimated Work Remaining)：

• 图上的单位是“故事点 (Story Points)”，刻度从 0 到 70。
• 核心注意点： 纵轴代表的是“还没干完的活”，而不是“已经干完的活”。所以这条线必须是往下走的，降到 0 才算胜利。

横轴 (X轴) —— 时间 (Date)：

• 代表整个 Sprint 的时间跨度（图例是从 8月1日 到 8月19日）。细心看会发现中间有跳过的日期（比如 5号直接跳到 8号），那是因为排除了周末不干活的时间。

虚线 —— 理想基准线 (Ideal Line)：

• 图中那条笔直向下的灰色虚线。它代表了一种“完美且不现实”的假设：团队每天以绝对匀速的速度干活，没有 Bug、没有请假，最后一天准时做完。它是一根用来对比的“参考线”。

蓝色实线 —— 实际燃烧线 (Actual Line)：

• 这是团队每天根据实际做完的任务，在站会上实时更新画出来的曲线。

每日站会 Daily Scrum

• 不超过15min
• 回答三个问题
  • 昨天我做了什么
  • 今天准备干什么
  • 你遇到了什么障碍，需要其他人如何帮你
• 移动任务板上的即时贴到对应的地方
• 每日例会一结束就要计算剩余工作故事点并更新燃尽图
• 团队每日报到、简短、及时开始与结束、聚焦重点、有规律

另一种站会

• 关注事——而不是人
  • 不关注每个人做了或没做什么，而是关注整个工作流或者单个工作项的流动是否有什么问题
• 遍历看板墙
• 关注味道
  • 在软件工程里，“味道（Smell）”是一个专业术语（源自“代码坏味道 Code Smell”），在这里指的是“流程坏味道”。它意味着系统表面看起来在运转，但实际上散发着隐患的信号。
• 每日站会之后，鼓励自发改善会议

Sprint演示会议

为什么定义Sprint结束于演示

• 其他人可以了解你的团队在做什么
• 团队得到认可，团队成员感觉很好
• 不同的团队得到交流，讨论各自的工作
• 演示可以吸引相干人士的关注，并得到重要的反馈
• 演示会迫使团队真正完成一些工作而不是貌似完成，这样不会污染下一个Sprint

Sprint演示——检查列表

• 确保明确阐述Sprint目标
• 集中精力演示可以实际工作的代码
• 演示保持快节奏
• 演示我们做了什么而不是我们怎么做的
• 不演示细碎bug的修复和微不足道的特性

Sprint回顾会议

• Sprint回顾是仅次于Sprint计划的第二重要的事件
• 这是做出改进的最佳时期
• 主题：我们怎样才能在下个Sprint中做的更好，不是追究责任

活动列表

• 根据要讨论的内容范围，设定时间为1至3个小时
  • 参与者：产品负责人，整个团队还有我自己
  • 我们换到一个封闭的房间中，或者舒适的沙发角，或者屋顶平台等等类似的场所。只要能够在不受干扰的情况下讨论就好
  • 我们一般不会在团队房间中进行回顾，因为这往往会发散大家的注意力
  • 指定某人当秘书
• Scrum master向大家展示sprint backlog，在团队的帮助下对Sprint做总结。包括重要事件和决策等
• 轮流发言
• 对预估生产率和实际生产率进行比较，差异大就分析原因
• 快结束时，Scrum master对具体建议进行总结，得出下一个Sprint需要改进的地方

使用白板 白班内容包括

• Good：哪些做法可以保持
• Could have been better：那些做法需要改变
• Improvements：具体改进想法

估算

• 团队经常是错误的，但是估算过程仍然是有用的。它可以被当作风险管理的工具，可以发现误解不一致以及需要进一步调查地方
• 团队共同完成估算可以让大家建立对工作一致的理解
• 根据收益递减原理，不应在估算上花太多时间

估算单位 （storypoint）

• Story point：故事点 选取可识别的最小用例为2个story point，其它估算都是相对值，在所有sprint中保持相对值一致，这样可以在估算时缩小人与人的能力误差

• 估算速度时，估计能在一个迭代周期内能够完成的story point

另一种估算单位 T恤尺码

• 经常使用的序列是 S M L
• 如果工作项比L大，他们会把它拆分成大小为S、M和L的更小条目
  • 一个XL的条目会占用团队太多产能，也不便于管理
• 必要时可以使用XS和XL

估算过程

计划“扑克”估算法

1. 每个团队成员拿到一组卡片
2. 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问
3. 团队讨论这个条目
4. 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上
5. 阅读者向大家确认是否都已经确认估算结果，确认后，团队成员同时展示估算结果
6. 团队评估不同的估算结果，共同讨论估算的差异，最终达成一致，若差异不可接受，则返回3
7. 返回2，开始估算下一个条目

估算差异的原因

• 需求理解不同
• 技术不熟悉

扑克牌估算法价值

• 鼓励跨职能团队的多个团队成员参与估算，团队成员可以从不同的视角来思考和分析问题，估算的过程中考虑的更加全面、估算也更加准确
• 在估算的过程中，团队对估算的结果进行讨论和评判，在一个高度透明的环境下，估算的结果更加真实和客观
• 估算的过程也是一个知识分享和学习的过程，对某一个条目不清楚的成员通过其他成员的阐述会增加对该条目涉及到的要点的认识

另一种扑克估算法

1. 由一个领域专家向团队解释需求并回答问题，以确保大家都理解
2. 进入以下轮次，只有在没能达成一致时才进入下一轮次
   1. 大家用卡片独立投票，不要讨论
   2. 让人们思考一到两分钟，再进入下一轮独立投票，还是不要讨论
   3. 大家先解释一下自己为什么给出这样的投票，然后再次投票
   4. 如果没有达成一致，就暂时搁置，先进行下一个需求的估算

这个方法让你快速得到足够好的估计。如果能够达成一致，就不会对需求作详细的讨论了

卡片队列估算法

1. 把每个条目的描述写在单独的卡片上，这个应该再估算前就准备好
2. 把所有的卡片摞成一摞放在桌上
3. 拿出第一张卡片，放在旁边
4. 再拿出一张，问“这个比第一个大还是小？”为了回答这个问题，你可能需要和其他人讨论一下这个工作项事干什么的。这需要时间但别太长
5. 当你决定了它更大或更小后，把它放在原卡片的上方或下方，形成一列
6. 重复第4和第5步，直到用完所有的卡片
7. 现在你可以把所有的卡片分组了— 这也是该技术的第二阶段。从桌上底部(最小)的 卡片开始，声明第一组的估算是“小的”
8. 继续向上，决定到何时为止卡片已经变大到需要用一个新的估算值(如 “中等”)了， 让团队决定
9. 很快，你就可以把整列卡片再过一遍，并加总(5 个的估计是S, 4个 M ,等等) 以得到整个列的总和，这也就是需求的总工作量估计。从队列最下面的部分开始，第一部分可以被当做S

金发女孩估算技术

• 作为对工作项大小估计的替代，可以把工作项调整到合适的大小
• 你不再是指定每个工作项的大小，而是去分割或组合工作项，让它们的规模大致相当，并便于后续操作

减小故事规模

很多团队要求故事的大小再2-8个故事点，大于8要求拆分故事

故事和任务

• Story是可以交付的东西，Task是不可以交付的，Product Owner对Task不关心
  • task是功能被拆解形成的许多具体的工作步骤

Scrum局限 变更 优势

局限

• 没有技术实践
• Scrum关注项目管理和团队过程，而XP侧重工程实践和代码质量
• Scrum不包含技术实践，但如果没有XP实践的支撑，Scrum难以成功

Scrum Guide 2020核心变更与争议

• 改进
  • 团队结构简化：取消”开发团队“专属称谓，统称”开发者“
  • 目标体系强化：引入产品目标、冲刺目标、承诺性待办项三层目标架构
  • 仪式优化：每日站会取消固定三问，聚焦进度与障碍
  • 指导原则：删减50%内容，强调适应性和精简
• 主要争议
  • 角色职责模糊化争议
  • 仪式灵活性带来的执行差异
  • 精简版指南对新手支持不足

Scrum核心优势

• 轻量灵活
  • 仅定义必要规则，兼容多种实践
• 持续改进
  • 通过事件循环实现经验反馈
• 价值驱动
  • 以Product Goal为导向，确保交付有效性
• 协作透明
  • 跨角色协作，信息共享最大化

Scrum适用性

• 超越软件领域，适用于复杂创新工作

LeSS Large-Scale Scrum

• 仅在一个产品待办列表下扩展多个Scrum团队，尽量减少额外角色
• 核心理念是“Large-Scale Scrum is Scrum”，即大规模Scrum仍然是Scrum，不引入额外的复杂框架，而是通过扩展Scrum的基本原则和实践来适应团队环境
• Less提供了两种框架，分别适用于不同规模的团队
  • 基本LeSS（Basic LeSS）：适用于2-8个团队（每个团队通常5-9人），共同开发一个产品
  • LeSS Huge：适用8个以上团队，通常用于超大规模产品开发，可能设计数百甚至数千人

基本Less

• 一个产品负责人PO
  • 负责整个产品的愿景、优先级和Product Backlog。PO需要与所有团队密切合作，确保所有团队对产品目标的理解一致
• 多个Scrum团队
  • 每个团队遵循标准的Scrum实践，包括Sprint、Daily Scrum、Sprint Planning、Sprint Review和Retrospective。团队是跨职能的，能够独立交付功能
• 一个Product Backlog
  • 所有团队共享同一个产品待办事项列表，确保工作的透明性和一致性
• 一个Sprint
  • 所有团队在同一时间段内进行冲刺，目标是交付一个集成的、可发布的增量

AI对Scrum的冲击

角色冲击：从“跨职能团队到人-Agent混合团队”

• 传统：致力于创建每个Sprint可用Increment的人员
• Agent时代：从代码编写者到Agent编排者

Product Owner的挑战

• Product Backlog的粒度需重新校准——Agent可能在一天内完成原本需要数天的编码任务
• 用户故事的“可估算性“受到冲击：AI Agent产出质量方差大，Velocity预测更困难
• PO需要学会用”测试规格“而非仅用自然语言描述需求——TDD成为向Agent传达需求的精确语言

Scrum Master的新使命

• 从”移除障碍“到”管理人-Agent协作的流动性“
• 核心新职责：识别价值流中的瓶颈漂移（编码不再是瓶颈，评审变成了新瓶颈）
• 需要理解约束理论（TOC）：优化非瓶颈环节不会提高系统产出，只会增加在制品库存

事件冲击：Sprint节奏与仪式的适配压力

• 传统假设被打破：Sprint工作量之所以可预测，是因为人类产能相对稳定。Agent介入后，产能弹性剧增但方差也剧增
• 估算（Planning Poker 计划扑克）的困境：同一个Story，Agent可能2小时搞定，也可能因为反复返工耗费2天——Story Point的相对稳定性被动摇
• 建议适配：优先选取边界清晰、验收标准明确的Story交给Agent；保留模糊的、需要人类判断的Story由人类主导

Daily Scrum

• 传统三问仍然有效，但需要追加“Agent完成的产出中，什么已验证？什么待审核？”
• 关注焦点从“人的进度”扩展到“人——Agent协作流”的瓶颈——看板的“遍历看板墙、关注味道”再次更加适用
• 当“等待评审”列持续膨胀时，团队需要做出决策：暂停Agent的新任务or调配更多人力or启用AI辅助评审

Sprint Review/Demo

• 演示可以实际工作的代码这一原则不变——但需追问：团队是否真正理解这些代码
• 引入新概念：理解力负债——系统代码量与人类实际理解量之间不断扩大的差距
• AI生成代码的速度是开发者吸收速度的5-7倍。PR数量攀升，评审容量持平

Sprint Retrospective

• 回顾会增加新维度：Agent的使用效果如何？哪些类型的任务适合委托？哪些不适合
• 警惕“感知-现实鸿沟”：开发者主观感知的效率提升，与实际客观产出之间存在巨大反差——你以为AI让你变快了，实际上可能变慢了
• 回顾会是修正认知偏差、建立团队对Agent能力边界共识的关键场所

工件冲击：Backlog、DoD和Increment的重新定义

• Agent时代的用户故事可能需要更细的粒度——小批量工作变得更重要；让Agent每次提交小的、独立的、可验证的变更，而不是巨大的变更集
• INVEST原则的重新审视
  • Independent：Agent可以并行处理多个独立的Story
  • Negotiable：与Agent的“协商”变为精确的提示工程与测试规格定义
  • Valuable：不变
  • Estimate：因Agent产出方差大，估算难度上升
  • Small：在Agent 时代尤为重要
  • Testable：测试从“最佳实践”升级为“生存必需品”——TDD是Agent时代的“超能力”

DoD的扩展

• 传统DoD：代码完成+测试通过+代码已合并+文档补充+验收完成
• Agent时代DoD应追加
  • 人类已评审并理解AI生成代码的核心逻辑
  • 安全审查已通过（AI生成代码的安全风险需要显式检查）
  • 无“理解力负债”积累——至少一名团队成员能解释该代码的设计决策

Increment——质量的新风险

• PR数量、规模、bug率提高 PR评审时间增加
• 变更失败率上升
• 透明面临新挑战：AI生成的代码表面干净整洁，但“表面正确性 != 系统正确性”

Scrum三大支柱在Agent时代的重新锚定

• 透明
  • 新的透明需求：不仅是过程和工作成果对人可见，还包括——哪些代码由AI生成？Agent的决策依据是什么？团队对AI产出的理解程度如何？
  • 透明使检视成为可能——如果团队不知道哪些代码是AI写的、为什么这样写，检视就失去了基础
• 检视
  • 评审成为新的关键约束，解决路径
    • AI辅助评审
    • 小批量PR
    • 完成的定义中嵌入理解力验证
    • 代码平生不仅仅是质量关口，更是知识传递的核心机制——是防止“理解力负债”积累的最后防线
• 适应
  • Scrum的适应性在Agent时代尤为珍贵：经验主义本身就是应对AI不确定性的最佳框架
  • 关键适配方向
    • 看板的WIP（Work In Progress 在制品）限制引入Sprint管理：控制“待评审队列长度”
    • Sprint长度可能需要缩短（反馈周期更快，纠错成本更低）
    • 回顾会的“改进建议”中，增加“人-Agent协作模式”的持续优化

底层逻辑：为什么Scrum框架依然有效

• Scrum定义：“一个基于团队进行复杂系统和产品开发的框架”——Agent不改变“复杂系统”的本质
• Scrum的核心价值观是人类的价值观——AI Agent没有价值观，它需要被人类的价值观所约束和引导
• 经验主义的本质——“知识源自实际经验以及根据当前观察到的事物作出的判断”——在Agent产出充满不确定性的时代，比任何时候都更重要