敏捷整洁之道-回归本源

第 1章 介绍敏捷 1

1.1 敏捷的历史 3

• 我第一次尝试了测试驱动开发（TDD），从此深深着迷。

1.2 雪鸟会议 10

• 个体和互动高一流程和工具
• 可工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划

1.3 敏捷全貌 14

1.3.1 铁十字 15

• 质量、速度、成本、完成，你只能任选3个，没法4个全要。

1.3.2 墙上的图 15

1.3.3 你知道的第 一件事 18

• 交付日期

1.3.4 会议 18

1.3.5 分析阶段 19

1.3.6 设计阶段 20

1.3.7 实施阶段 21

1.3.8 死亡行军阶段 22

1.3.9 夸张吗 23

1.3.10 更好的方式 23

1.3.11 迭代0 24

1.3.12 敏捷产出数据 25

1.3.13 幻想与管理 27

1.3.14 管理铁十字 27

• 为延迟的项目增加人手反而会是它更加延迟。
• 快速前进的唯一方法就是做扎实。
• 写了二三十年程序之后，这是你会学到的最重要一课。没有“快而脏”这样的事，逢脏必慢。

1.3.15 业务价值排序 31

1.3.16 全貌至此结束 31

1.4 生命之环 31

• 极限编程是敏捷本质核心的原型，也是最好的代表。

• 极限编程的生命之环（敏捷运动的发起人之一：肯特 贝克）

  • 

• 业务实践

  • 计划游戏
  • 小步发布
  • 验收测试
  • 完整团队

• 团队实践

  • 可持续节奏
  • 代码集体所有
  • 持续集成
  • 隐喻

• 技术实践

  • 结对
  • 简单设计
  • 重构
  • 测试驱动开发

1.5 结论 35

第 2章 敏捷的理由 37

2.1 专业性 38

• 敏捷吸引我的第一要素是导读重视纪律而非形式。
• 要把敏捷做对，你需要结对编程、测试先行、重构并致力于简单设计。

2.1.1 到处是软件 39

2.1.2 程序员统治世界 41

2.1.3 灾难 42

• 在把计算机编程编程真正光荣职业的道路上，敏捷软件开发将是我们迈出的第一步。

2.2 合理的期望 43

2.2.1 我们不会交付一堆垃圾！ 43

• 请注意，敏捷中强调测试、重构、简单设计以及用户反馈，就是为了避免交付糟糕的代码。

2.2.2 从技术上随时做好交付准备 45

2.2.3 稳定的生产率 46

• 杂乱代码越多，阻碍越大，进度越慢。团队进展越慢，项目日程压力就更大，这又会带来更多的混乱。
• 增加人力反而会拖慢团队好几周。
• 大规模的重新设计极其昂贵，而且很少真正部署上线。
• 开发人员对自己的要求不应该低于此。持续地将架构、设计以及代码保持在尽可能干净的状态

2.2.4 划算的适应性 49

• 软件就是“容易修改的产品”。
• 客户、用户和管理者都希望软件系统容易修改、修改的成本不高并且成本与收益相符。
• 我们将看到测试驱动开发、重构和简单设计等敏捷实践是如何确保以最小的代价安全地更改软件系统。

2.2.5 持续改进 50

• 结对编程、测试驱动开发、重构、简单设计等敏捷实践强有力地支持持续改进的期望。

2.2.6 无畏之力 50

• 测试驱动开发的敏捷实践为你提供了无所畏惧的能力。

2.2.7 QA应该什么也找不到 52

• 验收测试、测试驱动开发以及持续集成等敏捷实践支持这个期望。

2.2.8 测试自动化 52

• 手工测试应该仅限于那些无法自动验证的事情，以及需要创新能力的探索性测试上。
• 验收测试、测试驱动开发以及持续集成等敏捷实践支持这个期望。

2.2.9 我们互相掩护 54

• 结对编程、完整团队和代码集体所有的敏捷实践支持这些期望。

2.2.10 诚实的估算 54

• 最诚实的估算就是“我不知道”。

2.2.11 你需要说“不” 55

• 当答案确实是“不”的时候，我期望你能够说出“不”。

2.2.12 持续主动地学习 55

2.2.13 指导 56

2.3 权利条款 56

2.3.1 客户权利条款 56

2.3.2 开发人员权利条款 57

2.3.3 客户权利详讨 57

2.3.4 开发人员权利详讨 59

2.4 结论 61

• 敏捷不仅仅是一组规则，还是构成软件开发职业道德基础的权利、期望和纪律的组合体。

第3章 业务实践 63

3.1 计划游戏 64

3.1.1 三元分析 65

3.1.2 故事和点数 66

3.1.3 ATM的故事 67

3.1.4 故事 74

