敏捷阅读杂记

  阅读关于《卓有成效的敏捷》这本书，感觉内容还不错，应该说非常好，作者是把自己 20+ 年的操作经验鱼贯而出。由于我之前参与过敏捷培训和敏捷 Leader 开发，与本书过程不一样，但大概都知道，当时发放的培训资料也都收走了，项目使用敏捷方式的时间约有两年吧，所以 Leader + 两年使用时间让我知道大部分敏捷的运行理念。我的角色大部分会议都要参加：每天的站会、周技能学习、评审会议、回顾会议、计划会议等等。但我还是有极个别的会议未参加，那是总监及副总级别的会议，所以这本书的后面个别章节会让我难以理解，当然也并不是全部都要看得懂，至少这本书我应该领会了 95% 以上吧。当然，这种东西不是照抄过来就行的，环境不同，因人而异。

我还没有过更全面、更精细的培训，之前的经验没能让我清晰的认识到我有多少还没了解到的内容，20%吗？60%吗？这件事情在我心里已经很久了，看完这本书我大概知道约有 30% 的内容不了解。本书涵盖了：介绍、团队、工作、组织，说不了解的也就是书中提到的⟨组织⟩内容，也是总监级别的内容吧。况且我不是总监的头衔，也有需要去了解一下为好。

敏捷笔记，勾勾画画，如：书的内容、理解方式、记法等等。这些加起来只有记的人能看得懂，我是为了通勤时间手机观看方便罢了，需要的才记，写写加深记忆。无所谓，感兴趣的朋友看看也好，或者只看下面第五章的⟨关键原则汇总⟩也好。这需要一点经验，而不是开篇。

助词解释

传统项目 = 瀑布项目 = (本篇的)顺序项目。

助词解释

前置时间：从代码变更 到软件部署 的全周期时间。

助词解释

以下在（括号内）的文字，是本人加注的个人理解或扩展想法等，但也不全是。

一、卓有成效的敏捷介绍

1 概述

2 敏捷到底有何不同

表 2-1 顺序开发和敏捷开发之间不同的侧重点

顺序开发	敏捷开发
长发布周期	短发布周期
以大批量的方式，开展从需求到实现的开发工作	以小批量的方式、开展从需求到实现的开发方式
详细的预先规划	高层级的预先规划结合详细的即时规划
详细的预先需求	高层级的预先需求结合详细的即时需求
预先设计	涌现式设计
最后测试，通常作为单独的活动	开发阶段的持续自动化测试
不频繁的结构化协助	频繁的结构化协作
整体方法是理想化的、预先安排、面向控制	整体方法是经验性的、快速响应、面向改进

3.2 在复杂项目上取得成功：OODA循环

• 观察、定位、决策、行动。

OODA循环，作为一种加速决策的途径，通过它可以比敌人更快的做决策，让敌人的决策无效。OODA是一种系统化的方法，用于建立上下文、制定计划、执行工作、观察结果，并将所学到的内容融入下一次循环。

表 3-1 顺序方法和OODA(敏捷)方法之间不同的侧重点

顺序开发	敏捷开发
初始关注规划	初始关注观察
注重长期	注重短期
预先安排	快速响应
理想化的	经验性的
将不确定性视为风险	将不确定性视为机会
面向控制	面向改进
能很好的处理繁杂问题	能很好的处理复杂问题和繁杂问题

顺序开发和敏捷开发之间的总体区别可以总结为，一方使用规划、预测和控制，而另一方使用观察、响应和改进。

3.3 关键原则：检视和调整（回头的纠正机会）

敏捷团队应该定期检视和调整所有事情——计划、设计、代码质量、测试、流程、团队沟通、组织沟通——每一个可能影响团队效率的因素。未经检视就不能进行调整。改变应该基于经验。

二、卓有成效的团队

4.1 关键原则：从 Scrum 开始

Scrum 是一套轻量级但结构清晰、高纪律性的团队工作流程管理方法。Scrum 没有规定具体技术实践。它定义了工作如何在团队中进行，它还规定了一些特定角色以及团队将使用的工作协同实践。

Scrum 团队按 sprint 来组织工作，sprint 是为期 1~4 周的迭代。1~3 周的 sprint 通常表现最好。

整个团队在 sprint 计划期间进行设计，这样做是有效的，因为团队是跨职能的并且拥有做出良好设计决策所需的全部专业领域。

团队不会毫无准备地开始 sprint 计划会议。团队会在 sprint 计划会议之前对需求和设计进行足够的细化以支撑高效的会议。

团队在每个 sprint 结束时交付的功能被称为增量。在通常对话中，增量仅指每个 sprint 交付的新增功能。然而，在 Scrum 中，增量指的是迄今为止所开发的功能的聚合。

每天站会三问（团队共 5~10 分钟的会议）：

• 昨天做了什么？
• 今天要做什么？
• 有什么障碍？

在 sprint 结束时，该质量级别要满足团队的完成定义。

sprint 结束时，Scrum 团队在被称为 sprint 评审或 sprint 演示的会议上演示其工作的实际结果。团队邀请项目利益相关者来交流观点并提供反馈。产品负责人依据约定好的验收标准以及利益相关者的反馈来接受或拒绝工作项，尽管这应该可以在 sprint 评审前就完成。团队使用 sprint 评审中获得的反馈改进产品及过程和实践。

每个 sprint 的最后环节是 sprint 回顾，团队借此回顾 sprint 的成功和失败之处。团队会借这个机会通过用检视和调整来改进其使用的软件开发过程。团队会回顾之前所有的过程改进项，逐一决定每项改进是继续保持还是撤销。此外，团队还会就下个 sprint 要实施的过程改进项达成一致意见。

