通常情况下，软件交付中的创新和产品构思之间并不总会互相影响。尽管如此，随着对产品新功能的需求 不断增多，及对应产品生命周期的缩短，甚至商业模型，也都使得将持续设计和持续交付置于同一循环以实现 全面的交付成为必需。由于缺少好的名字，我们就暂就时叫本文为创新循环，循环的每一个阶段如下所示：
选择一个构思
将该构思提炼成一个可测的假设
选择完成该构思所需的功能
开发并测试这些功能
开发和测试那些衡量标准以证实该假设是否可行
将构思发布到生产环境
对该构思成功与否进行衡量
重复这一循环。
不出意料，支持该方式需要应用程序在以下方面进行创新：度量和分析，基础架构，测试，试验型设计， 持续设计及支持持续交付的流程和工具。在本文中，我们将介绍维持该循环所要求的重要创新。以下涉及的每 个话题都可独立成文或者涉猎更多，请将此调查问卷作为一个引子，激发大家去更多地了解这些话题。
度量和分析
度量是有风险的，它很容易产生反效果，激励坏行为。尽管如此，度量却是以上我 们所描述循环的一个主要方面。软件系统中关于具体内容的构想的定义不仅在于软件具体行为，也在于如何知 晓该构想的好坏。我们可以参考一个具体实例：市场部有人认为如果改变他们的网上购物流程，其网上营业额 将会提升20%。该例子的构想是改变流程，而可测性的假设就是用户使用新流程后，会有高于之前流程20%的人 倾向购买。在这种情况下，其度量就很简单，我们需要去测量每个流程客户的购买结果。我们可以随机性地将 用户分配到不同的流程，然后评定各流程是否达到它的目标。为了完成这个度量，我们要保证我们记录下每个 流程用户的使用情况和销售结果。在测试的最后阶段，我们就会知道该营销想法好坏与否。
试验型设 计
有时，什么是正确的度量或需要哪种类型的分析来评估一个构想的价值，并不显而易见。比如：试 图提高生产力的构想，就可能很难去度量。提供给系统所有者对其构想成功与否的反馈，对新需求的优先级排 定和引导系统改进起着至关重要的作用。
设计可测试性假设有效的方式是：设计一系列试验以验证新 功能是否交付了预期结果。因此，我们从新功能的预期结果和其对系统行为带来的影响来决定。设计试验的关 键是保证度量了新功能的真实影响。拿上述改变购买流程的例子来讲，度量和比较用户使用新旧流程比单方面 查看历史数据提供了更有效的依据。
演变型基础架构
要使该循环有效执行下去，部分地要求快 速调整系统以尝试新的想法。在理想世界里，我们能够预见所有对系统可能想要的修改。现实中，一切改变都 是不可预测的。用户期望，商业环境，竞争对手情况，规章制度等都在一个组织管辖范畴之外。因此不论改变 是否可预见，我们都需要能够适应。演变型基础架构和紧急设计是敏捷软件开发采取的方式，能让不可预计变 化变得尽可能简单和安全。
支持演变型基础架构和紧急设计的测试将在下个章节涉及。通过认清由于 系统新加功能所产生的重构机会，紧急设计关注于保持代码可维护性与干净整洁。与之相反，演变型基础架构 关注于系统的构架因素，包括技术选择和不同架构元素间的接口设计。
在这种情况下，演变型架构的 目标包含独立开发系统不同部分的能力，即使它们需要相互交互。我们通过对功能的合理封装，连同合同测试 里记录的每个系统对其它系统行为的影响等途径来将其实现。为每个开发团队提供这样的测试能让他们从一开 始就意识到随着系统的开发将不可避免地会遇到不兼容性问题。演变型架构的另外一个目的在于目标数据修改 ，信息修改，以及某个组件对其他组件实现的交换。
测试
在演变型架构章节，我们讲述了支持 该变革循环重要的测试风格。尽管如此，很多其他测试方式对支持该循环也至关重要。彻底有效的单元测试对 支持演变式设计是至关重要的，而且也为添加新功能而不影响当前功能带来了更多自信。同样，一个彻底的回 归测试集也在不同粒度层提供了同样的保护。
一个完整的测试策略对于参与到该创新循环的系统，保 证了在不影响旧功能的前提下新功能的正常使用。该测试应包含功能测试以外的技术型测试（压力，环境等） 。同样重要的，测试这一功能对该构想的度量的支持也应该包含在测试策略里。为了确保该循环的进行，自动 化测试至关重要。手动测试循环一般都很长，手动测试应该关注于核心领域，并更倾向于探索性。