以上，我们从响应能力出发，梳理了敏捷软件开发中的主要实践，这些实践并非为敏捷软件开发所专享。其实施，也非一蹴而就，需要以团队整体技术和管理水平的提高作为支撑。否则反而可能会带来新的“在制品”和“债务”，特别是“债务”。比如，引入单元测试自动化是为了减少技术“债务”，但如果单元测试自动化本身设计不良，测试用例过分依赖于实现细节。这样，对实现细节的改变，会影响到测试用例的正确运行，反而使单元测试成为负担，提高变更的成本，降低响应能力。

　　敏捷的实践之间是相互关联的，成为一个有机系统，才能发挥效益。管理实践之间是相互支持的。例如，离开多功能的团队，开发任务就必须在多个功能团队之间传递，无法做到短迭代开发。 技术实践之间是相互支持的。例如，没有单元测试自动化的保障，持续重构的风险将激增，在操作上变得不现实；有了持续重构保障，维持一个最简单的系统设计，需要时再通过重构，使设计适应新的变化要求，简单设计才更可能得以实施。技术实践和管理实践也是相互支持的。例如，短迭代开发中没有技术实践支持，就会不断积累技术“债务”，产品质量和开发效率不断下降；而，短迭代内全生命周期的反馈，也为各类技术实践的部署提供了便利。

　　综上，敏捷实践的应用和团队技术水平的提高，相辅相成，在应用中不断总结提高，构建和完善实践体系，加强客户、业务人员和团队的合作，以及团队内部的合作，持续、有效地减少“在制品”，以及技术和学习“债务”，提升组织的整体技术和管理水平，只有这样才能构建可持续的响应能力。

　　敏捷开发的最新实践

　　敏捷开发的思想并非在一夜之间产生，有些实践，如迭代开发几乎和软件开发的历史一样久远。上世纪90年代各类系统的敏捷开发框架和方法被相继提出，2001年敏捷宣言的发布，敏捷的概念正式形成，敏捷开发方法迅速普及。早期的敏捷实践，虽然也会涉及到业务和用户，但往往还是以开发团队为核心，重点关注团队内部实践。

　　随着敏捷实践的普及和完善，团队内部技术和管理实践作为组织响应能力的瓶颈被突破。近年来敏捷社区的关注重点更多地向团队前端和后端转移，一些新敏捷实践应运而生。

　　前端是指团队的输入，也即需求（包含用户体验）的获取、挖掘、澄清、整理和设计。得到比较多应用的新实践有SBE（Spec by Example）和 Agile UX。严格意义SBE和验收测试驱动开发（ATDD）属于同一实践的不同表述，它突出强调了，业务、开发和测试在前期通过表格化的实例对需求进行充分地沟通和协作，澄清和概念及一致性验证，并确保各方对业务和需求理解的一致。Agile UX把用户体验设计，更早和更紧密地融入敏捷软件开发过程，确保团队在迭代模式下，能持续交付具备良好用户体验的产品，同时加强与用户体验相关的响应能力。

　　后端是指团队的输出，也即产品的交付、运营和维护。得到比较多应用的新实践有持续交付和 DevOps。持续交付是持续集成的延伸，它的目标不仅是使软件始终处于可运行和通过适当验证的状态，它致力于确保整个开发周期中，软件都处于可交付的状态，从而降低交付风险，并缩减从概念形成到软件交付的时间周期。DevOps则进一步拓展，加强软件开发和IT运营之间的沟通、合作及整合，弥补两者之间的信息鸿沟，更快地交付软件产品，提供软件服务。

　　总结

　　在激烈竞争和充满无限可能的今天，技术、应用都在飞速发展，用户对体验的要求也前所未有的提高，响应变化的能力成为组织的核心生存能力。就这一点而言，敏捷对于软件开发组织是一个必然的选择，而非一个可有可无选项。

　　通过敏捷开发实践的系统运用，减少“在制品”数量、降低技术和学习“债务”，改善团队与用户及市场的协作，构建了组织的灵活响应能力。然而，敏捷对于软件开发，也绝非一个银弹，软件开发没有因之变得更加容易，甚至因响应性要求，团队和个人都面临更大的挑战。敏捷实践的正确实施，响应能力的建设，最终还是依赖与在实践中不断总结、提高，依赖于个人和团队总体能力的提升。