产品负责人（product owner，PO）是 Scrum 团队与业务管理人员、客户和其他利益相关者之间的接口。Scrum Master 的角色也可以由团队中的技术贡献者来充当，只要给他分配了足够的时间来扮演好 Scrum Master 角色就没问题。

4.2 常见的 Scrum 失败模式

公司应该将产品负责人视为 Scrum 团队最具影响力的角色并相应的优先安排这个角色，通过适当的培训，业务分析师、客户支持人员以及测试人员都有可能成为出色的产品负责人。

我们发现，更为成功的敏捷团队不会等到 sprint 结束时才实现可发布的质量：他们在开始下个故事前会让每个故事达到可发布的质量水平。

4.3 Scrum 失败模式的共同点

Scrum Master 负责确保团队使用 Scrum 的高纪律性的实践（以及其他实践）。Scrum 中的会议——sprint 计划会议、每日 Scrum、sprint 评审和 sprint 回顾——为高纪律性的实践提供了社会性和结构性支撑。

4.10 其他考虑

有些团队或团队已经成功地用看板开始了他们的敏捷实施。然而 Scrum 更结构化、更规范、也更面向团队，因此它通常是开始敏捷开发的最好起点。

调整

如果 Scrum Master 不胜其任，要么培训和发展他们，要么对其进行撤换。

5.1 关键原则：搭建跨职能团队

团队是否拥有架构、质量、可用性、产品、客户和业务方面的专业知识？

一个 5~9 人的团队不可能拥有无数专家。常见的变通方法是，每次让诸如用户体验或架构这样领域的非全职专家介入几个 sprint。

如果团队真正代表了所有利益相关者的利益，所有决策都会从所有相关角度进行考虑。这意味着团队有一个良好的基础进行决策，组织的其他人也有一个良好的基础来信任团队的决策（有技术能力，考虑事情较全面）。

5.2 测试人员的组织

测试人员通过不同的汇报结构进行汇报，通常在总监或副总裁级别之前都不会和开发人员的汇报结构存在交集。这种情况下，测试人员直接或间接负责防止低质量的发布。测试人员与开发人员坐在一起，以便支持更好的协作关系。

5.3 关键原则：将测试人员整合到开发人员团队中（更高级别，如测试专家：压力、性能、负载等，坐在开发团队中）

5.5 被视为黑盒的敏捷团队

团队在每个 sprint 开始时承担一定数量的工作（sprint 目标）来实现的。团队承诺无论如何会在 sprint 结束时交付工作。在 sprint 过程中保护团队避免打扰，通过冲突解决来指导团队，解决项目间的优先级冲突，支持员工发展，雇用新团队成员，提高组织机构效率，以及鼓励团队从经验中反思和学习。

5.7 其他考虑

开放式的办公环境，建议采用如下措施来达到高效：

• 提供带有开放式办公空间的私人或半私人办公室给团队工作
• 团队聚集在小隔间里，并拥有用于团队工作的开放式办公空间和供个人暂时使用的专注房间（小办公室）
• 带有专注房间的隔间
• 带有专注房间的开放式工作间

6.1 关键原则：通过自主、专精和目标来激励团队

• 自主（放手肯干）
• 专精（吸收提高）
• 目标（定期或频繁的沟通）

丹尼尔·平克研究发现，一个自主工作、理解为什么工作而且持续改进的团队也会受到积极性的激励。创建高效团队的因素也会是创建充满积极性团队的因素，而且在这种良性沟通中，效能和积极性是互相促进的。

6.2 关键原则：培养成长思维（以可持续的步调工作并成长，以适当的速度前进）

6.3 关键原则：培养以业务为中心（开发人员试着跟着业务线，与需求人员带着一起工作）

6.4 其他考虑

个人发展方向与角色（个人、角色、与团队协作），当在个人发展方向和角色之间取得平衡，团队往往表现卓越。

调整

制订计划，让技术人员直接与客户接触。

7.1 关键原则：加强反馈循环

团队是高内聚低耦合。（图？）

7.2 迈向成功的分布式敏捷团队

实现分布式团队的成功需要做到以下工作：

• 安排例行的面对面沟通；（多见面，如一季一次）
• 增加分布式团队的后勤支持；（入职培训、定期沟通、Leader负责）
• 充分利用自主、专精和目标；（专业性的自主成长）
• 尊重康威定律；（技术架构在一块，并支持开发人员）
• 将敏捷团队视为黑盒；
• 维持高质量；
• 注意文化差异；
• 检视和调整。（回顾，解决团队的麻烦）

其他考虑：内部决策与效率（Leader 多见面多会议）

调整

制定一个计划来改进跨工作地点的沟通与理解。

制定一个计划来支持分布式团队拥有自主、专精和目标。

8.1 关注个体

建立试验和学习的文化，并投资支持它的技术和管理能力。（他想学什么，我们就给予支持）

8.2 关键原则：通过培养个人能力来提高团队能力

跨职能敏捷团队需要拥有在自己的专业领域表现出色，并且可以根据需要扩展到其他领域的技术人员。

高素质软件从业人员需要在以下三种知识上具备很强的能力：

• 技术知识——具体技术的知识，如编程语言和工具
• 软件开发实践知识——设计、编程、测试、需求和管理领域的实践知识
• 领域知识——专家所从事的具体商业或科学的领域知识

8.3 卓有成效的团队沟通

与管理层沟通（摸清上司）

简化的决策制定模型（每一步每一项，都可优化再优化）

高效的会议（由 Scrum 决定会议内容，并邀请交付成果的相关人员）

沟通的共赢思维，培养关注于帮助他人成功的思维会在团队中创造出良好的动力。

常规的沟通技能（都可以从回顾中获益）

