敏捷宣言、原则及SCRUM敏捷实践

1. 敏捷的基本方法论

1.1 为什么选择敏捷

传统项目管理应对快速变化项目的挑战

• 繁重的计划和文件
• 被隔离的隐形项目团队（传统项目管理中，各个角色、项目团队和客户之间有特定的沟通渠道，敏捷强调建立更多的联系，让人起到更重要的作用）
• 无法适应快速变化和实际情况

选择敏捷的原因：

• 灵活性
• 更快的交付价值
• 持续改进
• 更低风险

敏思维模式由价值观定义，以原则为指导，并在许多不同的实践中体现。敏捷实践者根据自身需求选择不同的实践。

1.2 Stacy 斯泰西图

敏捷强调适应型，但需要明确，敏捷中不确定的更多是具体实现方法，但目标是明确的，如果目标和方法都不明确，这就不是项目。

工作类型	范围	计划	交付	团队成员
确定型	前期确定，不易变更	按计划进行	一次交付	执行为主
不确定型	难以事先确定	计划赶不上变化	多次交付	动手又动脑

2. 敏捷宣言

我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始更重视：
个体以及互动 胜于 流程和工具 —> 以人为本
工作的软件 胜于 完整的文档 —> 以价值为导向
客户合作 胜于 合同谈判 —> 合作共赢
应对变更 胜于 遵循计划 —> 拥抱变化
也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。

2.1 个体和互动胜于流程和工具

• 流程和工具在项目中是重要的，但它们是“死”的
• 参与项目的人是“活”的
• 过程和工具需要合适的人来运用，才能产生价值
• 个体和互动是项目获得成功的最为重要的因素
• 团队成员不能面对面时，可以使用远程工具，但不能替代面对面

2.2 工作的软件胜于详尽的文档

成功的敏捷项目，重要的是双方有足够的互信，文档很多时候都是因为要“扯皮”

• 过多的面面俱到的文档，有时候比过少的文档更糟
• 需求变化快，前期花太多时间在细节上，是浪费
• 文档应尽量短小并且主题突出
• 可工作的软件是项目的最终量化结果

2.3 客户合作胜于合同谈判

跟客户要合作共赢，不能有对抗的思想，成功的商业模式不是零和游戏。双方是一体两面的，双方一起努力把“饼"做大后分饼（分润增量的好处），而不是把客户的口袋掏空

• 谈判形成的合同往往是固化、死板的条文
• 客户很难做到一次性将需求完整清晰的表述在合同中
• 有利于引导协同工作的合同才是好合同
• 让客户专注于商业决策
• 客户和开发团队形成合作伙伴
• 客户定义价值

2.4 拥抱变化胜于遵循计划

需要留意，敏捷项目通常没有严格的边界。敏捷中最重要的事情是优先级排序后拥抱变化

• 唯一的不变就是变化，初始计划总是不足的
• 可以更多精力处理项目组不可避免的”变化”
• 短期迭代的机会比中长期计划更有效
• 探索性项目强调展望并基于愿景进行探索，而不是详细计划和严格执行任务
• 低成本迭代使开发具有适应性，计划、架构和设计与实际产品不断演进。

3. SCRUM敏捷实践

3.1 敏捷（适应型）和瀑布（预测型）项目中人的区别

类型	角色	特点
预测型	项目经理（PM）	主导者（强）
预测型	团队成员	执行者（弱）
适应型	敏捷教练（SM）	辅助者（弱）
适应型	团队成员	自组织（强）
适应型	产品负责人（PO）	客户代言人、掌舵者、验收者

3.2 Scrum框架中的33355