• 故事遵循一简单的指导原则：（INVEST）
  • I：独立（Independent）
  • N：可协商（Negotiable）
  • V：有价值（Valueable）
    • 故事永远是有业务价值的东西。
  • E：可估算（Estimable）
  • S：小（Small）
  • T：可测试（Testable）

3.1.5 故事估算 76

• 伸指头

3.1.6 对迭代进行管理 78

• 故事都是由程序员自己选 择的。
• 经理和主管可能倾向于将故事分配给程序员。应该避免这种情况，而让程序员自己进行协商，这样做的效果要好得多。
• 如果没有在中期节点之前准备好所有验收测试，那么一些开发人员应该停止开发故事，并开始编写验收测试。

3.1.7 演示 80

3.1.8 速率 81

• 不要给度量对象施加压力
• 最可能导致速率图显示持续的负斜率的因素是代码质量。
• 团队很有可能没有进行足够的重构，而且可能坐视代码腐烂。
• 团队无法充分重构的原因之一是由于没有充分的单元测试，因此他们担心重构会破环过去可运行的部分。

3.2 小步发布 82

3.2.1 源代码控制简史 83

3.2.2 磁带 85

3.2.3 磁盘和源代码控制系统 85

3.2.4 Subversion 86

3.2.5 Git与测试 87

3.3 验收测试 88

• 应该由业务方负责说明需求的规格。
• 规格说明是一种测试。

3.3.1 工具和方法论 89

3.3.2 行为驱动开发 90

• 他们的目标是从测试中去掉技术术语，是测试看起来更像业务人员会喜欢的样子。

3.3.3 实践 90

• 程序员才能知道他们开发的故事是否完成。

3.4 完整团队 93

• 用户和程序员之间的距离越短，交流就越好，开发就越快、越准确。
• 当整个团队坐在同一个空间里，魔术般的变化就能发生。
• 当团队在同一地点时，业务运行会更顺畅。

3.5 结论 96

• 在2001 年的雪鸟会议上，肯特*贝克说，我们的目标之一是弥合业务与开发之间的鸿沟。

第4章 团队实践 97

• 实践包括隐喻、可持续节奏、代码集体所有和持续集成。

4.1 隐喻 98

• 为了有效地进行沟通，团队需要一个受限制的、有纪律的词汇表，其中包含项目中的术语及概念。

4.2 可持续节奏 100

• 快跑的未必能赢......

4.2.1 加班 102

• 自己最糟糕的技术错误都是在狂热熬夜时犯下的。

4.2.2 马拉松 103

• 我学到了软件项目是一场马拉松，不是冲刺，更不是一系列连续冲刺。
• 你有义务节约自己的资源以确保坚持到最后。

4.2.3 奉献精神 103

• 加班工作并不能向雇主展现你的奉献精神。
• 这只能表明你的计划做得糟糕，你答应了不该答应的截止日期，
• 承诺了不该承诺的事情，你只是一个可被操纵的劳工而非专业人士。
• 你必须非常清醒地意识到加班的成本可能远远超过省下的时间。

4.2.4 睡眠 104

• 程序员最宝贵的养生之道就是充足的睡眠。

4.3 代码集体所有 104

• 代码集体所有并非说你不能有所专长。

4.4 持续集成 107

4.4.1 然后有了持续构建 108

4.4.2 持续构建的纪律 109

• 持续构建应该用不被破坏。
• 构建永不失败。

4.5 站会 110

• 怎么做
  • 上次会议之后我做了什么？
  • 下次会议之前我将做什么？
  • 什么阻碍了我？
  • 你想要感谢谁？
• 不要做
  • 不要讨论
  • 不要装腔作势
  • 不要深入解释
  • 不要藏着掖着
  • 不要带有情绪
  • 不要八卦
  • 不要发牢骚

4.5.1 猪和鸡？ 111

4.5.2 公开表示认可 111

• 你想要感谢谁？

4.6 结论 111

第5章 技术实践 113

5.1 测试驱动开发 114

• 没有测试驱动开发、重构、简单设计及结对编程的明姐只是虚有其表，起不到作用。

5.1.1 复式记账 114

• 测试驱动开发是程序员的相应实践。每个必要的行为都输出两次：一次作为测试，另一次作为使测试通过的生产代码。
• 学习 TDD 的程序员被教会每次只添加一个行为--先写一个失败的测试，然后写恰好使测试通过的生产代码。
• 尽管编程对社会来说已经必不可少，但我们还没有用法律强制实施 TDD。
• 可是，既然编写糟糕的软件已经造成了生命财产损失，立法还会远吗？

5.1.2 TDD三规则 116

• TDD 可以描述为以下 3 条简单的规则：
  • 先编写一个因为缺乏生产代码而失败的测试，然后才能编写生产代码。
  • 只允许编写一个刚好失败的测试--编译失败也算。
  • 只允许编写刚好能使当前失败测试通过的生产代码。