（与员工访谈时，集体访谈，避免单独）

三、卓有成效的工作

9.1 关键原则：保持项目规模小（尽可能小，减少bug）

9.2 关键原则：保持 sprint 短小（2-3周循环一次，比几个月的快）

9.3 采用基于速度的计划（故事点的预计时间点数，需求估算🗒Leader估算🗒开发估算🗒）

9.4 关键原则：以垂直切片的方式交付（只能垂直方式）

9.5 关键原则：管理技术债（何时欠债，何式并何时还债）

要把技术债摆在台面进行管理。

引入债务的概念使得业务方和技术方可以共享彼此的一些顾虑，何时欠债，何种方式进行还债等问题做出更好的决策。

9.6 合理分配工作，避免心力交瘁（6-3-1，注意休息）

一种缓解 sprint 疲劳的办法是，偶尔改变 sprint 的长度。系统化的做法是使用 6-2-1 的模式：6 个 2 周一次的 sprint，然后做 1 个 1 周一次的 sprint，总共加起来是 13 周，一个季度可以执行一次。对那个更短的 sprint，也可以安排在大的发布上线后或者假期前后，或者在其他反正团队速度也不会很快的时候，在这个 1 周的 sprint 里，团队可以做做基础设施或工具相关的工作，可以参加培训、团队建设、黑客日（应该是美国的[公民黑客日]）等活动，也可以还技术债、专注做一些平时因为太大而没有机会在常规 sprint 中做的优化提升，等等。

9.7 其他考虑：与项目无关的软件开发工作（如做打补丁）

调整

鼓励团队创建自己的管理技术债的计划。（怎样还，何时还）

10.3 布鲁克斯法则（能不能彻底拆分）

正如布鲁克斯所指出的，将大型项目拆分成多个小项目的挑战在于工作的彻底拆分。将工作彻底拆分是困难的，但如果你只做到几近彻底的拆分——意味着不同项目团队间仍然需要协作——那么拆分出来的几个小项目从形态和行为上仍然会向大型项目靠拢。届时，好不容易取得的拆分成果又会逐渐退转。

10.4 康威定律（由架构决定都需要怎样的人员）（尽量各做各的）

一个大型系统的理想架构应当能够支持将不同团队间的工作完全分割开。这样的理想结果在一些系统上可能较为容易实现，在另外一些系统上则困难一点。

10.5 关键原则：通过架构支撑大型敏捷项目

具体的架构建议：

• 1.架构的基石：松耦合、模块化（敏捷拆成多个，微服务拆少个，一多一少示具体而言）
  如果系统中的某些处理路径需要大量调用系统其他部分的服务，这些调用又会调用更多的服务（典型的“依赖过多”现象），最终在软件层面就会带来显著的调用负担和沟通负担（和不同微服务团队之间的沟通）。这种情况下，对软件和团队结构来说，将系统集成为更少的微服务是更好的选择。
• 2.避免使用单体数据库（DB分治，如多库支持的数据表格，跨服务的数据需要一个一个的获取）
  要知道应该将系统解耦到什么程度才能使团队之间松耦合，同时又维持高质量的技术解决方案，需要技术判断力和团队管理相关的判断力，两者缺一不可。
• 3.使用队列（多服务间的交互，松耦合，解耦，kafka）（过多服务的交互会带来麻烦）
• 4.采用契约式设计（?）

10.6 大型项目上协作方式的变化

会议记录、名词解释等，形成文档，供异地或后来人观看。

10.9 从 Scrum 开始

确保小项目能够经常性的取得成功，再以此为基础演进到大型项目。

10.10 其他考虑

Scrum of Scrums（规模化）

SAFe（大规模）

11.2 关键原则：制定并采用完成定义（要清晰的完善定义的细节）

在遗留环境中实践完成定义，可能需要在一开始先设定一个比干净环境低一点的标准，当遗留代码库的质量得到提升后，再将完成定义逐步完善到更高的标准上。

11.5 其他考虑

结对编程（不推荐采用）。假设团队希望全面采用结对编程，（为了能够进行，有能力进行，）我支持。（不过团队技术能力偏低了点）

集体编程（mob programming），整个团队使用同一台电脑，同时工作在同一件事情上（多个屏幕而已）。蜂拥式开发（swarming）是让整个团队同时工作在同一张故事卡上，不过每个成员都在自己的电脑上完成属于自己的那部分用户故事。（压根不要用）

12.1 关键原则：由开发团队编写自动化测试（大公司，大项目，独立团队，至少完成集成测试验收测试）

最理想的做法是，采用多种层级、多种类型的测试，如API测试、单元测试、集成测试、验收测试、UI层测试等层级的测试。

一些备受关注的大公司——诸如亚马逊、奈飞等能够支持快速的、持续集成的测试，因为他们有单独的团队专注于这部分的能力构建，他们对计算机硬件进行了大量的投资，并且多年来一直在发展相关的能力。

12.2 使敏捷测试卓有成效的更多要领

将测试工作作为完成定义的一部分。

由独立的测试团队创建和维护验收测试。

12.3 其他考虑

日新月异的测试技术，如 金丝雀发布(A/B测试)、混沌猴子(Chaos Monkey)和猴子军团工具集(Simian Army)。

13 敏捷需求开发

在最初从事软件开发的 25 年里，我看到的每个关于项目挑战与项目失败的研究都表明，问题的主要原因是糟糕的需求——不完整的需求、错误的需求、相互矛盾的需求等。而在过去的 10 年里我们公司发现，敏捷项目上最常见的挑战是好的产品负责人的缺失——你猜对了，还是需求的问题。

13.1 敏捷需求的生命周期

这些实践对每个主要的需求开发活动都有帮助：