三个支柱	三个角色	三个工件	五个事件	五大价值观
透明性（transparency）	产品负责人（Product Owner）	产品待办事项列表（Product Backlog）	冲刺/迭代（Sprint）	承诺（Commitment）—愿意对目标做出承诺
检查（Inspection）	敏捷教练（Scrum Master）	迭代待办事项列表（Sprint Backlog）	迭代规划会议（Sprint Planning）	专注（Focus）—全身心都用到承诺的工作中去
适应（Adaptation）	项目团队（Scrum Team）	可交付产品增量（Increment）	每日站会（Daily Scrum）	开放（Openness）—团队内所有信息对所有人开放
			迭代评审会议（Sprint Review）	尊重（Respect）—每个人都有他独特的价值和经验
			迭代回顾会议（Sprint Retrospective）	勇气（Courage）—用于承诺，履行承诺，敢于说不

3.3 三个支柱

3.3.1 透明性（transparency）

过程中的关键环节对相关人是显而易见的，同时保证干系人对这些关键环节理解是统一的。

3.3.2 检查（Inspection）

Scrum使用者必须经常检视Scrum的工件和完成Sprint目标的进展，检视频率应适宜。确保能够及时发现过程中的重大偏差

3.3.3 适应（Adaptation）

如果检视发现一个或多个方向偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整，调整工作必须尽快执行，如此才能减少进一步的偏离。

3.4 三个角色

角色	职能
产品负责人	指导产品的开发方向；创建、维护产品待办事项列表。根据商业价值排序任务，提供反馈
产品负责人	确保遵循敏捷流程，引导、指导团队，为团队消除障碍
产品负责人	通才型专家，拥有各种必要技能，以常规节奏交付潜在可发布产品，核心职责是在短时间内交付任务

3.4.1 产品负责人（Product Owner，PO）

代言人 掌舵者 验收者
PO的工作聚焦于产品、聚焦于创造价值，如果PO工作偏离了职能，SM需要及时纠偏

• 产品负责人负责指导产品的开发方向
• 产品负责人跟进商业价值对任务进行排序。产品负责人与团队开展日常合作，提供产品反馈，为将要开发/交付的下一个功能设定方向
• 产品负责人与相关方、客户及团队合作，定义产品开发方向。
• 敏捷开发中，产品负责人将为团队创建待办事项列表，或者与团队共同创建。待办事项列表帮助团队了解怎样在不产生浪费的情况下交付最大的价值。主要负责确定产品的功能和达到要求的标准，维护产品待办事项列表，指定软件交付的内容，同时有权利接受或拒绝开发团队的工作成果。
• 产品负责人的要求：产品负责人拥有相关工作背景，会为决策提供丰富的专业知识技能。有时，产品负责人需要请求有关人员提供帮助，如具有丰富的专业领域知识的架构师或具有丰富客户经验的产品经理。

3.4.2 敏捷教练（Scrum master，SM）—仆人式领导

仆人式领导为团队赋权

定义：一种为团队赋权的方法。通过对团队服务来领导团队的实践，注重理解和关注团队成员的需要和发展，旨在使团队尽可能达到最高绩效。

作用：促使团队发现和定义敏捷，仆人式领导实践并传播敏捷

职责：

• 促进作用：工作重点从“管理协调”转向促进合作“。促进个人参与，促进团队内部和团队之间的合作与对话。仆人式领导是通过成为公正的搭桥者和教练做到的，而不是代替其他责任人做出决策。------- 只作为促进者，不做主，不决策
• 消除组织障碍：教育相关方，将团队从详尽的文档、冗长的过程、频繁的打扰、跨部门工作、行政任务等问题中解放出来。-------保护团队不受打扰
• 为他人贡献铺路：通过技术项目管理活动 （敏捷原则及实践），提供培训或者支持性工作。

定义目标	鼓励人员	开展过程
与团队一起定义目的，以便他们能围绕项目目标进行合作互动	鼓励团队创造一个人人都能成功的环境，要求每个团队成员在项目工作中做出贡献	**不要计划遵循“完美”**的敏捷过程，而是要注重结果

特征：提升自我意识，倾听，为团队服务，帮助他人成长，引导与控制，促进安全、尊重与信任，促进他人精力与才智提升。

3.4.3 项目团队（Scrum Team， ST）—自组织团队

	说明
