敏捷方法的核心思想在敏捷宣言中有阐述，这里引自敏捷宣言网站 agailemanifesto.org
敏捷软件宣言 我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工作,我们形成了如下价值观: 个体与交互 重于 过程与工具 可以工作的软件 重于 面面俱到的文档 客户协作 重于 合同谈判 响应变化 重于 遵循计划 也就是，虽然右边的条目都有价值，但是我们认为左边的价值更多
这个宣言中有几个值得关注的点。首先，它是参与软件开发的人写得“身体力行且帮助其他人”，另外敏捷方法对于价值和特定的一些技术一样关注。现在有很多敏捷方法：极限编程，Scrum, Crystal Clear和其他一些。但它们有着宣言中阐述的同样的核心价值，这使得它们相对来说容易理解。比方说，一旦你了解了
XP, 你应该容易了解Scrum, 在本书中我将用XP中的定义作为编程流程来描述。测试驱动开发，是作为XP一部分发明的。最后，但主要的点是“敏捷”，敏捷方法的价值在于以一定速度朝目标推进同时拥有转变成新的更好的路线且低成本的能力。
强调个人和交互。敏捷方法非常强调软件开发作为一个团队的行为，个人的创造性和贡献是成功的主要方面，因此给个人和协作的组织一个好的环境是关键。较早的开发方法倾向于把个人作为“生产部件”，机械化地产生软件代码，设计，测试计划等。因此很少关注使个人感觉舒服且更多关注于文档和流程来控制交互。敏捷方法建议了一些实践来确保正确的决定被做出，因为人都负责且想做正确的事情且总有人手上有适当的信息来做出有效的决定。比方说，有人关注过团队在楼里怎么分布的情况：如果需要协作的两个组在不同的楼层，他们的效率会低于办公室相邻的情况，在交流减少的情况下，交流存在误解的风险和在产品中的缺陷数量将显着提高。
可工作的软件。Bertrand Meyer， Eiffel编程语言的发明者有说过“当一切都说过，软件却是靠代码来定义…”(Meyer 1988)。设计也许正确，UML图也画得很漂亮，但是如果没有的代码没有产品那么也没有收益去埋单。敏捷方法关注创造高质量代码且较少写代码相关的文档，原因是写代码很费时间的，占用了不少写代码时间。因为强调个人和交互所以去找相关人员了解信息会比文档更快更准确，然而价值源自于可工作的软件：代码得是高质量，因此测试是主要的手段：使用软件去找到它的缺陷，另一个保持代码高质量的主要手段是重构：改善代码结构而不影响其功能。这两个手段在本书中都很重要且在后面有详细讨论。
客户互动 比合同谈判要快，Bjarne Stoustrup，C 语言的创始人说“去编程就是去理解。”作为去实现客户需求，你需要更深入地了解它们且指出需要解决的模棱两可的东西和可改善最终产品的地方。如果这些东西需要一个很长的命令链，开发人员问经理们，经理们问销售人员，销售人员再问采购，采购再问每个用户。反馈将会太慢，结果是有缺陷或累赘的产品且失去了变成更好产品的机会。想要关注于人与人之间交互，敏捷方法要求客户和用户都不迟疑地接受问题和讨论，一个核心的手段就是小的发布。把可工作但功能不全的系统展示给用户，给他们使用。这些发布是一个比用需求文档讨论不确定事情和改进机会的更好的出发点。
对修改的反馈 是说通向目标的最好的途径不一定是在旅程开始时计划的那一条。在项目中工作意指学习和改善对什么是最适合客户的产品的理解--特别是如上所综述因为它们集成在项目中。因此最开始的计划很重要但是计划随着经验的积累需要做出调整。也许客户原以为他们需要特性X当在工作于一个在小的发布的部分时发现X不是特别重要而特性Y的相关性更大，那么为什么不在下一个小的发布中加入特性Y呢？
翻译自书籍：Flexible, Reliable Software Using Patterns and Agile Development, Henrik Baerbak Christensen
后面的翻译将陆续更新… 下一篇，1.3 极限编程