• 需求获取——初始的需求探索和发现。
• 需求分析——对需求的进一步理解，以获得更丰富、更精细的需求，包括需求的优先级。
• 需求规格说明——以持久化的方式表述需求。
• 需求确认——保证需求的正确性(能够满足顾客的需求)，保证需求被正确地捕捉到。

13.4 敏捷需求：故事

敏捷需求最常见的描述形式非故事莫属。一张故事卡的常见格式如下：

作为<某个类型的用户>，我希望<目标/要求>，以便获得<收益>

故事是一份可追溯的文档，用于记录业务人员和技术人员之间发生的对话。这样的对话需求从业务、技术、测试以及该故事需求的其他视角对故事进行细化。

13.5 敏捷需求容器：产品待办事项列表

敏捷需求一般都存放在产品待办事项列表中。待办事项列表中可以包含故事(story)、史诗(epic)、主题(theme)、创新(initiative)、特性(feature)、功能(function)、需求(requirement)、功能增强(enhancement)、bug修复(fix)等项目范围里的任何待办事项。

图13-6展示了当产品待办事项（broduct backlog item，PBI）越接近实现时，它们随之得到的细化越仔细。我以漏斗的形式来展现待办事项列表，在漏斗口附近的是近期的工作。（敏捷团队通常称待办事项列表为一个队列，排在队列前面的是近期的工作。）

13.7 关键原则：细化产品待办事项列表

待办事项列表细化工作在待办事项列表细化会议上完成，该会议需要产品负责人、Scrum Master 和开发团队共同参与。整个团队都必须参加会议，这样有利于对接下来的工作形成共同理解。

会议需要进行如下工作：对故事和史诗进行讨论，将史诗拆分成故事，将故事拆解成更小的故事（以及将史诗拆解成更小的史诗），澄清每个故事的细节，定义它们的验收标准，并为它们估算故事点数。

产品负责人需要提供一个已经排好优先级的产品待办事项清单供待办事项细化会议上讨论，这份清单里应该已经做好了大部分需求相关的阐述与解释。

13.8 关键原则：制定并使用就绪定义（需求完成后准备发给开发人员）

13.9 其他考虑：需求基础

在敏捷开发中，（糟糕的庞大的痛苦的需求，分多次分散到各个 sprint 上，）每几个 sprint 重写一个故事。这样就没那么多痛苦了，因为痛苦感不是一次产生的。当然，累计下来的效率损失依然可观。

14.1 产品负责人

正如第四章所提到的，Scrum 最为常见的一种失败模式便是拥有一个不称职的产品负责人。在我公司的服务经验里，一个高效的产品负责人应该具有以下的品质。

（1）是领域专家。
一位有成效的产品负责人对应用、行业，以及对产品所服务的顾客群应该了如指掌。他们对行业的深入理解是为团队交付做优先级排序的基础。其中也包括他们对一个最小可行产品（MVP）中真正需要什么东西的理解。他们还拥有必要的沟通技能，以向技术团队传达业务上下文。

（2）掌握软件需求技能。
一位有成效的产品负责人能理解要定义好适合于特定环境的需求，需要了解什么类型的细节，以及对细节掌握到何种深度（比方说，做业务系统与医疗设备对需求所要了解的详细程度就不同）。产品负责人能理解需求与设计的差异——他应该只关注需求是什么，至于如何实现的问题应该交给开发团队来决定。

（3）掌握引导技巧。
一位强有力的产品负责人能够带领团队朝一个共同的目标前进。软件需求工作主要在于协调多方冲突的利益：业务目标与技术目标之间的权衡，团队对局部技术的想法与更高层级的组织架构之间的权衡，不同产品利益相关者之间的冲突，以及其他的紧张情势，等等。一位富有成效的产品负责人能够帮助各位利益相关者明白，为了打造一款优秀的产品需要拥有不同的视角。

（4）要有勇气。
一位有成效的产品负责人能够在需要的时候做出决策。有成效的产品负责人不会独断专行，但他明白什么时候应该由他拍板决定，什么时候可以让团队共同做出决策。

（5）干练的个人品质。
一位有成效的产品负责人往往具有干练的个人品质，如充满活力，对待办事项列表细化非常主动，能够高效的引导会议，以及能持续地追踪事物进展直至完成等。

这里列出的优良品质也暗含了对优秀产品负责人某些方面的背景要求。理想的产品负责人需要具备一定的工程背景，对所处领域有经验，以及有一定的业务经验。不过就如我前面所讲的，只要有适合的训练，业务分析师、客户支持人员、测试人员等角色都可以胜任优秀的产品负责人。

14.3 故事地图

因为待办事项列表里常常包含成百上千张故事卡，所以有时在做优先级排序的时候容易迷失，在每个 sprint 末尾交付的一组故事也容易缺少连贯性——即使单独来看他们确实是优先级最高的待办事项。

故事地图是一个强有力的工具，他能帮你排列待交付故事的优先级顺序，同时还能保证一组故事可以形成连贯一致的功能（Patton，2014）。故事地图对需求的获取、分析以及需求规格同样有帮助，同时它还能助力开发过程中的状态追踪。

故事地图需要整个团队一起经营实施，它包含以下 3 个步骤。

（1） 用便利贴记录下主要的大块功能，把它们按照优先级排列在一行上，最左边的优先级最高，越往右边优先级越低。大的功能块可以包含特性、史诗/大故事、主题、创新及其他粒度较粗的需求。在本篇后续的讨论中，我会使用“史诗”一词统一指代这些需求。

（2）将顶层史诗拆分成步骤或主题。这个拆分不会改变史诗的优先级顺序。