5.1.3 调试 117

• 但是通过实践 TDD 的 3 条规则，就可以大大降低 bug 的发生率和严重性。

5.1.4 文档 117

• 测试集已经以各种方式调用该函数，并捕获其可能引发的每个异常。

5.1.5 乐趣 118

• 如果你曾事后补写测试，你就应该知道，那不好玩。
• 因为你已经知道代码可以工作，你已经手工测试过。

5.1.6 完备性 119

• 不要因为覆盖率不足而使构建失败。

5.1.7 设计 121

• 通过先写测试，你将以此前从未想过的方式解耦系统。
• 整个系统将是可测试的，所以整个系统也将被解耦。

5.1.8 勇气 121

• TDD的好处
  • 更少的调试
  • 高质量的详细文档
  • 有趣、完备的测试
  • 解耦
  • 勇气
  • 我们之所以实践TDD，是因为它给了我们勇气，去保持代码整洁有序。它给了我们勇气，让我们表现得像一个专业人士。

5.2 重构 123

5.2.1 红-绿-重构 124

• 在 TDD 三规则的基础上在结合重构过程，就是广为人知的“红-绿-重构”。
  • 1. 创建一个失败的测试。
  • 2. 是测试通过。
  • 3. 清理代码。
  • 4. 返回步骤 1。
• 编写可用的代码与编写整洁的代码是编程的两个不同的维度。
• 重构是一个持续的过程
• 重构一次永远不应该出现在时间表上。
• 重构活动也不应该出现在项目的计划中。

5.2.2 大型重构 125

• 这种修改同样纳入红-绿-重构循环内。

5.3 简单设计 125

• 简单设计实践是重构的目标之一。
• 简单设计的意思是：仅编写必要的代码，使得程序结构保持简单、最小和最富表现力。
• 简单设计的规则如下：
  • 所有测试通过。
  • 揭示意图。
  • 消除重复。
  • 减少元素。

5.4 结对编程 127

• 结对是可选的。
• 结对是间歇性的。

5.4.1 什么是结对 128

5.4.2 为什么结对 129

• 结对是团队成员之间共享知识并方式形成知识孤岛的最佳方法。

5.4.3 结对当作代码评审 129

5.4.4 代价几何 130

• 直接成本可能约为15%

5.4.5 只能两人吗 130

5.4.6 管理 130

• 永远、永远不要请求管理者允许你结对，或测试，或重构，或者......你是专家。你决定。

5.5 结论 131

• 敏捷的技术实践是任何敏捷工作中最本质的组成部分。
• 任何敏捷实践导入的尝试，如果不包含技术实践，就注定会失败。

第6章 成就敏捷 133

6.1 敏捷的价值观 134

• 敏捷的4个价值观：勇气、沟通，反馈和简单。

• 6.1.1 勇气 134

• 维护高质量代码和高质量的纪律需要勇气。

• 通过牺牲质量来遵守时间表就是鲁莽。

• 质量和纪律会提高速度，这是一种信念。

• 强势但优质的人们在面对时间压力时会不断挑战这种信念，因此坚持正确的信念需要勇气。

6.1.2 沟通 134

• 重视面对面、非正式的人际对话。
• 坐在一起并经常交流的团队可以创造奇迹。

6.1.3 反馈 135

• 敏捷团队因反馈而健壮。
• 计划游戏、重构、测试驱动开发、持续集成、小步发布、代码集体所有、完整团队等实践最大化反馈的频率和数量。

6.1.4 简单 135

• 软件中的每个问题都可以通过添加间接层来解决。
• 保持代码简单。保持段对更简单。

6.2 怪物博物馆 136

• 导入完整的生命之环，特别要包含技术实践。
• 大多数的团队只导入了外圈的业务环，然后发现自己掉进了陷阱，马丁*福勒称之为“疲软的Scrum”。
• 生产力大量流失的原因在于代码本身的腐坏和恶化。

6.3 转型 137

• 敏捷开发的价值观包括勇于冒险、快速反馈、热情、人与人之间跨越障碍和指挥结构的频密沟通。

6.3.1 耍花招 138

6.3.2 幼狮 138

6.3.3 哭泣 139

6.3.4 寓意 139

6.3.5 假装 139

6.3.6 在更小的组织中成功 140

• 保持着直截了当、敢于冒险的精神。

6.3.7 个人成功和迁移 141

6.3.8 创建敏捷组织 141

6.4 教练辅导 142

• 目标是灌输明杰价值观及传授明杰纪律。
• 这个角色应该尽快从团队内部选拔出来。
• 队员会在无意中停止了结对、停止了重构，或者忽略了持续构建中的那些失败。教练的工作就是看到这些现象，并向全团队指出来。
• 教练是团队的良知，总是提醒团队对自己的承诺和一致同意必须秉持的价值观。
• 教练的角色完全是内部的。

