标签：5.1 1.3 6.3 本源 敏捷 2.2 整洁 6.8

• 第 1章 介绍敏捷 1
  • 1.1 敏捷的历史 3
  • 1.2 雪鸟会议 10
  • 1.3 敏捷全貌 14
    • 1.3.1 铁十字 15
    • 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.5 持续改进 50
    • 2.2.6 无畏之力 50
    • 2.2.7 QA应该什么也找不到 52
    • 2.2.8 测试自动化 52
    • 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
    • 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
• 第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
    • 5.1.2 TDD三规则 116
    • 5.1.3 调试 117
    • 5.1.4 文档 117
    • 5.1.5 乐趣 118
    • 5.1.6 完备性 119
    • 5.1.7 设计 121
    • 5.1.8 勇气 121
  • 5.2 重构 123
    • 5.2.1 红-绿-重构 124
    • 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
    • 5.4.5 只能两人吗 130
    • 5.4.6 管理 130
  • 5.5 结论 131
• 第6章 成就敏捷 133
  • 6.1 敏捷的价值观 134
    • 6.1.1 勇气 134
    • 6.1.2 沟通 134
    • 6.1.3 反馈 135
    • 6.1.4 简单 135
  • 6.2 怪物博物馆 136
  • 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
  • 6.7 敏捷工具 148
    • 6.7.1 软件工具 148
    • 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
  • 7.7 聚焦于价值而非实践 176
  • 7.8 对实践的讨论 177
  • 7.9 匠艺对个人的影响 178
  • 7.10 匠艺对行业的影响 179
  • 7.11 匠艺对公司的影响 180
  • 7.12 匠艺与敏捷 181
  • 7.13 结论 182
• 第8章 结论 183
• 跋 185
• 索引 191
• 第 4 章 团队实践
  • 4.5 站会
• 第 5 章 技术实践
  • 5.1 测试驱动开发

第 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

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

第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

5.1.2 TDD三规则 116

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

5.1.3 调试 117

5.1.4 文档 117

5.1.5 乐趣 118

5.1.6 完备性 119

5.1.7 设计 121

5.1.8 勇气 121

5.2 重构 123

5.2.1 红-绿-重构 124

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

5.4.5 只能两人吗 130

5.4.6 管理 130

5.5 结论 131

第6章 成就敏捷 133

6.1 敏捷的价值观 134

6.1.1 勇气 134

6.1.2 沟通 134

6.1.3 反馈 135

6.1.4 简单 135

6.2 怪物博物馆 136

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

6.7 敏捷工具 148

6.7.1 软件工具 148

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

7.7 聚焦于价值而非实践 176

7.8 对实践的讨论 177

7.9 匠艺对个人的影响 178

7.10 匠艺对行业的影响 179

7.11 匠艺对公司的影响 180

7.12 匠艺与敏捷 181

7.13 结论 182

第8章 结论 183

跋 185

索引 191

• 敏捷
  • 敏捷是将项目切分未迭代的过程。
  • 敏捷团队要测量每次迭代的输出，并用测量数据持续地评估时间表。
  • 按照业务价值排序来实现功能，以便优先实施最有价值的东西。
  • 他们尽可能地保持高质量，
  • 通过变更范围来管理时间表

第 4 章 团队实践

4.5 站会

第 5 章 技术实践

5.1 测试驱动开发

标签：5.1,1.3,6.3,本源,敏捷,2.2,整洁,6.8
来源： https://www.cnblogs.com/xulonglong/p/min-jie-zheng-jie-zhi-daohui-gui-ben-yuan.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。