（3）将每个步骤或主题进一步拆分成用户故事，并记录在便利贴上。将拆分出来的故事排列在每个步骤或主题之下，优先级按从上往下的顺序递减。

这套流程最终会产出一张故事地图，上面罗列了所有需求并按照从左往右、从上到下的优先级排好了顺序。

以下几小节将更详细地介绍每个步骤的细节。

第一步：对史诗及其他顶层事项做优先级排序

顶层事项记录在便利贴上，按照从左到右的排列确定优先级顺序，如图14-1所示。

每个史诗可以使用按T恤估算法(?)或其他技术（如加权最短工作优化方法，我们将在第22章介绍）来确定优先级顺序。

排列在故事地图右侧的是优先级较低的史诗，它们可能重要程度不太高，不会被包含到发布里面。即使它们有发布的价值，其重要程度也可能不足以被包含到最小可行产品（MVP）中。

第二步：将顶层史诗拆分成步骤或主题

大多数史诗都可以很容易凭直觉将其讲述成有顺序的多个步骤。有些史诗不包含一系列的步骤，但可以被拆分成多个主题，如图14-2所示。

在故事地图中，通过拆分得到的第二层步骤和主题称为主干（backbone）。通读一遍主干上的描述，应该能得到一个关于总体功能的连贯描述。

第三步：将每个步骤或主题拆分成按优先级排序的用户故事

在主干之下，每个步骤或主题会被进一步拆分成一个或多个故事。如图14-3所示，故事按照优先级从上到下的顺序排列，排序依据可以是T恤估算法(?)，也可以仅仅是团队的大致判断。

在故事地图中，每列中在步骤或主题之下的故事卡也称为地图的肋骨（ribs）。在主干正下方，有一组最小的故事集能够实现一个连贯的功能，这组故事也称为地图的活动骨架（walking skeleton）。活动骨架尽管功能连贯，但通常还不足以成为一个MVP，MVP在活动骨架外往往还包含一些其他的故事。

这些术语在故事地图上的体现如图14-4所示。

团队还可以添加许多细粒度的功能，但它们不会被包含到活动骨架中。通过主干、活动骨架和MVP这样的划分，无疑为开发团队交付价值最高、完整连贯的功能提供了清晰的指引。

1.故事地图与用户角色

故事地图有个同样有用的变种，就是在顶层不放置史诗，而是从用户角色开始：对用户角色进行同样的从左到右的优先级排序，再在每个用户角色下面拆分出史诗。

2.故事地图的信息发射源作用

有成效的敏捷实践强调要将工作可视化——这不仅仅是让工作可以通过网页访问，还要使其变成工作环境可见的一部分。一张墙上的用户地图能持续提醒团队关于优先级、当前工作分配，以及未来工作流等事宜。敏捷团队将这种故事墙称为一面信息发射源。

研究表明，这种可视化墙对提升交付效能来说非常必要（Forsgren，2018）。

3.故事地图体现了敏捷钟摆效应

故事地图是体现软件开发钟摆效应的一个绝佳例子：从最初完全的顺序开发，到早期的敏捷，现在钟摆又回到了一个更好的敏捷。早期敏捷开发会尽一切努力避免进行预先的需求工作，并将需求细化留到实现之前再进行，绝不提前开展细化工作。而故事地图这项与敏捷开发紧密联系的实践，却是一项预先进行需求管理和优先级排序的技术。但它与老的、顺序的、提前细化所有需求的做法不同。故事地图的实践有助于预先定义一次发布的大致范围，并持续为发布过程中的增量需求细化提供优先级排序和指引。

故事地图同时也是这样一绝佳的例子：它展示了顺序开发与敏捷开发是如何结合到一起，并为彼此提供双方最好的实践。故事地图为预先辨识需求、但仅在需求实现之前再进行细化提供了支持。它有助于避免一种常见的敏捷失败模式：虽然确实按优先级顺序交付了功能，却错失了整个全景图。在对故事墙从左到右、从上到下的走查过程中，通常会暴露更多考虑不周全的失误，如史诗里遗漏的步骤、对优先级的错误界定等。

15 敏捷交付

交付指的是开发流程中除需求以外的所有活动的总和。

使软件进入可交付状态的最后一个必要步骤是集成。敏捷开发的目标便是做到持续集成（continuous integration，CI）和持续交付/持续部署（continuous delivery/deployment，CD）。CI/CD 实践是 DevOps 的基石。

15.1 关键原则：自动化重复性工作

四、卓有成效的组织

16 敏捷领导力

服务型领导者，... ... 更清晰的指导。（可能我需要细节与活动的付出）

16.1 关键原则：管理结果，而不是管理细节（互不打扰）

敏捷团队（尤其是 Scrum 团队）向领导者承诺他们将在每个 sprint 结束时交付 sprint 目标。在完全遵循规范的 Scrum 实施中，承诺被视为绝对的——团队将尽心竭力地工作来达成 sprint 目标。

相应地，领导者向 Scrum 团队承诺他们会尊重 sprint 的安排。领导者不会在 sprint 中途变更需求或打扰团队。

16.2 关键原则：用指挥官意图明确表达目标（优先级的掌握）

指挥官意图是个很好的视角，通过它可以看到合适的优先级。领导者应该定义成功的标准——目标、结果、影响和收益，但不要定义细节。

16.3 关键原则：关注吞吐量，而不是关注活动（宽松政策）

组织领导者必须承认，一定程度的宽松是最大化吞吐量的必要条件（DeMarco，2002）

Scrum 将责任放在团队层面而不是个人身上的原因是，它允许团队决定如何做以最大化生产力。如果一名成员在外面坐一天生产力最高，团队可以自行决定让他到外边坐一天。（在思考，在冥想，或休息）

16.4 关键原则：在关键敏捷行为上以身作则