团队特点	被授权、自组织；强烈的产品责任感，价值驱动导向，鼓励建设性对抗，作为一个独立团队，聚焦绩效，交付价值、自主决策、自主承担
团队构成	团队规模3-9人（两个披萨原则，人数过多可以拆分团队，PO、SM不包含在人数中，除非参加执行冲刺列表中的工作）；通才型专家，T型人才（敏捷团队是跨职能的，鼓励成员成为通才），100%专职成员（多任务带来切换成本。并非所有人都要求专职，如临时专家）
团队环境	团队获得授权，自组织和管理他们的工作。责任属于整个开发团队。首选集中办公，通过透明沟通（渗透式），知识共享（团队培训，推崇先内后外）、致力于相互合作

3.5 三个工件

3.5.1 产品待办事项列表Product Backlog

• 产品待办事项列表是所有工作的有序列表，它以故事的形式呈现给团队，价值越大的排在上面
• 产品待办事项列表是以价值为核心的排了序的需求池
• 产品负责人Product Owner 制作一个产品路线图，以显示预期的可交付成果序列。产品负责人根据团队的实际成果重新规划路线图
• ** 产品负责人PO在迭代规划会议中与团队合作，为即将进行的迭代准备故事，细化足够的故事**
• 向团队介绍故事创意、潜在的挑战或问题。如不确定依赖关系，请求团队对相应功能进行刺探，以了解风险。
• 团队每周用不超过1小时的时间来为下一批工作细化故事。团队希望把时间尽可能花在工作上，而不是计划上。

产品待办事项列表的变化场景：

• 细化待办
• 上期遗留
• 新增事项 ------ PB的排序由PO负责，但团队可以往里面增加需求
• 优先插队
• 删除事项
• 办成增量

DEEP模型：

• 详略适宜的（Detailed Appropriately）
• 可估计的（Estimable）
• 涌现式的（Emergent）
• 排好优先级的（Prioritized）

3.5.2 迭代待办事项列表

• 定义了Sprint迭代的目标，明确了Sprint过程中具体需要完成的任务
• 尽量放在方便团队看到的地方
• 任务不是分配下去的，而是团队讨论与个人挑选的结果（自管理）
• 对每一个任务，每天更新剩余任务工作量的估算（迭代燃尽图）
• Sprint规划会议产出迭代待办事项列表SprintBacklog
• 是团队的资产，团队可以增加、删除或者修改任务
• 如果团队同意，对一些事项，可以先做大的整体估算，在Sprint进行当中再分解成任务
• 在Sprint开始后，Sprint列表一般不改变，但是如果“用户故事已经显然无效”也应该删除

3.5.3 可交付产品增量

• 可交付产品增量是一次迭代中实际已经完成已验收的用户故事
• 可交付产品增量交付价值

3.6 五个事件

迭代规划会议确定本次迭代要做什么，每日迭代会议交流日常工作信息，迭代评审会议对冲刺结果进行评审并展望项目的后续方向（区分规划会议），迭代回顾会议对过程、冲突问题、工具进行检视。

迭代周期	6周	4周	2周	1周
产品待办列表梳理会议（Release Planning）可选	12h	8h	4h	2h
迭代规划会议（Sprint Planning）	12h	8h	4h	2h
每日站会（Daily Scrum）	15min	15min	15min	15min
迭代评审会议（Sprint Review）	6h	4h	2h	1h
迭代回顾会议（Sprint Retrospective）	6h	2h	2h	1h

3.6.1 冲刺/迭代（Sprint）

• 迭代时间盒应该和团队能力、项目特征协调一致。通常为2-4周。
• 迭代时间盒一旦确定不会随意调整

3.6.2 迭代规划会议（Sprint Planning）

• 为即将要开展的Sprint制定计划，确定迭代目标
• Sprint第一天进行，控制在8小时以内（每周迭代时长对应约2h会议时间）
• 定义本sprint要交付的内容如何完成
• 相关方可以通过参加迭代规划会议了解团队情况和产品情况，主角是团队成员，其他相关方可以参与
• 会议基本内容：
  • 一般由PO来讲解产品待办事项列表（Product Backlog），并细化故事，团队来进行评估，得出迭代待办事项列表（Sprint Backlog）
  • 将用户故事拆分成任务（task）以估算时间
  • 团队成员领取任务（task）
  • 更新sprint待办列表

