译者序

我愿称你为最强

这本书充满了作者对敏捷软件开发的真知灼见，对想成为敏捷开发人员或者想要提升技能的你，有很大的帮助。我一直在期待这本书，事实上，它没有让我失望。

遥想当年，原著出版的时候，我还在上小学。后来上大学期间有幸读到它，已经弹指一挥过了十年。如今着手重新翻译，我已经是一名有六年经验的老司机，就职于以敏捷软件开发著称的软件公司ThoughtWorks。算算年头，我和这本书的渊源竟然如此之深。这本书年份虽久，但常翻常新。到今天，它所涵盖的原则、模式和实践仍然是敏捷软件开发的思想和实践的精髓。

大浪淘沙，我愿意称它为软件开发中的“圣经”（这句话再次暴露了年龄，因为我套用的是动漫《火影忍者》中的经典台词“我愿称你为最强”）。

记得大学时第一次翻阅这本书，开篇的敏捷软件开发宣言就让我有一种豁然开朗的感觉。大学老师讲的是瀑布式软件开发，动辄几十页的需求规格说明书、概要设计文档和详细设计文档的课程大作业往往让我们这些学生叫苦不迭。虽然高度怀疑这些活动的价值，但苦于找不到任何可以反驳的理由，所以只好去找些别的书来看。直到我遇到这本书，更没有想到就这样开启了我与敏捷近二十年的缘分。

2001年敏捷软件开发宣言签署以来，敏捷软件开发及其后的DevOps、设计思维、精益企业和精益创新等方法论逐渐成为中国软件行业的主流。虽然方法本身受到了应有的关注，但如何落地依旧是业内迫切关心的问题。

技术咨询师的从业经历使我有机会参与不少大中型企业的敏捷转型项目。在指导团队的过程中，我发现他们存在一些共性的问题—重管理轻实践。Scrum方法提倡的各种活动，例如站会，需求澄清，迭代回顾和代码评审，这些名头，他们都有。但事实上，这些活动往往流于形式，有些甚至演变成领导的“一言堂”，例如，站会变成向领导汇报工作进度；需求澄清变成领导分配任务；迭代回顾变成领导问责；代码评审会议倒还好，因为领导一般不参加。究其缘由，原来是团队领导更注重管理，他想在团队内部推行Scrum和Kanban等敏捷精益方法，这是外功。但团队成员对持续集成、TDD和重构等这类注重内功的敏捷实践力有不逮，因此，前脚未出坑，后脚又踏入了软件质量差、上线时间周期长和变更频繁失败的恶性循环中。敏捷开发倡导内外兼修，这本书中阐述的敏捷开发实践和敏捷设计原则是帮助我们修习内功心法的捷径。

重译经典是为了使经典更好地为社区服务。学习技术发展史有助于我们更清楚地技术发展的现状，因此，我们不妨在一个更大的历史背景中理解敏捷软件开发。

从1978年到今天，短短四十多年的时间，我们迈过了欧美国家历时二百多年的两次工业革命，追上了第三次工业革命的尾巴，并开始引领第四次工业革命。在这样的大时代背景下，西方50年的软件工程（作为信息革命的一部分）发展史在中国也被压缩为20年。软件市场欣欣向荣的同时，工程方法却没有与时俱进。面对日益庞大且复杂的软件需求，以往厚重、亦步亦趋的软件工程方法逐渐失效，轻量且灵活的科学方法应运而生，敏捷软件开发方法便是其中很重要的一支力量。

吴军博士在《全球科技通史》中表达了这样一种观点，19世纪和20世纪的科技发展，它们的驱动力有所不同，前者更多是靠能量，如蒸汽和电气，而后者则是以信息为中心，典型代表就是计算机。与此同时，科学认知方式也经历了从机械论到“三论”（控制论、系统论和信息论）的转变。

在21世纪，互联网迅速普及带来了信息产生、传输和使用上的指数级增长，以处理信息为目的的软件也随之发生了巨大的变化，服务从单体演进成微服务，拓扑由点状进化成网状，这也使得软件开发技术更加复杂。除了技术更加复杂，数字化时代背景下的不确定性以及由此而来的复杂性更加突出，为此，我们需要更科学的工程方法，这样的工程方法必须遵循这个时代的认知方式。幸运的是，敏捷软件开发就是一种符合这一认知的软件开发方法，它的核心价值观体现在敏捷软件开发宣言中，而诸多实践背后的原则都集中反映了“缩短反馈”和“持续改进”这两个以获取和处理信息为目标的举措，试图以引入更多信息的方式来实现信息的熵减。

总而言之，这本书兼具实用价值和历史意义，于我而言是常读常新。我相信你也不会例外。