高效的领导者也会展现出他们想从员工身上看到的那些行为。这些行为包括：

• 培养成长思维——致力于在个人和组织层面持续改进；
• 检视和调整——持续反思，从经验中学习，并应用所学到的东西；
• 正向看待错误——接受每个错误并将其作为学习机会，将这种处置方法作为榜样；（学习榜样）
• 修复系统——当发生问题时，不管是人的错误还是系统的错误，将其作为系统缺陷检测的机会，去完成；
• 承诺高质量——用你的行动传达对高质量的明确承诺；
• 培养以业务为中心——展示你的决策如何包含业务上的考虑和技术上的考虑；
• 加强反馈循环——积极回应团队（即使他们不需要，因为你已经清晰表达了指挥官意图）。

17.1 关键原则：正向看待错误

留心从结果中学习。

“我们很高兴自己犯了这个错误，否则我们可能永远都不会增进对某些事情的理解”。

复杂项目不仅仅依赖于从错误中学习，还需要尽早开始试错。创造一种必要时毫不犹豫地犯错的组织文化是很重要的。建立一种先做决策并从经验中学习的文化是有益的。

在修复黄金期内改正错误（早改错误）

17.2 心理安全（生机型，视错误为机会）

表 17-1 韦斯特鲁姆的三种文化模型中不同文化的属性

病态型	官僚型	生机型
权力导向	规则导向	绩效导向
缺少合作	适度合作	高度合作
信使被消灭	信使被忽略	信使受到训练
推卸责任	责任范围窄	风险共担
阻拦跨部门沟通	容忍跨部门沟通	鼓励跨部门沟通
失败 → 替罪羊	失败 → 责任评判	失败 → 调查
压制新鲜事物	认为新鲜事物带来问题	采纳新鲜事物

17.3 关键原则：以量化的团队产能为依据制定计划（给领导说明障碍，望领导加入其中，看看究竟是什么）

17.5 公司在支持卓有成效的敏捷中扮演的角色（爷爷的孙子，宠爱）

公司打击团队的做法有很多，如责备团队犯错、不支持团队拥有自主性、不充分与团队沟通其目的，以及不允许团队持续成长等。当然，这并不是敏捷团队独有的苦恼，常规的非敏捷团队也常常面临类似问题。

如果公司通过建立整个组织内不责怪的文化、为团队配备所需的全部技能、给团队安排合适的工作量、定期向团队传达其目的以及支持团队持续成长等来支撑团队，团队可能会更成功。

18.1 度量工作量

速度（故事的平均速度）

小故事（大主题转变为多个小故事）

像 21、40 和 100 这样的点数不应该参与到故事点加总中。它们更多是用来表达对体量的感觉，而不应被理解为精准的数字。——不应该包含这些故事点。

短迭代（敏捷迅速的过程）

比较团队的速度（此速度非彼速度，不可比）

18.2 度量工作质量（返工的定义和算法）

在敏捷团队中，返工往往是逐渐完成的，因此不那么引入注意。但它仍然存在，因此监控敏捷团队的R%是有用的。

对处理遗留系统的团队，之前团队造成的返工问题应该算做新工作。如果一个团队在修复自己之前造成的问题，这个工作应该算做返工。

无论哪种方法，其目的都是 …… 质量 …… 来平衡 …… 速度。

18.3 度量的一般注意事项

设定度量的期望（项目的横量更全面）

度量什么，就（只会）做什么，确保为团队优化引入一套平衡的度量。

调整（设想的）

• 领导的满意率
• 客户的满意率
• 员工的满意率

19.2 提高生产力

提高团队生产力（几个 sprint 对故事点的完成个数 = 速度，称为生产力）

度量可以给出要问的问题并指出要关注的地方，但它们不一定能给出答案。

提高团队生产力的作用（原因的影响）

经理问：“如果我们让那个人离开，你们会承诺保持相同的速度吗？”团队回应：“不，我们会承诺提高我们的速度，因为那个人拖慢了大家。”

组织对生产力的影响（组织犯的错），有时候，我们看到的组织问题包括：

• 难以招聘到合格的员工
• 人员流动率高
• 专业发展太少
• 经理培训太少
• 不愿撤换有问题的团队成员
• 不愿遵循 Scrum 的规则，如 sprint 中期不进行变更
• 不能配备特定角色（Scrum Master，产品负责人）
• 频繁改变业务方向
• 对其他团队有依赖，而这些团队又不能提供及时的支持
• 过多的跨项目多任务处理，包括提供必要的产品支持
• 缺乏业务人员的支持，决策缓慢
• 管理层决策缓慢
• 官僚企业的工作方式
• 团队散布在多个开发地点
• 对跨工作地点旅行的支持不足

比较各个团队的生产力（向优秀者学习，‹学不来吧›）

生产力改进的底线（ = 度量）

19.3 严格绘制价值流图，并监控在制品数量

限制在制品的作用是暴露等待时间，这是软件项目中浪费的一大来源。以下是一些需要等待的例子：（暴露的浪费，全栈工程师灵活填充短板）

• 代码已经通过单元测试、集成测试并且已经提交；在功能可以部署以前，需要等待手工验收测试完成；
• 在软件可以被部署前，等待开发修复由独立测试组织发现的故障；
• sprint 中的故事挪动到“完成”前，等待代码评审；
• 等待一个地点的团队提交代码，然后另一个地点的团队才能继续工作；
• 在开发团队能够开始实现故事之前，等待产品负责人细化故事；
• 等待高层决策者确定团队应该实施哪种方案。

关注在制品对帮助组织从最大化忙碌向最大化吞吐量转换是非常有用的。

19.4 敏捷回顾（重要会议）