3.6.3 每日站会（Daily Scrum）

• 注意时间盒，一般不超过15分钟；（人数过多可稍微延长，或划分团队）
• 团队以某种方式“过一下”看板或任务板。---------团队为主角，其他角色可以参加，但不发言
• 团队中任何人都可以主持站会
• 站会是为了同步信息，发现问题，不提倡在站会上解决问题
• 每个人轮流回答问题：
  • 上次站会以来我都完成了什么？
  • 从现在到下次站会，我计划完成什么？
  • 我的障碍（风险或问题）是什么？
• 两种反模式：变成状态报告；变成问题解决会议。---- 注意，站会中可以澄清问题
• 每日站会是支持敏捷原则的重要基石之一，不可随意取消

3.6.4 迭代评审会议（Sprint Review）

• 发生在Sprint结束时，一般控制在4小时以内（以月迭代为例，半月迭代则为2h）
• 参会者包括Scrum团队和产品负责人PO及其邀请的主要利益相关者。
• 主要会议内容：
  • 产品负责人说明哪些产品待办列表项已经**“完成”和那些没有“完成”**
  • 开发团队讨论在Sprint期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决的。
  • 开发团队演示”完成“的工作并解答关于所交付增量的问题，获得相关方验收通过
  • 未完成或未通过评审的用户故事，重新放回产品待办事项列表，在下一次迭代规划会议评价
  • 参会的所有人就下一步的工作进行探讨，为接下来的Sprint规划会议提供有价值的输入信息
  • 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变；同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

3.6.5 迭代回顾会议（Sprint Retrospective）

• Sprint回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。
• 回顾会议发生在Sprint评审会议结束后，下个Sprint规划会议之前
• 对于长度为一个月的Sprint来说，回顾会议时间最长不超过3小时，对于较短的Sprint来说，会议时间通常会缩短。Scrum Master教导大家遵守时间盒的规则
• Scrum Master要确保会议举行，并且每个参会者都明白会议的目的
  • 一般是团队成员、敏捷教练参加，PO视情况参加，相关方受邀参与
• Scrum Master确保会议是积极的和富有成效的。Scrum Master对Scrum过程负责，作为团队的一员参加该会议。
• Sprint回顾会议的目的在于：
  • 检视前一个Sprint中关于人、关系、过程和工具 的情况如何；
  • 找出并加以排序做得好的和潜在需要改进的主要方面；同时制定改进Scrum团队工作方式的计划

3.7 五大价值观

承诺（Commitment）—愿意对目标做出承诺
专注（Focus）—全身心都用到承诺的工作中去，要求全职，专注于本项目
开放（Openness）—团队内所有信息对所有人开放
尊重（Respect）—每个人都有他独特的价值和经验
勇气（Courage）—用于承诺，履行承诺，敢于说不

4. 敏捷项目管理阶段框架

• 构想（Envision）：确定产品愿景、项目目标和探索边界、项目社团以及团队如何共同工作；
• 推测（Speculate）：制定基于功能或特性的发布计划和产品待办事项列表，确保交付愿景
• 探索（Explore ）：在短迭代内计划和交付经过测试的故事，不断致力于减少项目风险和不确定性
• 适应（Adapt）：评审交付的结果、当前情况和团队的绩效，必要时做出调整。
• 结束（Close）：终止项目，交流主要的学习成果，并进行庆祝。
  

4.1 构想阶段实践

4.1.1 产品愿景盒

愿景是洋葱圈首层，是制定计划的基础
产品愿景通过产品愿景盒、电梯测试获取，记录在项目章程中。颗粒度是大的、粗略的、高层级的

4.1.2 电梯测试（Elevator Test）

关于产品定位、目标客户、关键收益和竞争优势的简短声明：
通用模板：