6.5 认证 143

• 培训不应该集中在某个特定的角色上，而是应该针对团队中的每个人。
• 敏捷团队的每个成员都需要了解敏捷的价值观和技术。

6.6 大型组织中的敏捷 144

• 团队中包含 4～12 名软件开发人员。
• 敏捷是为中小型团队服务的，就这样。对于中小型团队，敏捷很有效。
• 敏捷从来不是为大型团队设计的。
• 我们不知道如何有效地组织一个相对较小的程序员团队来提高效率。敏捷解决的正是这个问题。
• 根本没有所谓的大规模敏捷。

6.7 敏捷工具 148

6.7.1 软件工具 148

• 软件开发人员必须掌握一些核心工具：
  • 至少一门编程语言，通常会是多门；
  • 一个集成开发环境（IDE）或者程序员使用的编辑器（vim、Tmacs 等）；
  • 各种数据格式（JSON、XML、YAML等）和标记语言（包括 HTML）；
  • 基于命令行和脚本与操作系统进行交互；
  • 源代码仓库工具（Git。除此之外还有其他的选项吗？）；
  • 持续集成/持续构建工具（Jenkins、TeamCity、GoCD等）；
  • 部署/服务器管理工具（Docker、Kubernetes、Ansible、Chef、Puppet等）；
  • 沟通工具--电子邮件、Slack、英语（！）；
  • 测试工具（单元测试框架、Cucumber、Selenium等）；

6.7.2 什么才是有效的工具 149

• 优秀的工具可以做到以下几点：
  • 帮组人们实现目标；
  • 可以很快到“足够好”的程度；
  • 对用户透明；
  • 允许适配和扩展；
  • 经济上负担得起。

6.7.3 物理的敏捷工具 151

6.7.4 自动化的压力 152

6.7.5 有钱人用的ALM类工具 153

6.8 教练——另一个视角 155

6.8.1 条条大路通敏捷 155

6.8.2 从过程专家到敏捷专家 156

6.8.3 对敏捷教练的需求 157

• 要想变的敏捷，需要重新审视根生蒂固的观念、文化、过程、思维和工作方式。
• 让一个人转变思维、帮组他看到“这对我有什么好处”。
• 变革能持续的关键在于：找到人们意识到并愿意投资的问题或者机遇，然后帮组他们实现目标。

6.8.4 将教练技术带给敏捷教练 158

• 《如何构建敏捷项目管理团队》-丽萨

6.8.5 超越ICP-ACC 158

6.8.6 教练工具 159

6.8.7 只有专业教练技巧是不够的 159

• 敏捷教练可以从六大专业领域中汲取知识：敏捷框架、敏捷转型、敏捷产品管理、敏捷技术实践、引导技术、教练技术。
• 添加新的功能时必须同时添加新的测试

6.8.8 在多团队环境中进行敏捷教练的工作 160

6.8.9 大型组织中的敏捷 161

6.8.10 使用敏捷和教练技术 来变得敏捷 161

6.8.11 敏捷导入的成长 162

6.8.12 细处着手成大事 164

6.8.13 敏捷教练的未来 165

6.9 结论（鲍勃大叔回来了） 165

第7章 匠艺 167

7.1 敏捷的宿醉 169

7.2 不孚所望 170

7.3 渐行渐远 172

7.4 软件匠艺 173

7.5 思想体系与方法论 174

• 没有实践的原则只是空壳，而没有原则的实践往往是没有判断力的死记硬背。
• 原则指导实践，实践具像化原则，两者齐头并进。

7.6 软件匠艺包含实践吗 175

• 自 2008 年创建以来，软件匠艺社区认为极限编程是当下的最佳敏捷开发实践集。

7.7 聚焦于价值而非实践 176

• 如果人们看不到价值，就不会改变他们的工作方式。

7.8 对实践的讨论 177

• 围绕实践的讨论应该是在合适的级别、与合适的人进行。

7.9 匠艺对个人的影响 178

• 正是通过软件匠艺社区，开发人员学习测试驱动开发（TDD）、集成测试、结对编程、简单设计、SOLID 原则、整洁代码和重构。

7.10 匠艺对行业的影响 179

7.11 匠艺对公司的影响 180

7.12 匠艺与敏捷 181

7.13 结论 182

第8章 结论 183

• 敏捷的本源从未变过。它们是罗恩*杰弗里斯的生命之环中的纪律，它们是肯特-贝克的《解析极限编程-拥抱变化》一书中的价值观、原则和纪律，它们是马丁-福勒的《重构：改善既有代码的设计（第 2 版）》一书中的动机、技术和纪律。

跋 185

索引 191