Scrum Master 主持会议，整个 Scrum 团队参加。会议一般遵循下面的流程：

（1）介绍规则。建议团队成员更多关注于如何改进。提醒大家关注修复系统。有家公司在每次回顾时都用一个笑话开场，这能为会议确立下宽容错误和心理安全的基调。
（2）收集输入。让大家把想法写在便利贴上，然后贴到同一面墙或者白板上。
（3）洞察问题。将相似的意见或想法归类，寻找这些问题的根因，回顾全局。
（4）决定做什么。确定团队可以尝试的改进项，制订行动计划。
（5）总结并结束回顾。在回顾会议最后，可以回顾下这场会议还能如何进一步改进。

19.6 检视和调整（重要会议）

给领导者的行动建议

    |——浪费延迟（本书描述）

浪费 ——|——修复浪费（自己想的，全栈灵活填充）

    |——以上会不会想多了

20.1 发布生命周期不同阶段的可预测性

20.2 可预测性的类型

精确的成本和进展预测

• 可预测性支持：速度计算（Leader与Member共同开会预测的可能）
• 可预测性支持：预先填充、细化和估算产品待办事项列表（待办事项的处理）
  只需要细化到能够为每个待办事项估算故事点即可，他们给每个待办事项实际估算故事点，这被称为“给整个产品待办事项列表估算点数”。
• 可预测性支持：发布燃尽图（故事点数量走势）

精确的特性预测

• 计算速度，用来预测功能数量（速度得出交付日期）

粗略预测

• 需要可预测性时使用史诗作为预测

20.3 可预测性与敏捷边界

20.4 可预测性与灵活性

由于短 sprint 的工作结构（前期投入少），团队能够更容易地改变方向。

20.5 其他考虑

可预测性与敏捷文化

《敏捷宣言》描述的最初价值之一是客户协作。如果你是客户，而你的敏捷团队一直坚持你应当重新审视业务本身，而不是提供你要求的东西，你可能需要建议团队重新审视客户协作这条敏捷价值观。（客户靠敏捷，而非官僚型做法）

21.1 敏捷如何支持受监管环境中的工作

提供广泛的追溯性来证明你做到了所有细节工作。

高层级的 预先规划 结合 详细的 及时规划。
高层级的 预先需求 结合 详细的 及时需求。

21.2 Scrum 如何支持受监管环境中的工作

IEC 62304 标准要求有下面这些类别的活动和文档：（顺序项目流程）

• 软件开发计划；
• 需求分析；
• 软件架构设计；
• 软件详细设计；
• 软件单元实现和验证；
• 软件集成和集成测试；
• 软件系统测试；
• 软件发布。

21.3 受监管系统的敏捷边界

22 (?)

23.2 多米诺变革模型

在多米诺变革模型中，成功的组织变革需要下面这些元素：

• 愿景
  除了要清楚地定义敏捷，愿景还应该包含一份关于期望中的最终状态的详细表述。该表述应该包括为什么需要进行敏捷实施、预期的收益是什么、实施的深度和广度会怎样，以及它将如何影响每个人——理想情况是不要泛泛或笼统的谈，而是要一个问题一个问题说清楚。
• 共识
  共识建立需要双向沟通：领导者描绘愿景并接受关于愿景的反馈。在真正的共识建立过程中，愿景可能也会有所变化。
• 技能
  构建技能需求基础的专业技能培养，包括课堂里或线上的正式培训、讨论组、阅读俱乐部、午餐会、练习新技巧的时间、内部指导、外部指导、以及传帮带等。
• 资源
  谨记，软件开发是基于技能的智力劳动，软件变更所需的各种资源包括获得培训、指导以及工具的许可。尽管看起来似乎没有必要，但员工也需要获得明确的授权以及专门的时间来推进敏捷实施工作。如果没有这些，员工对日常工作的关注会占主导地位。更大型的组织通常需要全职员工推动敏捷实施。没有足够的资源，员工会感觉领导者口是心非。
• 激励
  记住要考虑自主、专精和目标。一个完全遵循规范的敏捷实施能够增加个人和团队的自主权。关注基于经验的计划和成长思维将支持学习和专精。最能够支持敏捷团队的领导风格是定期与团队沟通目标。（传教引导，激励发挥，互相帮助）
• 行动计划
  将检视和调整纳入行动计划。变革应该是渐进式的，应该基于定期回顾和在整个推广过程中经验教训的应用来进行改进。

23.3 在组织内转播变革

如图 23-3 所示，创新采纳顺序呈现标准正态分布（钟形曲线）。创新者在距均值三个标准差之内，而早期采纳者在距均值两个标准差之内。总的来说，他们仅代表总采纳者需要的支持的 15%。

23.4 再谈高层级的变革推广

这里从高层级看一个更实际的敏捷实施方法。

• 阶段 1：从试点团队开始。
  尝试敏捷方法，解决单个团队层面的绊脚石。
• 阶段 2：将敏捷实施传播到一个或多个其他团队。
  在工作时间提供明确的培训、指导，拨出专门的时间来处理向新团队的推广。建立实践者社群并支持他们。定期与新团队联系，主动提供额外的支持。解决额外的问题，包括团队之间的问题。制订一份计划，用以提供更大范围推广所需的更多培训和支持。
• 阶段 3：将敏捷实践推广到整个组织。
  详细描述那些团队获得的收益，并解释已经得到了什么经验教训，这些经验教训有助于保证其他团队获得成功。倾听人们的反馈，按需要修正愿景。传达修正后的愿景，并确认已经包含了人们的反馈。

让敏捷在组织中获得成功的具体计划。讲清楚谁领导实施工作、让实施取得成功需要什么工作，以及实施的时间表。

