如果你问10个人关于敏捷的意义，你将很有可能获得至少10种不同的答案——也许更多，因为很多人会给你多个定义。一些人可能会引用敏捷宣言，另外一些可能告诉你Scrum的规则，而还有一些人可能说它是完全关于在要求中允许灵活性的。尽管对词语敏捷的意义有不同的解释，但敏捷领袖建议看看最佳实践，而不是只注意到词语本身。本文中，我们将会重新审视一些用于成功组织内的敏捷的基础因素。

　　使用敏捷方法

　　虽然敏捷宣言不怎么像食谱似的方法，来教你“怎样敏捷，”但敏捷方法论，如流行的Scrum，在本质上是更规范的。敏捷教导我们要恰当好，持续地改进，所以它在理论在有点“反规范性”，这可能就是敏捷意义模糊的原因。尽管如此，使用方法论给软件开发组织提供了框架，含有要求的所有工件和指导方针。

　　使用敏捷技术

　　尽管使用特定的敏捷方法论可能给了你一个简略的敏捷实践，但是许多组织都从各种各样的，认为是敏捷的方法论中进行混合和匹配使用。在“Scrum vs. Kanban：软件开发新方法大比拼”一文中，我们看到了有着不同的指导方针的两个敏捷方法论，可以以互补的方法进行使用。许多组织变形最佳实践，从而为他们的组织实现一项定制的指导方针。

　　频繁交付

　　在敏捷软件开发中，你将会听到这个术语“持续交付”。这意味着客户将有能力做出反馈，然后从这些反馈改变的结果将会比之前更快速地再交付给他们。敏捷环境建立反馈循环，并增量创建软件，因此根据需求做出改变，纠正路线是可能的。

　　迭代开发

　　区分敏捷开发和如瀑布式方法这样的传统方法论的一种方法是使用迭代开发。瀑布式方法规定在不同的开发阶段，如需求、设计、编码和测试阶段之间存在着“门”。每个阶段都不会开始，直到另一个阶段已经完成画上了t和i。因为迭代开发，编码被分成简短的迭代，而且每一个这样的代码部分都要有需求分析、设计、编辑和测试，然后回顾与业务或用户代表的反馈。

　　应变能力

　　在与业务回顾简短的、少量的代码部分中，用户将能够对他们的原始需求进行修订。与瀑布式方法不同，在瀑布式方法中组织不会看最终结果，直到长期的开发周期结束；而敏捷方法，业务用户一直与开发团队进行沟通。这些团队需要有现成的流程，才能适应改变的需求。使用敏捷框架，团队学习方法来适应和拥抱改变，以及移除不被允许的障碍。

　　协同合作

　　基本的协作意味着不是不同的组织（如业务所有者、开发者、QA、运营者）独立工作，他们一起工作，经常沟通。敏捷团队经常使用“全队（whole-team）”方法，该方法中整个团队都为质量负责。很少强调特定的角色，而是所有的团队成员群一起以一个可持续的速度帮助解决问题和向客户交付高质量的代码。

　　测试驱动开发（TDD）

　　测试驱动开发是一个技巧，用于自动化单元测试，但是通过技巧性地在功能代码之前编写自动测试代码。测试将失败，直到功能编写代码。该技术与XP的测试优先编码概念相关，据说它可以使设计更简单。在代码本身中拥有这些自动化测试保证这一测试，也可以作为文档，永远不会过时。这些自动化测试也能作为持续集成来服务。

　　持续集成

　　持续集成是运行一组自动化回归测试的过程，在每次代码构建和自动通知适当的团队成员是否有任何问题时。该技术是敏捷实践的关键之一，它允许团队迅速交付，而不是必须在每一个部署之前都经过长期的建立测试周期。

　　自主团队和服务型领导

　　敏捷团队不使用传统的命令控制式的领导模型，而是使用更加服务型的领导方法，在此方法中经理们扮演辅助和教导的角色，努力激励和授权他们的团队。在“敏捷开发需要经理，还是经理阻碍了敏捷开发”一文中，Skip Angel谈了催化剂领导的需求，这些敏捷领导拥抱和展示敏捷的价值。

　　尽管本方中总结了几点敏捷的基础因素，但我们只是触及了表面。整个书是写在各主题之下，当然，作者和专家的建议会随着如何使这些实践发挥最好的作用的建议而改变。就像在良好的烹饪中涉及到各种各样的技术一样，开发软件也有很多方法。虽然有很多食谱，但最好的厨师了解如何调整食谱做出杰作。敏捷软件开发团队可能开始于食谱方法，但将会继续尝试各种技术，使每一次迭代都变得更敏捷。