我有一个绝妙的想法，我觉得应该：
For（目标客户） ------- 大部分的职场人士
Who（需求及机会） --------想学习提升但没有整块时间学习的问题
The（产品名称） is a (产品类别）---------xx软件，属于知识服务平台
That（关键价值收益，解释购买原因）----------通过碎片化时间，用更合适的方式，学习到筛选出来的高价值内容
Unlike（主要可选择的竞品）---------慕课
Our product(差异）---------基于移动互联网场景，用听的形式，xxx的个人IP为内容品质背书
我认为该产品一旦实现了，一定会大受市场欢迎！

4.1.3 项目章程

• 我们为什么要做这个项目？
• 谁会从中受益？如何受益？
• 对此项目而言，达到哪些条件才意味着项目完成？（愿景及产品路线图）----敏捷的项目章程包含愿景
• 我们将怎样合作？

4.1.4 团队章程

和预测中的团队章程差不多，只不过更强调团队自组织达成，是创造良好氛围的基础。
团队章程是团队需共同遵守的行为准则，是团队社会契约，为提供指导原则、规则并指导团队成员行为的方针政策，包括：

• 团队价值观：如可持续的步调和工作时间
• 工作协议：如就绪的定义（DoR，Definiton of Ready），完成的定义（DoD，Definition of done），时间和的期望，工作流的限制。
• 基本准则：如一个人如何在会上发言
• 团队规范：团队如何对待会议时间

4.1.5 精益画布（一页纸可视化商业计划书）

4.2 推测阶段实践

4.2.1 产品需求规划

4.2.1.1 敏捷洋葱圈

滚动式规划，渐进明细，走一步看一步
各层级颗粒度辨析，外两层叫可能性，内三层叫可行性

4.2.1.2 产品路线图（Product Roadmap）（年）

可能性而非可行性

4.2.1.3 用户旅程地图（User Journey Map）

把用户的需求按照使用逻辑列出来，通常是一些史诗级的需求，然后树状细分

4.2.1.4 用户故事地图（User Story Mapping）

用户故事地图中的内容，汇总到一个表里就是产品待办事项列表
最小可行产品MVP（Minimum Viable Product）:区别原型法，原型法只是用来收集需求，不能使用，MVP是真正可用的
特性Feature：对客户有用和有价值的特性
最小可售功能MMF（Minimum Marketable Product）：可以为客户提供价值的，足够小且足够足够完整的功能包。
敏捷项目都是先做MVP，然后逐渐叠加MMF迭代

4.2.1.5 敏捷发布规划

迭代0，可能不真正产出一些软件，在这个迭代里为后续迭代做准备，如部署、调试环境等。

4.2.1.6 时间盒

时间盒：固定的一段相对比较段的时间，计划的工作要在这段时间内完成，可以帮助团队专注项目对抗帕金森定律
优点：高度关注价值
缺点：可能导致“半成品”

时间盒越短，越频繁达成小的目标，给外部干系人建立信息
时间盒越短，反馈频率越频繁，能越早获得反馈，降低复杂度

4.2.2 用户故事

4.2.2.1 用户画像（Personal）

用户画像的核心工作就是给用户打标签，标签通常是人为规定的高度精炼的特征标识，如年龄、性别、地域、兴趣等。这些标签集合就能抽象出一个用户的信息全貌。
用户画像的构建一般可以分为目标分析、体系构建、画像建立三步。

4.2.2.2 创造场景和人物

• 什么是场景？
• 什么时间（when）
  • 什么地点（where）
  • 周围出现了什么事物时（with what）
  • 什么用户（who）萌发了某种欲望（desire）
  • 会想到某种手段（method）来满足欲望
• 什么时人物？
  • 人物：虚拟人物或身份，用来模拟与系统交互，以便收集需求。
  • 极端人物：极其夸张的人物，目的是引发一般人可能考虑不到的需求

4.2.2.3 用户故事卡片

史诗故事Epic Story：一个功能集或是一个大的用户故事
主题故事Theme Story：介于用户故事和史诗故事之间颗粒度的故事
用户故事User Story：简短的用户需求，足够小以适合迭代中完成
任务Task：完成用户故事过程性的工作
子任务Subtask：子任务通常是故事或任务的具体拆分，由单人承接，而且通常能在短时间内完成

用户故事的3C原则：Card（卡片），Conversation（交谈，有协商空间），Confirmation（确认，DoD）

• 卡片正面：作为xx，我想xx，以便于xx
• 卡片反面：DoD（Definition of Done）：已完成的定义（验收标准），最迟在迭代规划会议确认出来。由PO确定。
  • Given（在什么样的情境或条件下）
  • When（做了什么操作，采取了什么行动）
  • Then（得到了什么结果）

4.2.2.4 用户故事的INVEST原则

• Independent：独立的
• Negotiable：可协商的
• Valuable：有价值的
• Estimable：可估计的
• Small：小的
• Testable：可测试的

4.2.2.5 理想时间&故事点

常见的度量故事大小的方法为故事点和理想时间方法。理想时间是一个参考，敏捷主要以故事点为主。

• 理想时间：理想情况下，剔除所谓外围干扰因素后需要的时间。理想时间可以用来预测实际耗时，且更容易估算。但精确估算成本很高，对于拥抱变化的敏捷项目来说，没必要，也是浪费。进行理想人天估算时的假设：
  • 所估算的故事是要处理的唯一工作
  • 处理这个故事所需一切外部条件在开始工作时都已经准备好了
  • 处理这个故事过程中不会被打断
• 故事点：用于表达用户故事、特性或其他工作的总体大小的度量单位，一般情况下反应了一个故事的相对大小，可简单看成工作量大小。当风险、不确定性、复杂度、未知因素以及其他相关的事会影响工作量时，也应被包含进去考虑。
  • 故事点估算是一种相对估算（有一个参照系），而不是绝对估算（可以具体到几小时之类的）
  • 故事点估算需要事先选择一个参照故事作为其他故事估算的参照依据：
    • 选择一个系统内最小的故事，设定其为1个故事点
    • 选择一个中等规模故事，给它分配一个中间点数，如5点
    • 然后参考它来估算剩余故事点
  • 故事点估算方式：
    • 比较用户故事的规模、复杂程度、不确定性。
    • 但不适合跨团队比较（选取的参照系不一致，能力不一致）

4.2.2.6 用户故事估算

敏捷项目是拆分故事颗粒度，团队一起用故事点进行估算
估算时，团队成员经验最重要，有过故事开发经验的团队成员意见最重要

• 计划扑克：每人10张数字牌，每个人选一张牌，代表自己对这个故事所花费的成本的估算。这个时间点选择的卡片不能给他人看，所有参与者同时展示自己的卡片。团队一起来讨论这些估计值，尤其对异常值（最高和最低）着重讨论，最后选择连续几轮的估算（多轮达成一致）
• 宽带德尔菲：一种团队共同参与的估算方法，一群专家匿名提交估算结果，避免产生“光环效应”，一般会进行多轮，直到达成共识。
• 相对规模估算：通过规模的相对大小来估算故事工作量
• 亲和估算：快速估计大规模需求未完项的一种技术，利用衬衫尺寸，咖啡杯尺寸或斐波那契数列中的数字将用户故事快速置于规模类似的群组中。

4.2.2.6 用户故事优先级排序

不要把故事点的大小和优先级高低混为一谈，故事点大，优先级不一定高

用户故事优先级排序，以价值为核心。主要考虑价值，结合风险、依赖关系、政治等因素确定是否将其分配到迭代计划中。不同因素的重要性在整个项目周期也有所不同。

• MoSCoW：

  • Must：必须做的，不做不行，通常就是最小可行产品（MVP）
  • Should：应该有的，应该做。有些功能很重要，但不是必须的。
  • Could：可以做的，这些需求是客户期望的，但优先级不高的
  • Would not：可以不做的，在当下是不适合的要求。

• 卡诺模型(KANO)：分析用户需求对用户满意的影响为基础，体现产品性能和用户满意度之间的非线性关系

  • 魅力型需求
  • 期望型需求
  • 无差异需求
  • 基本性需求
  • 反向需求
  • 基本型>期望型>魅力型> 无差异> 反向
    

• 风险四象限：敏捷团队维护工作项的一个有序列表，把最高风险的项放在这个列表最上面，使他们最先得到处理，这种实践叫已调整风险的待办列表 （高风险高价值> 低风险高价值> 低风险低价值> 高风险低价值）
  

• 举手表决法（Fist to five），也成为五指法，可以应用于一些团队决议，帮助达成一致意见。

  • 举拳头Fist，表示不支持
  • 1根手指，表示非常担心
  • 2根手指，表示我想讨论一些小问题
  • 3根手指，表示我不完全认同，但可以接受其通过，不需要进一步讨论
  • 4根手指，表示我认为想法不错，且愿意为其工作
  • 5根手指，表示想法棒极了，执行时我愿意带头
  • 伸出三个以下手指的团队成员，有机会与团队讨论其反对意见。
  • 项目经理会不断举行举手表决，直到团队达成共识（所有人都伸出三个以上手指）或同意进入下一个决定。

4.2.3 风险

• 风险是一个不确定的事件，一旦发生可能会影响到项目
• 在敏捷中，消极的风险等同于反价值（Anti-value）。价值是存钱，风险是花钱。如果风险发生了， 就需要花费时间和资源应对，同时也会威胁到项目的利益。
• 敏捷是业务价值与风险驱动的组合
• 尽早规划风险规避以及转移的举措。敏捷项目不断进行迭代，在前期进行高风险处理，让高风险早曝光，这样，风险的应对成本相对较低，也降低了在之后阶段无效工作投入的可能性。
• 基于风险的小试验是风险管理的一个技能，叫刺探Spike。
  

4.2.4 刺探/探针（Spike）

刺探是一种技术尝试，分配一个很短的时间盒尝试性探索，快速试错。可以明确新技术在新环境下的可行性，以降低风险。

团队研究某个问题而进行的快速的概念验证活动，常用来测试陌生的或全新的技术。在深入采用这种技术之前，刺探的结果能够避免陷入太深。

刺探是对风险或潜在问题进行探索性工作，探索新技术、新方法、新问题、不清楚的风险
面对客户需求不知如何下手时，可以刺探一下分析客户需求

4.3 探索阶段实践

照着计划做事情

4.4 适应阶段实践

4.4.1 敏捷中的挣值

• 敏捷挣值只在迭代中使用
• 在敏捷中的挣值是基于已完成的功能
• 迭代中计划完成30个故事点，但只完成了25个，SPI是25/30=0.83
• CPI是已完成的功能值除以实际成本，2.2M/2.8M=0.79

4.4.2 速度控制

• 速度是迭代之后的实际情况，而不是目标，预测相反。最好的结果是稳定而不是越高越好。
• 速度，即本次迭代中实际完成功能的故事点大小的总和，让团队得以通过观察历史表现来更准确的规划下阶段的能力。
• 速度是对每一迭代完成的用户故事点或故事数量的衡量
• 只有用户故事完成了，计算速度时才会计入其故事点。没完成的故事即使只差1%，也不计入速度

敏捷中对速度的监控：

• 敏捷倾向于使用基于经验和价值的衡量指标，而不是预测型衡量指标，敏捷衡量团队所交付的成果
• 在敏捷中，团队的估算最多限于未来几周。未来几周团队工作的可变性不高，团队成员专注于任务，则团队的能力就会变得稳定。
• 完成一轮迭代后，团队就可以进行重新规划。
• 敏捷并不能创造更多的工作能力，然而，有证据表明，工作越少（WIP），人员就越可能交付。-----限制在制品数量
• 在不同的敏捷团队中横向比较速度是不明智的，因为项目内容不同，人员组成不同，面对的环境也不同。
• 最好的结果应该使速度达到稳定持续

4.4.3 回顾

原则12： 团队要定期反省如何能够做到有效，并相应调整团队行为；

回顾能让团队学习、改进和调整其过程。
回顾不是责备，而是指向未来，让团队从以前的工作中学习并作出小的改进。
回顾针对定性的（人的感觉）和定量的（衡量指标）数据，利用这些数据找到根源，设计对策，并制定行动计划。采取行动事项消除障碍。

4.5 结束阶段实践

5. 其他敏捷实践

5.1 精益Lean

精益思想就是花最少的钱，办最好的事，核心是消除浪费

• 浪费3M：不均衡（Mura）、超负荷（Muri）、浪费（Muda）
• 精益七种浪费：运输、等待、动作、缺陷、库存、过量生产、过度加工
• 精益七大核心理念：
  • 消除浪费：要想获得最大化的价值，必须将浪费最小化。延期、没有用的功能、等待都是一种软件浪费。
  • 强化学习：通过尽早沟通和频繁的反馈来建立学习的内容，软件项目是业务和技术两项经验的积累，需要尽快开始并保持学习的状态。
  • 晚做决策：尽早计划和最晚决策
  • 品质为先：去检视系统的整体而不是一部分，关注整个组织的优化改进，关注团体
  • 全面优化：精益开发不是测试为先，而是通过重构、持续集成、单元测试等技术手段来加强质量保证
  • 快速交付：通过快速交付有价值的软件来最大化项目的投资回报率（ROI）
  • 授权团队：尊重团队成员并由团队来进行决策，保证项目的效率并且有利于项目成功。
• 价值流图（Value Stream Mapping，VSM）：用于分析信息或者材料的流动，从初始到结束，用来识别浪费的环节。识别出的环节即成为流程改进的地方。价值流程图的目的是为了辨识和减少生产过程中的浪费。
  • 步骤一：选定需要分析的产品族
  • 步骤二：调查现状
  • 步骤三：绘制现状图
  • 步骤四：检讨问题点
  • 步骤五：绘制未来图
  • 步骤六：制定改善计划

5.2 看板实践（Kanban）

狭义的看板：一块用来信息共享的板子
广义的看板：一种基于信息可视化的系统性实践方法

• 看板法源于精益
• 整体性组织增量演变过程和系统变更框架，采用拉式系统来完成在制品
• 看板面板利用列进入和退出策略以及限制在制品等制约因素，可提供一目了然的工作流、瓶颈、阻碍和整体状态信息。
• 限制在制品（WIP，work in process），让整个系统中的每份工作"完成”。
• 看板六大核心实践
  • 可视化工作流程：创建一个可视化的工作流示意图，方便跟踪每个工作项的当前状态
  • 限制在制品（WIP）：限制每个环节步骤中的工作项目数，使工作任务能均衡流动
  • 管理流动（拉动）：管理工作流使之快速而毫无中断的流动起来。
  • 显示化规则：明确定义和沟通团队所遵循的价值项流转规则，价值项从一个阶段进入下一个阶段必须达到的标准
  • 建立反馈环路：从你的流程中获得反馈
  • 协作式改进：应用可视化、限制WIP、价值流度量，暴露产品开发中的问题和瓶颈。回顾、分析、改进，并鼓励实验，推动整个团队持续改进。

5.2.1 信息发射源

确保信息透明

累计流图

5.3 极限编程XP

极限编程EXtreme Programming（XP）是一种基于频繁交付周期的软件开发方法。关注团队凝聚力、沟通、代码质量和变成。极限编程相较于传统软件开发方式，强调把它列出来的每个方法和思想做到极致，做到最好。

• 角色：XP教练、XP客户、XP程序员、XP跟踪员、XP测试员
• 核心价值观：沟通、简洁、反馈、勇气、尊重
• 12个技术实现：计划游戏、小版本、用户测试、集体代码所有权、编码标准、可持续的开发速度、比喻、持续集成、测试驱动、开发重构、简洁设计、结对编程