提供工作中的培训和指导。强调每个团队都有权力做让推广获得成功所必须的工作。定期与团队联系，并提供额外的支持。提供人员帮助解决团队内部问题和跨团队问题。向团队解释有挑战是正常的，当挑战出现时组织会向他们提供支持。

总的来说，将指挥官意图应用于敏捷实施。设定愿景（并接受员工的反馈），然后让人们自由地解决细节问题。

（
阶段：一个，多个，反馈。
高层：培训，指导，跨团队。
总结：自由地解决细节问题。）

23.5 检视和调整

寻找每个领域出现问题的迹象。每次敏捷实施都会在某些方面具有独特之处。对反馈保持开放态度，如果需要就调整方向。

五、关键原则汇总

检视和调整。敏捷是一种依赖于从经验中学习的经验性方法。这需要创造机会定期反思并根据经验进行调整。（3.3节）

从 Scrum 开始。Scrum 并非敏捷之旅的最终目的，但它是最为结构化、支持最好的起点。（4.1节）

搭建跨职能团队。敏捷项目的工作发生在自我管理的团队中。要自我管理，团队必须包含做出对组织有约束力的良好决策所需的全部技能。（5.1节）

将测试人员整合到开发人员团队中。通过让做事的人更紧密的一同工作来加强开发和测试之间的反馈循环。（5.3节）

通过自主、专精和目标来激励团队。敏捷实践天生就支持那些有助于激励的因素。团队旨在自主地工作并不断改进（专精）。为了做到这一点，他们需要理解目标。“健康的敏捷团队”与“积极进取的敏捷团队”是互为表里的。（6.1节）

培养成长思维。无论你是从自主、专精和目标的专精角度看还是从检视和调整的角度看，高效敏捷团队持续地关注于变得更好。（6.2节）

培养以业务为中心。开发人员经常需要在产品负责人的指导下填补需求中缺失的细节。理解业务有助于以对业务有益的方式填补这些细节。（6.3节）

加强反馈循环。不要花更长时间学习不需要的经验教训，而是尽可能加强反馈循环。这有助于通过检视和调整获得更快的进步，以及通过培养成长思维更快地改善效果。（7.1节）

修正系统，而不是处理个人。大多数软件从业人员都想做好工作。如果他们没有把工作做好，特别是如果他们看起来没有尽力把工作做好，应该去了解是什么导致了这一点。找出让个人感到挫败的系统问题。（7.3节）

通过培养个人能力来提高团队能力。团队呈现的品质是团队中个人品质以及他们之间互动的结合。通过加强个人来加强团队。（8.2节）

保持项目规模小。小项目更容易而且更常成功。不是所有工作都能够被组织成小项目的形式，但只要有可能，就应该尽量地把工作组织成小项目的形式。（9.1节）

保持 sprint 短小。短 sprint 支持频繁的检视和调整的反馈循环。短 sprint 能使问题更快暴露，更容易在小问题变成大问题前将它们消灭在萌芽状态。（9.2节）

以垂直切片的方式交付。敏捷中的反馈很重要。当团队以垂直切片而不是水平切片的方式交付时，他们能够得到有关其技术和设计选择方面更好的反馈——既有来自客户的反馈，也有来自业务的反馈。（9.4节）

管理技术债。持续关注质量是高效敏捷实施的一部分。管理技术债能带来更高的团队士气、更快的进展，以及更高质量的产品。（9.5节）

通过架构支撑大型敏捷项目。良好的架构能够支持项目的工作拆分并最小化大型项目特有的日常开销。优秀的架构能够让大型项目感觉上像较小的项目。（10.5节）

使缺陷检测的时间最短。修复缺陷的成本往往随着缺陷停留时间越长而变得越高。敏捷注重质量工作的一个好处是在更靠近源头的地方检测出更多缺陷。（11.1节）

制定并采用完成定义。良好的完成定义有助于及早发现不完整或错误的工作，最大限度地缩小缺陷引入和缺陷检测之间的时间。（11.2节）

将质量维持在可发布水平。将质量维持在可发布水平有助于捕获早期完成定义遗漏的额外缺陷。（11.3节）

由开发团队编写自动化测试。自动化测试有助于最小化缺陷检测时间。让团队中的每个人都负责测试强化了质量是每个人的责任这一理念。（12.1节）

细化产品待办事项列表。产品待办事项列表细化确保团队处理最高优先级的事项，不会在没有产品负责人的情况下自行填补需求细节，并且不会让团队没有工作而陷入空转。（13.7节）

制定并使用就绪定义。待办事项列表细化的部分工作是确保需求在团队实现前确实准备就绪。（13.8节）

自动化重复性工作。没有人喜欢重复性工作，而且当把软件开发中能够自动化的工作进行自动化后，许多工作能够比不进行自动化带来更多收益。（15.1节）

管理结果，而不是管理细节。通过清晰地沟通期望结果的方式来保护团队的自主性，同时让团队自由决定完成工作的细节。（16.1节）

用指挥官意图明确表达目标。通过明确传达期望的最终状态的目标，来支持团队能够进行及时的内部决策。（16.2节）

关注吞吐量，而不是关注活动。类似管理结果，细微差别在于忙碌并非目标——搞定有价值的工作才是目标。（16.3节）

在关键敏捷行为上以身作则。高效的领导者也会展现出他们想从员工身上看到的那些行为。（16.4节）

正向看待错误。正向看待错误，以便团队可以毫不犹豫地将错误暴露出来，这样能够从中汲取教训。不从过往错误中汲取教训为让公司再次蒙受损失。（17.1节）

以量化的团队产能为依据制订计划。敏捷是一个经验性方法，团队和组织应该基于量化的产能来计划工作。（17.3节）