Scrum 敏捷原则
可变形和不确定性
积极参用有帮助的可变性
采用迭代和增量开发
迭代开发：承认我们在把事情做对之前有可能做错，把事情做好之前有可能做坏。本身是一个有计划的修改策略。
增量开发：先构建部分，再构建整体。
Scrum 并不是每次做一个阶段的工作，而是每次做一个特性的工作。
通过检视、调整和透明来利用可变形
Scrum的核心原则是检视、调整和透明性。
维度 计划驱动 Scrum 过程定义的程度 一套明确定义的顺序 复杂过程无事时先制定的完整规则 产出物的随即程度 产出物可变形很小或者不存在 预计有变化，因为我们不是重复构建相同的东西 利用的反馈的数量 很少、很晚 频繁、尽早 Scrum依赖于透明性：参与创建产品的每一个人都有必要能够得到与WIP相关的所有重要信息。
信息透明 –> 检视 –> 调整
减少各种各样的不确定因素
- 结果不确定性（不确定做什么）：围绕最终产品特性的不确定性。
- 方法不确定性（不确定怎么做）：围绕产品的开发过程和技术的不确定性。
此外还包含客户的不确定性（不确定用户是谁）。
预测和适应
不到最后时刻，不轻易做决定
“最后责任时刻”原则（Last Responsible Moment，LRM）：不该单单因为通用过程要求此事作出决定，就做出不成熟的决定。而是“不轻易做决定”。推迟做出承诺，直到最后责任时刻再作出重要的、不可逆转的决定。
大多数人都倾向于等有更多信息之后再做出更明智的决定。
承担 无法一开始就把事情做对
实际上我们不可能事先就能以正确的方式得到所有需求，也不可能基于这些需求以正确方式得出详尽的计划。
在Scrum中，会预先产生需求和计划，但原则是够用就好，一旦了解更多在建产品的相关知识，就会填充需求和计划的细节
偏好适应性、探索式的方法
恰当运用探索式方法，在此基础上采用适应性的试错法。
- 探索：通过某些活动获得知识，例如构建原形、创建概念验证、实施研究或者进行试验。
快速构建少量内容并根据用户反馈进行调整，其成本往往低于实现投入精力试图一次性做对所有事情
用经济合理的方法接受变化？？？
目标：让变更成本曲线长期保持稳定。
通过WIP数量和工作流进行管理来实现。如何实现（具体方式）？
Scrum中 很多工作产品（例如详细需求、设计和测试用例）都是以刚好及时的方式产生的，以避免创建非必要的工件。
在预测型事前工作和适应型刚好及时的工作之间做出平衡
推动平衡的因素：
- 所构建的产品的类型
- 待建产品（结果的不确定性）
- 产品构建方式（方法不确定性）
- 开发中的限制
- 符合法律/监管的要求
一方面要调整，一方面也要通过刚好够的预测来取得平衡，以免陷入混乱。
经验认知
快速验证重要的假设
假设：即使某些猜测或看法并没有被之前验证过的认知确认，也认为它是正确、真实或可靠的。
假设本身就意味着重大的开发风险。
在Scrum中，任何时候的重要假设都要力求最少。
利用多个认知循环并行的优势
顺序开发方式是在特性工作快结束时（经过构建、集成、测试后）获得认知。此时，可能已经“没有足够时间利用认知”或者“利用认知的成本太高”。
利用反馈循环来提高认知。
Scrum的几种认知循环：
- 结对编程：秒级反馈。
- 测试驱动开发：分钟级反馈。
- 每日例会：每日循环。
- 冲刺评审活动：迭代级的循环。
妥善组织工作流程已获得快速反馈
计划驱动开发的问题：“我们可以同时开发一堆组件，等到后期集成阶段再顺利组装成一个紧密结合的整体”，这种想法几乎不可能实现。即便在开发组建之前定义有精心构思的接口，在集成时也有可能出错。
通过组织好工作流，在认知循环中移动，尽快获取反馈。
WIP （work in process）
WIP：表示已经开始但尚未结束的工作清单。
批量大小要经济合理
传统的计划驱动的顺序开发过程核心理念：倾向于将相同的类型的工作分批汇集到一个独立阶段中执行。又称为“整体推进”。该理念来源于传统制造业的规模经济原则：认为单件产品的成本会随着生产数量的增加而降低。
单件流程：批量大小为1，一次只处理一个需求，做完所有活动后准备交付给客户。但该模式充其量也只是局部优势。
小批量的优势 |优势|描述| |–|–| |减少周期时间|批量较小时，等待处理的工作也比较少，意味着等待时间不会太长。工作完成得更快| |减少工作的变动|想象一下，一个餐馆，顾客零散地进进出出（在餐馆里良好流动）。此时从一辆大新观光巴士走西来一大批顾客（大批量），对餐馆中的人流有什么影响？| |加速反馈|小批量有利于加快快速反馈，能够最小化错误影响| |减少风险|小批量意味着受变更影响的库存更少。小批量失败的可能性也更小| |降低管理成本|大批量工作有管理成本| |积极性和紧迫性提高|小批量能够让人更加专注，更有责任感。与大批量相比，在处理小批量时，更容易理解拖延和失败的后果| |降低成本，减少计划延期|如果在使用大批量时出错，成本和时间安排上都会出现大范围的错误。使用小批量工作，则不会错的太离谱。|
识别并管理库存以达到良好的流动
库存：也称为WIP，“流程中的产品、“半成品”、“在制品”。
软件开发企业
Scrum的目标是合理地平衡适量库存和过多库存之间的关系。
关注闲置工作，而非闲置人员
需要找出工作流的瓶颈并集中精力消除它，而不是努力让每个人都100%连轴转。
考虑延期成本
延期成本：工作延期或里程碑延期达到所生产的财务成本。
进度
根据实时信息来重新制定计划
“盲目计划”！
“计划可能有错”！
目标：快速地重新制定计划并根据开发程度中不断出现的、具有重要经济价值的信息进行调整。
通过验证工作结果来度量进度
计划驱动地顺序开发方式，进度的表现方式：完成一个阶段之后才可以允许进入下一个阶段。
Scrum中，通过构建可工作、可验证地成果 来 度量进度。
聚焦于以价值为中心的交付
Scrum是以客户价值为中心地开发方式，基于优先级排序的“增量交付模型”
执行
快速前进，但不匆忙
Scrum的核心目标是灵活、适应、快速。
Scrum的可持续节奏的原则：人们应该以长期稳定的节奏工作。
要快，但不要匆忙。
以质量为魂
Scrum中，质量并不是测试团队在最后阶段“测”出来的，而是由跨职能的Scrum团队负责并持续内建于每个冲刺中。
采用最小够用的仪式
Scrum中，目标是消除可有可无的繁文缛节。设定一个较低的标准，也就是“基本够用”。
以下情况可能需要写文档：
- 文档要作为产品的交付的一部分（安装文档、用户指南等）。
- 我们的目标是保存重要的讨论、决议和协议，以便大家今后能清除想起讨论过的内容、决议或协议。
- 文档是有价值的，可以版主新的团队成员迅速跟进。
- 监管要求提供文档（在受监管行业开展业务就有这个成本）。
总结
| 主题 | 计划驱动原则 | 敏捷原则 |
|---|---|---|
| 开发和制造的相似性 | 二者都遵循既定规则 | 开发工作不是制造业，它是为产品创造方法 |
| 过程的结构 | 开发是基于阶段的、顺序的 | 开发应该是迭代和增量的 |
| 过程和产品的可变程度 | 尝试消除流程和产品的可变性 | 通过检视、调整和透明来驾驭可变性 |
| 不确定性管理 | 先消除结果的不确定性，再消除方法的不确定性 | 同时减少各种不确定性 |
| 决策 | 在合适的阶段做出相应的决策 | 不轻易决定 |
| 第一次就做对 | 假设我们事先就能拥有创建需求和计划所需的所有正确信息 | 事先无法做对 |
| 探索和开发 | 利用目前已知的，预测未知的 | 偏好适应式的，探索式的方法 |
| 变更（涌现） | 变更会破坏计划且成本高昂，应避免 | 用经济合理的方法积极接受变更 |
| 预测式对比适应性 | 过程是高度预测式的 | 平衡预测性工作的实现工作和适应性的刚好及时的工作之间的关系 |
| 假定（未经验证的知识） | 此过程容忍假设长期不被验证 | 快速验证重要的假设 |
| 反馈 | 关键认知发生在一个“分析-设计-编码-测试”大循环中 | 利用多个认知循环并发的优势 |
| 快速反馈 | 此过程容忍较晚获得认知 | 妥善组织工作流以获得快速反馈 |
| 批量大小（在下一个活动可以开始之前有多少工作完成了） | 批量较大，通常是100%–大批量分阶段整体推进。规模经济适用 | 使用较小的、经济合理的批量大小 |
| 库存或WIP | 这个体系的理念中没有考虑库存，所以不是重点 | 意识到并妥善管理库存已达到较好的流动 |
| 人员浪费和工作浪费 | 分配人员，达到更高级别的利用率 | 关注闲置工作而非闲置人员 |
| 延期成本 | 几乎不考虑延期成本 | 总是考虑延期成本 |
| 遵循计划 | 认为遵从计划是得到好结果的主要方法 | 调整并重新制定计划，而不是遵从计划 |
| 进度 | 通过阶段进展情况展示进度 | 通过验证工作成果衡量进度 |
| 中心性 | 过程为中心–遵循过程 | 价值为中心–交付价值 |
| 速度 | 遵循流程，把事情一次做对并快速前进 | 快速前进，但不匆忙 |
| 什么时候会有高质量 | 经过全面的测试–修复阶段后，最后得到质量 | 从一开始就以质量为魂 |
| 仪式化 | 仪式（定义良好的过程和检查点）对于有效的执行很重要 | 采用最小够用的仪式 |