前言
这本书既适合程序员也适合非程序员。它不是技术性的。没有代码。它旨在提供敏捷软件开发的原始意图的概述，而不涉及任何编程、测试和管理的深入技术细节。
这是一本小书。那是因为这个话题不大。敏捷是一个关于小型编程团队做小事情的小问题的小想法。敏捷不是关于大型编程团队做大事情的大问题的大想法。大事情不会由大团队来完成，大事情是由许多小团队协作完成的。
在过去的几年中，敏捷所传达的简单而微小的信息已经变得模糊不清。它混合了精益、看板、LeSS、SAFe、Modern、Skilled 等概念。这些想法还不错，但它们不是最初敏捷表达的信息。是时候记住敏捷到底是什么了。
在这本书中，你不会发现什么特别的新东西，没有什么令人吃惊的东西，没有什么革命性的东西打破常规。你会发现它是敏捷的一个重述，就像它在 2000 年被告知的那样。在过去的 20 年里，我们学到了一些东西，我将把它们包括在内。但总的来说，这本书传达的信息是 2001 年和 1950 年的信息。
这是一个古老的信息。这是一个真实的信息。它给了我们一个小的解决方案，解决小的软件团队做一些小事情碰到的小问题。
什么是敏捷
2001 年 2 月，在犹他州的 Snowbird 这个地方，由 17 位软件专家组成的小组谈论软件的糟糕状况发展。当时，大多数软件是使用低效的，繁重的，高礼节性的流程所构建的，例如 Waterfall 和 Rational Unified Process（RUP）。这 17 位专家的目标是创建一份宣言，介绍一种更有效、更轻量级的方法。
这绝非易事。这 17 个人有着不同的经历和强烈的不同观点。期望这样一个团体达成共识是不可能的。然而，尽管困难重重，大家还是达成了共识，并撰写了敏捷宣言，并且诞生了软件领域最具影响力和最持久的运动之一。
这样的运动在软件行业遵循可预测的路径。一开始有一小部分热情的支持者，另一部分热情的反对者，还有绝大多数的人并不关心。许多运动在那个阶段结束，或者至少永远不会结束。想想面向切面编程、逻辑编程或 CRC 卡。然而，有些跨越了鸿沟，变得格外受欢迎，也引起了争议。有些人甚至设法将争议抛诸脑后，而只是成为主流思想的一部分。面向对象就是后者的一个例子。敏捷也是如此。
不幸的是，一旦一个运动变得流行起来，它的名字就会因为误解和篡夺而变得模糊不清。与实际运动无关的产品和方法会借用名称，利用名称的知名度和重要性来赚钱。敏捷也是如此。
这本书是在 Snowbird 会议发生近 20 年后写的，其目的是澄清事实。这本书用尽可能务实的方式描述敏捷，没有废话，没有不确定的表述，没有不确定的术语。
这本书介绍了敏捷的基础。许多人美化和扩展了这些想法，这并没有错。然而，这些扩展和修饰都不是敏捷的。它们是敏捷加上其他的东西。你将在这里读到敏捷是什么，敏捷过去是什么，以及敏捷将不可避免地永远是什么。
敏捷历史
Winston Royce 在 1970 年写了一篇论文，在其中描述了自己对如何管理大规模软件开发项目的想法。论文中包含了如下的一张图。
由于这个图和瀑布很像，因此这种技术被人们以“瀑布”命名所熟知。
瀑布软件开发模式源自于科学管理，它通过分析、制定详细的计划、执行计划来完成软件开发。Winston Royce 并没有推荐瀑布软件开发模式，人们从他的论文中拿走了瀑布软件开发模式的概念，然后瀑布软件开发模式统治了接下来的 30 年软件开发模式。
由于软件开发的特殊性，我们几乎不可能在开始就做好软件需求分析，软件架构设计，因为需求一直在发生变化。
在 1994 年，我第一次见到了 Kent Beck ，在 1999 年我再次见到了 Kent Beck ，在这之后我了解到了 Kent Beck 的极限编程，然后被极限编程所吸引。极限编程中的想法很有颠覆性。我在自己的公司引入了极限编程的训练营。在 2000 年的夏天 Kent Beck 邀请极限编程社区和设计模式社区一起组织会议，称之为极限编程领导会议（XP Leadership），讨论接下来极限编程应该如何发展，其中有一个想法是围绕极限编程创建一个非盈利性的组织。我同意这个想法，但是其他人不太同意这个想法。我有点受挫的离开了那个会议，Martin Fowler 也跟了出来，建议我们可以之后在芝加哥再开会讨论，我同意了。
在 2000 年的秋天，我和 Martin 见面讨论决定组织一个轻量级工作流程会议（Light Weight Process Summit），我们决定邀请了很多人。在我们的受邀人中，Alistair Cockburn 告诉我说他也在准备组织类似的会议，他把他的邀请人和我们的邀请人进行了合并。如果我们同意在 Snowbird 滑雪场组织会议，他愿意为组织会议做跑腿活。所以会议就定在了 Snowbird 举行。
Snowbird
2001 年 17 位软件开发人员聚集在一起探讨寻找更好的软件开发方法，他们讨论得出了敏捷软件开发方法，并提出了如下的敏捷宣言：
- 个体和互动高于流程和工具。（Individuals and interactions over processes and tools）
- 工作的软件高于详尽的文档。（Working software over comprehensive documentation）
- 客户合作高于合同谈判。（Customer collaboration over contract negotiation）
- 响应变化高于遵循计划。（Responding to change over following a plan）
敏捷软件开发概览
项目管理铁十字原则
任何项目都只能从好、快、便宜、完成四个方面中选择三个。
现实中，好的项目管理者知道这四个方面可以有不同的系数，好的管理者带领着项目朝着足够好，足够快，足够便宜并且只完成必须功能的方向前进，他们不会把这四方面的系数都设置为 100%，这也是敏捷软件开发想要实现的管理方法。
敏捷软件开发就是这样一个帮助开发者和管理者执行这种实用项目管理的框架。
敏捷软件开发提供数据，管理者在做决策时需要的数据
团队速率图
团队速率图表示团队每个迭代完成的用户故事点数
燃尽图
燃尽图表示项目用户故事点数的变化情况
传统软件开发
老板确定了项目的截止日期。开会决定分析阶段所需时间、设计阶段所需时间、实现阶段所需时间。
分析阶段是一个很轻松欢乐的阶段，我们上上网，与客户聊聊天，当计划的时间结束时，我们结束了分析，“神奇”的完成了分析阶段。
设计阶段我们把项目分成多个模块，并设计它们之间的接口。当然，不可预知的事情也会发生，新的需求被添加进来，老的需求被移除或者修改，我们很想重新分析这些改变，但是由于时间紧迫，我们只能把这些改变 hack 进设计，当计划的时间结束，我们结束了设计，设计阶段也神奇的完成了。
实现阶段有明确的标准，我们没有办法来假装我们已经把实现阶段的工作做完了。在实现阶段，需求也在持续改变，新的需求会加入，旧的需求会被移除或修改。我们很想回去重新进行分析、重新设计这些改变，但是由于所剩时间不多，我们只能把这些改变一个接一个的 hack 进代码里。当我们回头把这些代码与设计对比时，发现我们的代码与设计与之前的设想已经相差甚远，但是我们已经没有时间去担心这些东西了。在与计划的交付日期还有两个星期时，我们告诉利益相关人（可能是经理、产品负责人、客户等），我们不能如期交付软件。你可以想像下利益相关人会作何反应。
最后我们压力倍增，继续完成未完成工作，这个阶段被称为死亡行军阶段（The Death March Phase）。我们告诉自己之后再也不会像这样一样做项目，下一次我们会做更多的分析，更多的设计。结果还是一样，因为我们的方法错了。
瀑布开发模式并不会摧毁每一个项目，但是它仍然是一种灾难性的软件项目开发方式。
敏捷软件开发
项目开始于分析，但是分析从来都不会停止，我们把时间分隔正常的增量的小段，我们称它为迭代（iterations）或者冲刺（sprints），右侧是截止时间。迭代通常为一周或者二周。
第一个迭代通常被称为迭代 0，用来产生需求列表，被称作用户故事。迭代 0 也用来建立开发环境，评估用户故事，制定初步计划，该计划只是将故事分配给最初的几个迭代。最后，迭代 0 被开发人员和架构师用来根据暂定的故事清单来构想系统的初始暂定设计，编写用户故事，评估用户故事，计划用户故事和架构设计永远不会停止。每一个迭代的任何时间，都会有一些分析、设计与实现，在敏捷软件开发中，我们一直在分析和设计。迭代并不是一个小瀑布。
迭代 1 从评估本次迭代计划完成多少用户故事开始，然后团队开始工作，完成用户故事。在迭代结束时，我们完成了部分用户故事，这是我们对一次迭代中可以完成数量的首次测量，这是真实的数据，如果我们假定我们每一个迭代都相似，然后我们就可以调整我们的原始项目计划，重新计算一个新的项目完成日期。这可能会严重超过我们之前计划的截止时间，但这至少是真实数据，但是也不用太过认真，因为这仅仅是第一次迭代数据，随着迭代的进行，团队完成的点数，可能会变化，我们的调整可能会持续进行，直到它非常的稳定。
让他们失去希望是敏捷软件开发的主要目标，我们采用敏捷的目的就是为了在希望杀死项目之前摧毁希望，因为希望会导致团队误导管理者看不到项目的真实进度。敏捷软件开发引导项目走向最好的可能结果，可能这并不是最想要的结果，但这就是最好的可能结果。
管理铁十字原则
项目管理者需要决定项目应该多好，多快，多便宜和完成多少功能。通常管理者可以调整范围、时间、人员和质量。
改变时间，但有时因为商业原因，时间并不能更改。
增加人员，有数据表明增加人员的前几周并不能提高生产力，反而会降低生产力，后面生产力会逐渐增加。你只能寄希望于后面会补上前面丢失的生产力，并且增加人员，通常会增加预算。
降低质量，我们都知道通过停止写测试、停止做代码评审、停止做重构，仅仅写生产代码，可以加快速度。但是事实并不是这样的，不做这些看似没用的事情，不仅不会加快速度，反而会降低速度。如果你想走的更快，你应该先走好。如果你想减少项目时间，唯一的选项就是提高质量。
改变范围，有些需求可能并不需要在截止时间内完成。
业务价值优先级
我们会问利益相关者下一个我们应该实现的需求，我们只做利益相关者要求我们做的需求
上面描述的只是敏捷软件开发的大概，但这是敏捷的要点。每一个迭代的输出都是可以衡量的，用于持续评估时间表，需求按业务价值的顺序来实现，质量保持尽量的高，时间表主要靠改变需求范围来调整，这就是敏捷。
Circle of Life
XP（Extreme Programming）中文被译为极限编程。它最符合敏捷软件开发的要求。Ron Jeffries 总结了 XP 的实践图，这个图被亲切的称为 “Circle of Life” 。
外圈的环是面向业务的实践，本质上相当于 Scrum 。它提供了软件开发人员与业务人员的沟通框架，并且还提供了软件开发人员和业务人员管理项目的原则。
中间的环是面向团队的实践，这些实践提供了开发团队内部沟通和自我管理的原则和框架。
内圈的环代表了技术实践，指导和限制程序员保证尽可能高的技术质量。
总结
敏捷就是用小的纪律帮助小团队管理小项目。
为什么要采用敏捷
在我们深入讨论敏捷开发的细节之前，我想先解释一下其中的利害关系。敏捷开发不仅对软件开发很重要，而且对我们的行业、社会和最终的文明都很重要。
开发人员和管理人员常常因为一些短暂的原因而被敏捷开发所吸引。他们可能会尝试，因为他们只是觉得这样做是对的，或者他们可能会相信速度和质量的承诺。这些原因是无形的，模糊的，很容易挫败。许多人放弃敏捷开发仅仅是因为他们没有立即体验到他们认为的敏捷承诺的结果。
这些稍纵即逝的理由并不是敏捷开发重要的原因。敏捷开发对于更深层次的哲学和伦理原因非常重要。这些原因与我们的专业和客户的合理期望有关。
专业主义
软件已经遍布我们生活的方方面面，我们统治了世界，我们的软件错误可能会给其他人带来灾难，我们应该更专业。
合理的期望
- 我们不制作质量不合格的软件。
- 软件一直处于技术就绪状态，软件可以随时发布。
- 稳定的软件生产效率，我们开发软件的速率稳定。
- 廉价的适应性，软件应该易修改。
- 持续改进，软件应该是持续改进的。
- 无所畏惧的能力，当我们修改代码时，我们需要有机制给我们足够的信心。
- QA 应该找不到任何 BUG，当 QA 检查软件时，开发团队应该让 QA 找不出任何 BUG。
- 测试应该自动化。
- 开发人员之间的工作应该可以随时交换，保证每个人的工作都可以交由其他人来完成，防止突发情况。
- 诚实的用户故事时间评估。
- 在必要时说不，我们是专业的，我们应该在不合理的地方说不。
- 持续积极的学习。
- 指导别人，与别人一起相互指导学习。
权力法案
客户权利法案
- 你有权利制定一个全面的计划，知道什么时候可以完成什么事情，要付出什么代价。
- 你有权从每个迭代中获得最大可能的价值。
- 你有权查看正在运行的系统的进展，并通过指定的可重复测试来验证其有效性。
- 你有权利改变你的想法，替换功能，改变优先级而不付出过高的成本。
- 你有权获知日程安排和评估变更，及时选择如何缩小范围以满足所需日期。你可以随时取消项目，并留下一个有用的可工作的系统，反映投资到目前为止的软件。
开发者权利法案
- 你有权利知道什么需求是需要的，并带有明确描述与优先级。
- 你有权在任何时候都做出高质量的作品，业务不能强迫你降低质量。
- 你有权向同事、经理和客户寻求帮助并接受他们的帮助。
- 你有权作出和更新自己的评估，你可以在发现新因素时更改估算值，评估并不是承诺。
- 你有权利接受你的责任，而不是被分配给你，你有权力拒绝。
总结
敏捷是一个支持专业软件开发的纪律框架。敏捷不是一个流程，也不是时尚，也不仅仅是一些规则的集合。敏捷是一组权力、期望和纪律，它们构成了职业道德的基础。
业务实践
为了取得成功，开发必须遵循大量面向业务的实践。这些包括计划、小版本发布、验收测试和团队协作。
计划
项目时间评估
如果你想要一个准确而又精确的项目时间评估，你就需要把项目逐步分解，分解到越小越好，你甚至可以分解到单独的实现代码行数。你做这些的时间就是项目的精确预估时间，因为你所做的这些就是在开发实现一个软件。
评估就是猜测，我们想在不实际开发这个软件的情况下，猜测项目会花费的时间，所以这肯定是不精确的，想更精确，你花费在评估上的时间就要更多，这需要我们自己选择。
关于评估我们可以了解三变量评估和 PERT 评估方法。
用户故事与点数
用户故事是从用户的角度描述系统特性的简短描述，例如：作为一名汽车司机，为了提高我的速度，我会更用力地踩油门踏板。（As the driver of a car, in order to increase my velocity, I will press my foot harder on the accelerator pedal）
通常，我们把故事写在索引卡上，不一定非要使用软件工具。
ATM 用户故事示例
用户故事
- 取钱（Withdrawal）
- 存钱（Deposit）
- 转账（Transfer）
- 登录（Login）
- 登出（Logout）
在迭代 0，我们团队写出了以上的 5 个用户故事， 我们也讨论了这些用户故事的细节，比如用户使用密码登录等，但是我们不相信这些细节，我们没有把他们写在故事卡上，我们在故事卡上只写了上面简短的单词。
用户故事评估
现在有了用户故事，开发、测试、项目管理或其他利益相关者一起开会来进行用户故事的评估，这样的会议会很多，每当有新的用户故事或者对之前的用户故事有了新的理解时，我们就会开用户故事评估相关的会议，这个会议是非正式的，每个迭代都会进行。
由于这是第一次用户故事评估，我们选择一个我们认为复杂度平均的用户故事来开始进行评估，我们选择登录用户故事，我们要求利益相关者回顾之前讨论的细节，这样我们就都能了解上下文，之后我们为这个用户故事选择一个数字 3，为什么是 3 呢？登录用户故事是一个平均故事，所以我们给它一个平均的数字，如果我们选择 1 到 6 来表用户故事评估，那 3 就是那个平均数字。
登录用户故事现在是我们的 Golden Story，之后所有的用户故事都会与之比较来进行评估，因此我们得出如下评估，登出 1、取钱 6、存钱 5、转账 3，我们把用户故事评估写在用户故事卡上。
用户故事的评估的数字并不表示周、天、时等其他时间单位，它只是个相对数字，只是表示需要付出努力的单位，和实际时间没有关系，可能有的人需要一天，有的人需要两天。
计划迭代 1
迭代以迭代计划会议（Iteration Planning Meeting (IPM)）开始，这个会议应该花费大约整个迭代 1/20 的时间，所有的团队成员都需要参加这个 IPM 会议，包括利益相关者、程序员、测试、项目经理。利益相关者查看用户故事，并按业务价值给它们排序。
利益相关者的主要工作是选出程序员和测试人员在这个迭代将要完成的用户故事，因此，他们需要知道程序员认为他们能完成多少，这个数字就是速率，由于这是第一个迭代，我们并不知道速率，所以我们随便猜一个数字，比如：30。
必须要说明的是，速率并不是承诺，他们甚至不是试着去完成 30 点，它只是个猜测。
投资回报
ROI （return on investment）和用户故事优先级评估。
中点检查
在迭代的时间中点，我们发现我们只完成了 10 点，那利益相关者就需要从迭代中去除 10 点的用户故事。
到迭代结束可能只完成了 18 点，但这并不表示这个迭代失败了，一个迭代的目的是为了给管理者产生数据。
昨天的天气
现在我们知道了我们一个迭代可以完成 18 点，在下一个迭代我们应该计划 18 点。
今天天气的最佳预报是昨天的天气，迭代进展的最佳预测器是前一个迭代。
在 IPM 会议上，利益相关者选择 18 点的用户故事，这一次可能奇怪的事情发生了，在这个迭代，中点检查时发现已经完成了 12 点，因此利益相关者又增加了 6 点用户故事，总计划 24 点，可能结果我们完成了 22 点，因此下一个迭代就设置为 22 点。
项目结束
随着迭代持续进行，速率被持续增加到速率图中，每个人都知道我们有多快。
可能到了某个阶段，项目并没有实现所有的用户故事，但是项目却结束了，因为根据 ROI 原则，已经没有更多的用户故事值得去实现了，最早被写出来的用户故事的重要性可能早已消失不见了。
用户故事
用户故事应该遵循 INVEST 原则：
- I: Independent 独立，用户故事之间应该相互独立，这表示他们不需要以特定的顺序实现，登出不能要求登录先实现。
- N: Negotiable 可协商，开发者可以和业务协商具体细节。
- V: Valuable 有价值，用户故事必须对业务具有清晰和可量化的价值。
- E: Estimable 可评估，用户故事必须具体到开发者可以评估。
- S: Small 足够小，用户故事不应该大到需要一到两个开者一个单独迭代还不能实现。
- T: Testable 可测试，业务应该能够清晰地写测试，以证明故事已经完成。
用户故事评估
方法 1：Flying Fingers
开发者坐围着桌子坐，阅读用户故事并与利益相关者讨论（如果需要的话），然后开发者在背后伸出手指数量，然后所有开发者同时亮出手指，某个人统计所有开发者表示的点数，如果分歧很小并且有一个明显的平均值，记录下用户故事的评估，如果不统一，再次讨论，再次进行打分。
- 大拇指向下表达 0
- 大拇指向上表达 ∞
- 打开手掌表达 ?
方法 2：Planning Poker
通常使用斐波那契数列，?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞。
- 0 表示太过琐碎无法评估，可以把几个用户故事合并。
- ∞ 表示太大无法评估，用户故事应该被拆分。
- ? 表示你不知道，你需要一个 spike。
Spike
一个 spike 是一个元故事，或者更确切地说，是一个用来估计一个故事的故事。你需要先去了解这个技术，然后才能对当前的故事做出评估，例如：你可以写一个用户故事为评估打印 PDF。
管理迭代
每一个迭代的目的是通过完成用户故事来产生数据，团队应该着力于用户故事，而不是用户故事里的任务，完成了 80% 的用户故事，远好于把每个用户故事都完成了 80%。
管理者不要分配用户故事，而应该让他们自己来协商选择用户故事。
验收测试应该尽早写，尽量在迭代中点之前完成所有验收测试代码，QA 应该和程序员紧密配合。
真正的完成就是验收测试通过。
小版本发布
小步快跑，才能跑的更快。把发布和部署分开，发布表示软件已经准备就绪，可以部署，部署只是业务方面的决定。
验收测试
验收测试是最少被理解、最少被使用、最混乱的敏捷实践。其基本思想非常简单：需求应该由业务来指定。
验收测试是一种规范，它也是一个测试，例如：当用户输入有效的用户名和密码，然后单击登录，系统将显示欢迎页面。
工具和方法
- FitNesse, JBehave, SpecFlow, Cucumber
- BDD(Behavior-Driven Development)
实践
验收测试由业务分析人员和 QA 在迭代中点之前编写。开发人员把这些测试集成进持续构建。这些测试就是用户故事完成的定义，只有通过这些测试才表示用户故事完成。
业务分析人员指定正常业务路径，QA 编写异常业务路径，开发者与业务分析人员和 QA 一起确保从技术角度来看这些测试是有意义的。
QA 不在是在最后阶段才进入保证质量，他们在每一个迭代的开始就介入开发团队来阻止错误和遗漏，最后他们来决定软件是否可以部署。
运行测试的工作应该由程序员来做，只有运行测试通过才表示他们的用户故事完成了，当然程序员可以通过持续构建来自动化这一测试过程。
团队协作
- 团队所有成员应该坐在一起工作。
- 保证团队可以随时面对面交流。
- 远程办公也是可以的，只要能实时面对面沟通即可。
总结
敏捷想打破业务和开发团队之间的鸿沟，让业务和开发能更好的合作，面向业务的实践在满足这个目标方面扮演了重要的角色。通过遵循这些实践，业务和开发有了一种简单而明确的沟通方式。这种交流产生了信任。
团队实践
Ron Jeffries 的 Circle of Life 中间部分由敏捷团队实践组成。这些实践控制着团队成员之间以及他们所创建的产品之间的关系。我们将讨论的实践包括隐喻、可持续的速度、集体所有制和持续集成。
然后，我们将简要讨论所谓的站立会议（Standup Meetings）。
隐喻
寻找可以形象比喻项目或者项目中模块组件的词语，然后团队使用这个词语交流。领域驱动设计（Domain-Driven Design）使用统一语言（Ubiquitous Language）方便团队交流。
可持续的速度
- 开发团队可持续的开发速度很重要。
- 通过加班来提高开发速度不可持续，可能会在加班期间做错误的决定，写错误的代码，最后反而会起反效果。
- 软件开发是一个马拉松过程，我们不能在早期就把体力用的过快，我们要维持可持续的速度。
- 开发工作不是体力劳动，加班并不能说明你工作努力且专业。
- 要保证有足够的睡眠。
- 偶尔加班是可以的，但这不能是常态。
集体所有制
代码集体所有，任何人随时都可以查看获取修改代码。
持续集成
- 尽早的进行代码集成，尽早的发现错误，修改错误。
- 持续集成的极致是每次的代码提交都进行集成。
- 当持续集成失败时，所有人都不能提交代码，直到持续集成被修复。
- 当持续集成失败时，可以发报警邮件，甚至可以设置报警灯和报警声音。
每日站会
指导原则
- 会议是可选的。
- 可以不用每天都开，有意义时才需要开。
- 会议应该小 10 分钟，即使大团队。
发言规则
- 上次会议到现在我做了什么。
- 到下次会议之前我会做什么。
- 我碰到了什么困难。
会议上不允许讨论，不允许深入解释。每个人都可以发言，包括经理等，只要他们遵守规则。你也可以在会议是感谢给你帮助的其他人。
总结
敏捷就是一组原则、实践和纪律，帮助小的团队构建小的软件项目，本章节的实践帮助小团队表现的像一个真正的团队。帮助团队构建他们的交流语言，以及团队成员如何对待彼此和他们正在构建的项目的期望。
技术实践
本章中描述的实践与过去 70 年中大多数程序员的行为方式大不相同。它们强制执行一组深刻的、以分钟为单位的、以秒为单位的行为，大多数程序员最初都会认为这是荒谬的仪式性行为。因此，许多程序员试图在没有这些实践的情况下实现敏捷。然而，他们失败了，因为这些实践是敏捷的核心。没有 TDD，没有重构，没有简单设计，甚至没有结对编程，敏捷就变成了一个没有效率的松散外壳。
测试驱动开发（Test-Driven Development）
先写测试代码，然后编写生产代码让测试通过，然后重构改善代码。
当使用 TDD 时，每一个需要的行为都被输入了两次，一次作为测试，一次作为使测试通过的生产代码，它们是互补的，当一起执行的时候，产生 0 结果，0 个测试失败。
TDD 三原则
- 在编写失败的测试代码之前，不要写任何生产代码。
- 在有测试失败的情况下不要再写测试代码，编译失败也是失败的测试。
- 只编写足够的生产代码来让测试通过。
没有经过数月练习 TDD 的程序员可能觉得这些原则有些怪异，甚至无法接受。
使用 TDD 的程序员很少 Debugging，因为新的代码都是几分前引入的，那么错误也就是这段时间引入的，很容易找到出错的代码。
如果你遵循了 TDD 原则，你写的测试可能就是软件最好的文档，测试里有软件或者库的多种使用方式。
每一个新测试都是一个挑战，每一次你写代码让测试通过，你就完成了一个挑战，这样一直下去你会感觉这不像忙碌的工作，感觉像让东西工作起来。
遵守三原则会给你一个完善的测试套件，但是这并不是 100% 完整的，并不是只有达到 100% 代码覆盖率才能进行软件部署，90% 的覆盖率已经很不错了，不要把代码覆盖率当作目标和管理指标。
由于先编写测试，你需要让你们代码更容易测试，因为松耦合的代码更容易测试，所以你需要解耦代码，这样你的代码设计也会更好。
由于测试比较完整，当你看到需要改善的代码时，你可以放心的修改它，因为有测试代码帮你验证，你的改动有没有影响到之前的功能。
重构（Refactoring）
在不改变软件外在行为的情况下，改善代码的内部设计。
重构与 TDD 密切相关，为了不害怕重构代码，我们需要完整的测试来给我们非常高的信心，以保证我们的修改不会破坏之前的功能。
红绿重构
- 首先，我们创建一个失败的测试。
- 然后，我们编写代码让测试通过。
- 然后， 我们重构让代码变的整洁。
- 回到开始的步骤。
我们不预留时间来进行大的重构，我们以一次一小步的方式的迁移代码，同时继续添加新功能，这个改变可能会持续数天、数周甚至数月，在这期间，系统可以一直通过测试，并且可以部署到生产环境。
简单设计（Simple Design）
Kent Beck 的简单设计原则
- 通过所有测试：完成所有功能。
- 表明意图：之后要考虑重构让代码能表达程序员的意图，代码要易于阅读，自描述。
- 去除重复：之后要考虑重构去除重复代码，可能会使用到设计模式等。
- 减少元素：最后考虑减少代码元素，比如类、函数、变量等。
设计的重量
设计越复杂，程序员的认知负担就越大，程序员就越难理解和操作系统，这就是设计的重量。程序员持续重构系统来保持需求与简单设计的平衡，保持最大的生产力。
结对编程（Pair Programming）
两个人在同一个编程问题上工作，他们可能分享屏幕、键盘和鼠标，只要他们看和操作同一块的代码即可。结对编程有时会用不同的角色。
- 一个是司机，一个是导航员，司机有键盘和鼠标，导航员会有更长远的视角并给出建议。
- 一个程序员写测试代码，别一个程序员写生产代码让测试通过，然后交换角色继续。
- 最常见的情况是根本没有角色。程序员只是以协作的方式共享鼠标和键盘的作者。
结对编程不是按期进行的，程序员根据自己的偏好来决定。结对编程是短期的，一次结对编程可能持续一天，但是通常情况下不会多于一到两个小时。
用户故事不是分配给结对编程的，用户故事是分配给独立的开发者的。
在一周的时间内，每个程序员将花费大约一半的结对时间来完成自己的任务，并寻求其他几个人的帮助。另一半的配对时间将用于帮助其他人完成任务。
高级程序员应该注意与低级程序员结对编程，而不是与其他高级程序员结对编程。低级程序员应该更多地请求高级程序员的帮助。
具有专业技能的程序员应该花费大量的结对时间与他们专业以外的程序员一起工作。目的是传播和交换知识，防止形成知识简仓、知识孤岛。
结对编程是在团队成员之间共享知识和防止知识孤岛形成的最佳方式。
结对编程能减少了错误并提高设计质量。
结对编程是另一种形式的代码评审。
结对编程可能会多花 15% 的编码时间，一个简单的计算表明，一个团队 50% 的时间是结对的，那么它的生产力就会降低 8% 以下。另一方面，如果结对的实践代替了代码评审，那么很可能根本不会降低生产率。
结对编程并不只能有两个人。
管理者不要干涉结对编程，相信程序员。程序员也永远不要向管理者请求结对、测试和重构的时间，你是专家，你应该自己决定。
总结
敏捷的技术实践是任何敏捷工作中最重要的组成部分。任何没有技术实践的敏捷实践尝试都注定要失败。原因很简单，敏捷是一种高效的机制，可以在很短的时间内把事情搞得一团糟。如果没有技术实践来保持高技术质量，团队的生产力将很快衰退并开始一个不可避免的死亡螺旋。
实施敏捷
当我第一次学习 XP 时，我想，还有什么比这更容易的呢？只需遵循一些简单的原则和实践。仅此而已。
然而，基于尝试敏捷却失败的组织的数量，成为敏捷肯定是非常非常困难的。也许所有这些失败的原因是许多组织都错误的认识了敏捷，他们认为的敏捷和敏捷原本的思想不同。
敏捷价值
勇气
部署最小的特性集需要勇气，维护高代码质量和高质量纪律也需要勇气。认为质量和纪律可以提高速度的信念是一种勇敢的信念，因为它将不断受到有权势但天真的人的挑战。
沟通
团队各成员可以更方便的面对面的、非正式的、人际间的对话。一个坐在一起并且交流频繁的团队可以创造奇迹。
反馈
敏捷原则实际上都是为那些需要做出重要决策的人提供快速的反馈。它们使我们能够尽早判断出什么时候出了问题，以便及时纠正。敏捷团队在反馈中茁壮成长。反馈是使团队高效工作的因素，也是推动项目取得有益成果的因素。
简单
简单性是指代码的直接性，以及沟通和行为的直接性。在代码中，一定数量的间接是必要的。间接是我们减少相互依赖复杂性的机制。在团队中，更少的间接是必要的。大多数时候，你想要尽可能的直接。保持代码简单，让团队更简单。
怪物博物馆
众多的敏捷方法可能让你眼花缭乱，无论选择哪种方法，最终都将调整它以满足自己团队的需要。我所能给你的最有力的建议是充分采纳 Circle of Life，尤其是技术实践。选择一个方法，或者不选。确保你充分采纳了 Circle of Life。让团队同意。然后开始，记住勇气、沟通、反馈和简单，并定期调整规则和行为。不要请求许可。不要强调要把事情做好。只要在问题出现时解决它们，并继续将项目推向最佳结果。
转型
敏捷的价值观与中层管理的职责完全相反，高管也常常被敏捷的冒险、直接、交流的价值观所驱动。这是他们试图转型的原因之一。障碍是中间的管理层。这些人被雇佣来不承担风险，避免直接，以最少的沟通来遵循和执行命令链。这就是组织的困境。组织的顶层和底层重视敏捷思维，但是中间层反对它。
敏捷团队能够存在于一个拥有强大的反对敏捷的中层管理层的组织中吗？我曾见过这种情况。一些软件开发团队悄悄地使用敏捷价值来驱动他们的开发，同时也遵从中层管理强加给他们的严格要求。只要中层管理人员对他们遵循的过程和标准感到满意，他们就可以让开发团队自行处理。团队在幕后执行敏捷，同时提供满足中级管理层的一切。这些团队并没有与中层管理者进行一场徒劳的战斗，而是在敏捷之上增加了一层，使得敏捷看起来更安全，更符合中层管理者的需求。
敏捷转型在小的组织中更容易成功。
教练
敏捷培训师教导团队如何以敏捷的方式管理自己，他们经常是从企业外部人员或者团队外部人员。他们的任期应该很短。每个由十几个开发人员组成的团队应该只需要一到两周的培训。其他的一切他们需要学习的都要自学，不管敏捷培训师说什么或做什么。
敏捷教练不是培训师。他们是团队的成员，他们的角色是在团队中维护流程。在开发的高峰期，开发人员可能会不遵守敏捷流程。也许他们无意中停止了结对，停止了重构，或者忽略了连续构建中的失败。教练的工作就是看到这一点并把它指出来。教练作为团队的良心，总是提醒团队他们对自己的承诺和他们同意持有的价值观。
在一个团队转变的早期，培训师可能会临时填补教练的角色，但这是一个临时的情况。这个角色应该尽快在团队中选择，该角色通常根据需要按照非正式的时间表从一个团队成员轮换到下一个成员。一个成熟的团队稳步前进不需要教练。另一方面，一个团队在某种压力下，无论是日程安排、业务，还是人际关系，可能会决定让某个人暂时填补这个角色。
教练不是经理。教练不负责预算或时间表。教练不指导团队，也不向管理层代表团队的利益。教练不是客户和开发者之间的联络人。教练的角色是团队内部的。经理和客户都不知道教练是谁，甚至不知道现在是否有教练。
认证
现有的敏捷认证完全是一个笑话，完全是荒谬的。不要把认证当回事。伴随认证项目的培训通常是值得的。然而，培训不应该专注于一个特定的角色，它应该适合团队中的每个人。
一个真正的敏捷认证项目应该是什么样的?这将是一个学期的课程，包括敏捷培训和一个小型敏捷项目的监督开发。这门课将被评分，学生们将被严格要求。认证人员将确保学生理解敏捷的价值，并在执行敏捷规程方面表现出熟练。
大型敏捷
敏捷团队只是众多需要在大型项目中协调的团队之一。不同团队的整合是一个已经解决的问题。我没有看到任何迹象表明软件团队的唯一性会过度地影响到他们对大型团队的集成。
在大范围内不存在敏捷这样的事情。敏捷是组织小型软件团队的必要创新。但是一旦组织起来，这些团队就适应了大型组织使用了数千年的结构。
敏捷工具
充分了解工具，才能用好工具，使用不当的工具甚至会对项目及其操作者造成伤害。
好的工具应该有如下特性：
- 帮助人们实现他们的目标。
- 能很快学好。
- 对用户透明。
- 允许适配和扩展。
- 可负担得起。
物理敏捷工具。敏捷使用者以使用白板、胶带、索引卡、记号笔和各种大小的便利贴(小的和翻页的)来对工作进行可视化管理而闻名。这些简单的手工工具具备所有伟大工具的品质：
- 它们有助于使正在进行的工作可见并易于管理。
- 它们是符合直觉的，不需要训练。
- 它们只需要微不足道的认知开销。你可以在专注于其他任务时轻松地使用它们。
- 它们都不是专享的。这些工具都不是专门为管理软件开发而设计的。
- 它们适应性好。你可以用胶带或油灰粘在上面，把图片或图标夹在上面，把其他的指示符粘在上面，通过新颖的自定义颜色和图标来增加意义上的细微差别。
- 它们都很便宜，很容易买到。
使用自动化工具的压力：
- 软件工具提供了一种帮助确保以一致的形式捕获数据的好方法。
- 使用一致捕获的数据，您可以轻松地获得看起来很专业的报告、图表和图形。
- 提供历史记录和安全存储很容易。
- 你可以立即与每个人共享信息，无论他们居住在哪里。
- 使用在线电子表格之类的工具，你甚至可以让一个完全分布式的团队实时协作。
考虑到大多数 ALM（Agile Lifecycle Management） 工具的当前状态，从物理工具开始可能更安全、更明智。之后，你可以考虑使用 ALM 工具。确保学习速度快，日常使用透明，容易适应，并在你的能力范围内获得和运行。最重要的是，确保它支持您的团队的工作方式，并为您的投资提供积极的回报。
教练（另一种观点）
敏捷教练带领团队走向敏捷。
总结
在很多方面，这一章更多的是关于不做什么，而不是做什么。也许这是因为我见过太多不去敏捷的例子。但是，我仍然认为，就像我 20 年前想的那样，还有什么比这更容易的呢?只需遵循一些简单的原则和实践。仅此而已。
匠艺
兴奋。这就是许多开发人员第一次听说敏捷时的感受。对于我们大多数来自软件工厂和瀑布思想的开发人员来说，敏捷是解放的希望。我们希望在一个协作的环境中工作，我们的意见能够得到倾听和尊重。我们将有更好的工作流程和实践。我们将在小的迭代和短的反馈循环中工作。我们将定期将应用程序发布到生产环境中。我们会与用户互动并得到他们的反馈。我们会不断地检查和调整。
一开始，我们觉得敏捷好得让人难以置信。我们认为我们的公司永远不会接受敏捷思维，更不用说敏捷实践了。但他们大多数人都这么做了，我们对此感到非常惊讶。突然，一切都变了。我们有产品 backlog 和用户故事，而不是需求文档。我们有物理看板和燃尽图，而不是甘特图。我们有便利贴，我们每天早上根据进度来移动它们。这些便利贴有一种强大的力量，它能引发一种深深的心理瘾。他们是我们敏捷性的代表。我们贴在墙上的便签越多，我们就越觉得自己敏捷。我们变成了一个 Scrum 团队，而不是一个构建团队。我们再也没有项目经理了。我们被告知我们不需要管理，我们的经理将成为产品所有者，我们将自我管理。我们被告知，产品所有者和开发人员将作为一个单独的团队密切协作。从现在开始，作为 Scrum 团队，我们不仅被授权做出技术决策，还被授权做出与项目相关的决策。我们是这么想的。
敏捷席卷了软件行业。但是，就像在中国的耳语游戏中一样，最初的敏捷思想被扭曲和简化了，在公司看来，这是一个更快交付软件的过程的承诺。对于使用瀑布或 RUP 的公司和管理人员来说，这就是他们喜欢的音乐。经理和利益相关者都很兴奋。说到底，谁不想变得敏捷呢?谁不想更快地交付软件呢？即使是持怀疑态度的人，也不能拒绝敏捷。如果你的竞争对手在宣传他们是敏捷的，而你不是，那么这又会给你带来什么呢？你的潜在客户会怎么看你？公司不能承担不敏捷的后果。在敏捷峰会之后的几年里，全世界的公司都开始了他们的敏捷转型。敏捷转变的时代已经开始了。
敏捷的宿醉
敏捷的转变过程并不容易，公司需要借助外部的帮助，敏捷教练这一职位的数量大量需要，出现了许多敏捷相关的认证，这其中的大多数证书都很容易获得。
向中层经理推销敏捷过程很容易，他们都希望软件能够更快地交付。经理们被告知，工程是容易的部分，如果我们修正了流程，工程就会被修正。这一直是人的问题。然后经理们相信了。
希望推动开发人员更快工作的管理人员正在使用过程的完全透明性来对他们进行微管理。既没有业务经验也没有技术经验的敏捷教练是在指导经理并告诉开发团队该做什么。路线图和里程碑是由经理定义的，并强制开发团队开发人员可以评估工作，但是他们很难将自己的评估纳入强加的里程碑中。在接下来的 6 到 12 个月中，经常可以看到项目的所有迭代和各自的用户场景已经被管理层定义。未能在 sprint 中交付所有的故事点意味着开发人员必须在下一个 sprint 中更加努力地工作以弥补延迟。日常的站立会议变成了开发人员必须向产品负责人和敏捷教练报告进展的会议，详细说明他们正在做什么，什么时候完成。如果产品负责人认为开发人员在自动化测试、重构或结对之类的事情上花费了太多时间，他们只会告诉团队停止这样做。战略技术工作在他们的敏捷过程中没有地位。不需要架构或设计。顺序是简单地将重点放在待办事项列表中优先级最高的项上，然后尽快完成一个又一个优先级最高的项。这种方法导致了一长串迭代的战术工作和技术债务的积累。脆弱的软件，著名的单体(或尝试微服务的团队的分布式单体)成为规范。bug 和操作问题是日常站立会议和回顾会议中的热门讨论主题。发布到产品中的频率不像业务预期的那么频繁。手工测试周期仍然需要几天(如果不是几周的话)才能完成。采用敏捷可以避免所有这些问题的希望已经破灭了。经理们指责开发人员行动不够迅速。开发人员指责管理人员不允许他们完成所需的技术和战略工作。产品负责人不认为自己是团队的一部分，当事情出错时也不承担责任。“我们对他们”的文化占据了主导地位。这就是我们所谓的敏捷宿醉。 经过多年的敏捷转型投资，公司意识到他们仍然遇到许多以前的问题。 当然，敏捷也因此而受到指责。
期望不匹配
纯粹关注过程的敏捷转换是部分转换。虽然敏捷教练试图通过敏捷过程来指导经理和交付团队，但是没有人帮助开发人员学习敏捷技术实践和工程。修正人们之间的协作将改进工程的假设是大错特错的。
敏捷的采用带来了一个很大的期望：开发团队应该在完成一个特性时，或者至少在每次迭代结束时，交付准备好生产的软件。对于大多数开发团队来说，这是一个重要的变化。如果不改变他们的工作方式，他们是不可能做到这一点的，这意味着学习和掌握新的实践。但也有一些问题。在敏捷转换期间，很少有用于提高开发人员技能的预算。业务部门并不期望开发人员在采用敏捷时放慢速度。大多数人甚至不知道开发人员必须学习新的实践。他们被告知，如果他们以一种更协作的方式工作，开发人员的工作速度会更快。
认为团队仅仅通过创建一个更具协作性的环境来开发这些技能是不现实的。团队在获取这些技术技能时需要支持。这种支持可以通过指导、培训、实验和自学的结合来实现。业务敏捷性与公司发展软件的速度直接相关，这意味着他们的工程技能和技术实践的发展。
远离
对于一些采用敏捷管理的公司，尽管公司确实比以前更好了，但是敏捷过程和工程之间的分歧仍然在伤害着他们。大多数现代敏捷教练没有足够的(如果有的话)技术技能来指导开发人员进行技术实践，而且他们很少谈论工程。多年来，开发人员开始将敏捷教练视为另一层管理：人们告诉他们做什么，而不是帮助他们更好地完成工作。
随着对技术技能的关注越来越少，敏捷是否能够显著地改进软件项目？敏捷是否仍然像敏捷宣言中所写的那样，专注于通过开发和帮助其他人来发现更好的软件开发方法?我不太确定。
软件匠艺
为了提高专业软件开发的标准并重新确立一些最初的敏捷目标，一组开发人员于 2008 年 11 月在芝加哥开会，创建了一个新的运动:软件工艺。在那次会议上，与 2001 年敏捷峰会期间的情况类似，他们就一套核心价值观达成了一致，并提出了一份新的宣言。
As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software.
- Not only responding to change, but also steadily adding value.
- Not only individuals and interactions, but also a community of professionals.
- Not only customer collaboration, but also productive partnerships.
- That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
作为有理想的软件工匠，我们一直身体力行，提升专业软件开发的标准，并帮助他人学习此工艺。通过这些工作，我们建立了如下价值观：
- 不仅要让软件工作，更要精益求精。
- 不仅要响应变化，更要稳步增加价值。
- 不仅要有个体与交互，更要形成专业人员的社区。
- 不仅要与客户合作，更要建立卓有成效的伙伴关系。
- 也就是说，左项固然值得追求，右项同样不可或缺。
精心编写的软件意味着经过良好设计和测试的代码。我们并不害怕更改代码，正是这些代码使业务能够快速做出反应。它是既灵活又健壮的代码。
稳步增值意味着无论我们做什么，我们都应该致力于不断为客户和雇主提供增值服务。
一个由专业人士组成的社区意味着我们需要互相分享和学习，从而提高我们行业的水平。我们负责培养下一代的开发人员。
富有成效的伙伴关系意味着我们将与客户和雇主建立专业关系。我们将始终保持职业道德和尊重的态度，以最好的方式为客户和雇主提供建议和工作。我们期待相互尊重和专业的关系，即使我们需要采取主动，以身作则。
思想与方法
意识形态是一种思想和理想的体系。方法学是方法和实践的系统。意识形态定义了目标的理想。一种或多种方法可以用来达到这些理想，它们是达到目的的手段。当我们看到敏捷宣言和 12 条原则时，我们可以清楚地看到它们背后的意识形态。
敏捷的主要目标是提供业务敏捷性和客户满意度，这是通过紧密协作，迭代开发，较短的反馈循环和卓越的技术来实现的。 诸如 Scrum，极限编程（XP），动态系统开发方法（DSDM），自适应软件开发（ASD），Crystal 方法，功能驱动开发（FDD）和其他敏捷方法之类的方法都是为了达到同一目的。
方法和实践就像训练轮，他们很容易带动人们。 与学习骑自行车的孩子一样，训练轮使他们能够以安全且受控的方式上手。 一旦他们更加自信，我们就会稍微抬高训练轮，以便他们练习平衡。 然后，我们将其中一个训练轮取下。 然后另一个。 此时，孩子已准备好独自行走。 但是，如果我们过多地关注训练轮的重要性，并且将其保持太长时间，则孩子会过于依赖训练轮，不希望将其卸下。 对方法论或一组实践的过分关注使团队和组织偏离了他们的实际目标。 目的是教孩子骑脚踏车，而不要使用辅助轮。
软件匠艺有实践吗
软件匠艺社区认为 XP 是当前可用的最佳敏捷开发实践集。 TDD，重构，简单设计，持续集成和结对编程在软件匠艺社区中得到了大力倡导-但它们是 XP 的实践，而不是匠艺的实践。 它们不是唯一的做法。 匠艺还倡导清洁规范和 SOLID 原则。 它促进小提交，小发布和持续交付。 它促进了软件设计和任何自动化类型的模块化，从而消除了手动和重复的工作。 而且，它倡导任何可提高生产率，降低风险并有助于生产有价值，强大而灵活的软件的实践。
匠艺不仅仅涉及技术实践，工程和自我完善。 这也与专业精神有关，并使客户能够实现其业务目标。 这是敏捷，精益和手工艺完美融合的领域。 这三个目标都有相似的目标，但从不同但同样重要和互补的角度解决问题。
关注价值，而不是实践
敏捷和软件匠艺社区中的一个常见错误是推广实践而不是其提供的价值。 让我们以 TDD 为例。 在软件匠艺社区中最常见的问题之一是“我如何说服我的经理/同事/团队进行 TDD？”这是一个错误的问题。 这里的问题是我们在达成一致意见之前就提供了解决方案。 如果人们看不到价值，人们将不会改变他们的工作方式。
在讨论实践时，首先要商定要实现的目标至关重要。 唯一不应该接受的事情是拒绝实践，而不提供更好的选择。
讨论实践
有关实践的讨论应在适当的级别和适当的人员进行。如果我们想采用改善业务与技术之间协作的实践，则应将业务和技术领域的人员参与其中。如果开发人员正在讨论使他们能够以更好的方式构建系统的实践，则没有理由让业务人员参与其中。仅在项目成本或项目持续时间有重大影响时，才应参与业务人员。
开发人员不应要求编写测试的授权。他们不应为单元测试或重构承担单独的任务。这些技术活动应纳入任何功能的开发之中。它们不是可选的。经理和开发人员应该只讨论将交付什么以及何时交付，而不是如何交付。每次开发人员自愿提供有关工作方式的详细信息时，他们都会邀请经理对其进行微观管理。
我们是说开发人员应该隐藏他们的工作方式吗？一点都不。开发人员应该能够向感兴趣的人清楚地描述他们的工作方式以及以这种方式工作的优势。开发人员不应该做的是让其他人决定他们的工作方式。开发人员与企业之间的对话应该是关于为什么，什么以及何时进行的，而不是如何进行的。
匠艺对个人的影响
人们通常将自己的生活与职业生活区分开来。诸如“离开办公室后我不想谈论工作”或“我对生活有不同的兴趣”等短语的表达方式使工作看起来像家务琐事，一件坏事或者你必须要做的事情，而不是你想要做的事情。将我们的生活分成多种生活的问题是，他们一直在发生冲突。总是有一种感觉，无论我们选择哪种生活，我们都必须牺牲另一种生活。
匠艺可以促进软件开发作为一种职业。工作和职业是有区别的。工作是我们要做的事情，但不是我们自己的一部分。专业是我们的一部分。专业是我们投资的东西。我们想要变得更好。我们希望获得更多技能，并拥有长期而充实的职业。
这并不意味着我们不会与家人在一起，也不会在生活中拥有其他利益。相反，这意味着我们将找到一种平衡所有承诺和利益的方法。有时候，我们想更加关注我们的家庭，我们的职业或我们可能有的爱好。那完全可以。我们在不同的时期有不同的需求。但是，当我们有专业时，上班不应该是一件繁琐的事。它应该是给我们带来快乐的事情，并使我们成为个人。专业赋予我们生活以意义。
匠艺对行业的影响
自 2008 年以来，在世界范围内组织了越来越多的软件匠艺社区和会议，吸引了成千上万的开发人员。敏捷社区侧重于软件项目的人员和流程方面，而匠艺社区则更侧重于技术方面。它们是向全球许多开发人员和公司推广 XP 和其他许多技术实践的关键。通过软件匠艺社区，许多开发人员正在学习 TDD，持续集成，结对编程，简单设计，SOLID 原理，简洁代码和重构。他们还学习如何使用微服务构建系统，如何自动化其部署管道以及如何将其系统迁移到云。他们正在学习不同的编程语言和范例。他们正在学习新技术以及测试和维护其应用程序的不同方法。匠艺社区的开发人员正在创建安全和友好的空间，在那里他们可以结识志趣相投的人并谈论他们的职业。
软件匠艺社区极为包容。从一开始，软件匠艺的主要目标之一就是将来自各个背景的软件开发人员召集在一起，以便他们可以互相学习并提高专业软件开发的水准。匠艺社区与技术无关，所有开发人员，无论其经验水平如何，均欢迎参加会议。该社区致力于培养下一代专业人员，举办各种活动，使加入我们行业的人们可以学习构建实用软件的基本实践。
匠艺对公司的影响
软件匠艺的采用正在增长。许多采用敏捷的公司现在都在寻求匠艺来提高其工程能力。但是，软件匠艺具有与敏捷不同的业务吸引力。 XP 仍然是许多经理不了解或不感到兴奋的东西。经理了解 Scrum，迭代，演示，回顾，协作和快速反馈循环。但是他们对与编程相关的技术并不那么感兴趣。对于大多数人而言，XP 与编程有关，而不与敏捷软件开发有关。
软件匠艺思想是许多开发人员的灵感。它给他们一种目的感，一种自豪感以及一种天生善于做事的意愿。一般而言，大多数开发人员都热衷于学习和做好事情，他们只需要支持和可以蓬勃发展的环境。拥护软件匠艺的公司通常会看到内部实践社区蓬勃发展。开发人员组织内部会议，他们在一起编码，练习 TDD 并提高他们的软件设计技能。他们对学习新技术和使他们工作的系统现代化感兴趣。他们讨论了改进代码库和消除技术借方的更好方法。软件匠艺促进了一种学习文化，使公司更具创新性和响应能力。
匠艺与敏捷
创建软件匠艺运动的一些触发因素与许多开发人员对敏捷开发的挫败感有关。因此，有些人认为软件匠艺和敏捷相互矛盾。参加过敏捷运动的软件匠艺运动人士批评敏捷过分关注过程，而缺乏对工程的关注。敏捷运动中的人们批评软件匠艺的关注点太窄或缺乏对实际业务和人员问题的关注。
尽管双方都有一些合理的担忧，但大多数分歧更多是与部落主义有关，而不是实际的根本分歧。本质上，两个运动都希望实现非常相似的目标。他们俩都希望客户满意，他们都希望紧密合作，并且都重视短暂的反馈循环。两者都希望提供高质量，有价值的工作，并且都希望专业。为了实现业务敏捷性，公司不仅需要协作和迭代的过程，还需要良好的工程技能。将敏捷与软件匠艺相结合是实现这一目标的完美方法。
总结
在 2001 年的 Snowbird 会议上，Kent Beck 说，敏捷是关于治愈开发与业务之间的鸿沟。 不幸的是，当项目经理涌入敏捷社区时，最初创建敏捷社区的开发人员被剥夺了价值，并低估了他们。 因此，他们离开去参加软件匠艺运动。 因此，古老的不信任仍在继续。但是，敏捷的价值和软件匠艺的价值是高度一致的。 这两个动作不应分开。 希望有一天，他们能再聚在一起。
总结
敏捷可能是我们所见过的所有关于软件过程和方法的革命中最重要、最持久的。这种重要性和坚持不懈的精神证明，2001 年 2 月，那 17 个人去犹他州的 Snowbird，开始了一场从一个很长的山上滚下来的雪球运动。骑着雪球，看着雪球越滚越大、越滚越快，看着雪球打在石头和树上，对我来说真是一件乐事。
我写这本书是因为我认为是时候有人站出来大声疾呼敏捷是什么，敏捷应该是什么。我想是时候记住这些基础知识了。
这些基本的东西过去是，现在是，将来也会是 Ron Jeffries 的 Circle of Life。这些基础就是 Kent Beck 所阐述的极限编程的价值观、原则和纪律。这些基础是 Martin Fowler 重构的动机、技术和纪律。这些基础是 Booch、DeMarco、Yourdon、Constantine、Page-Jones 和 Lister 提出的。
这些基本原则是古老的、经过考验的、正确的。不管在边缘添加了多少新的绒毛，这些基础仍然存在，仍然相关，仍然是敏捷软件开发的核心。
