试验型设计

有时，什么是正确的度量或需要哪种类型的分析来评估一个构想的价值，并不显而易见。比如：试图提高生产力的构想，就可能很难去度量。提供给系统所有者对其构想成功与否的反馈，对新需求的优先级排定和引导系统改进起着至关重要的作用。

设计可测试性假设有效的方式是：设计一系列试验以验证新功能是否交付了预期结果。因此，我们从新功能的预期结果和其对系统行为带来的影响来决定。设计试验的关键是保证度量了新功能的真实影响。拿上述改变购买流程的例子来讲，度量和比较用户使用新旧流程比单方面查看历史数据提供了更有效的依据。

演变型基础架构

要使该循环有效执行下去，部分地要求快速调整系统以尝试新的想法。在理想世界里，我们能够预见所有对系统可能想要的修改。现实中，一切改变都是不可预测的。用户期望，商业环境，竞争对手情况，规章制度等都在一个组织管辖范畴之外。因此不论改变是否可预见，我们都需要能够适应。演变型基础架构和紧急设计是敏捷软件开发采取的方式，能让不可预计变化变得尽可能简单和安全。

支持演变型基础架构和紧急设计的测试将在下个章节涉及。通过认清由于系统新加功能所产生的重构机会，紧急设计关注于保持代码可维护性与干净整洁。与之相反，演变型基础架构关注于系统的构架因素，包括技术选择和不同架构元素间的接口设计。

在这种情况下，演变型架构的目标包含独立开发系统不同部分的能力，即使它们需要相互交互。我们通过对功能的合理封装，连同合同测试里记录的每个系统对其它系统行为的影响等途径来将其实现。为每个开发团队提供这样的测试能让他们从一开始就意识到随着系统的开发将不可避免地会遇到不兼容性问题。演变型架构的另外一个目的在于目标数据修改，信息修改，以及某个组件对其他组件实现的交换。

测试

在演变型架构章节，我们讲述了支持该变革循环重要的测试风格。尽管如此，很多其他测试方式对支持该循环也至关重要。彻底有效的单元测试对支持演变式设计是至关重要的，而且也为添加新功能而不影响当前功能带来了更多自信。同样，一个彻底的回归测试集也在不同粒度层提供了同样的保护。

一个完整的测试策略对于参与到该创新循环的系统，保证了在不影响旧功能的前提下新功能的正常使用。该测试应包含功能测试以外的技术型测试（压力，环境等）。同样重要的，测试这一功能对该构想的度量的支持也应该包含在测试策略里。为了确保该循环的进行，自动化测试至关重要。手动测试循环一般都很长，手动测试应该关注于核心领域，并更倾向于探索性。

持续设计

值得兴奋的是设计越来越关注于客户和用户体验。与软件开发其它方面一样，以用户为中心的设计也在学习如何更加以敏捷为导向。同架构和应用设计一样，对用户体验框架的设定，一些前期思考是必需的。尽管如此，需再次强调的是，不应集中太多精力在初始框架的确定上，应该同架构和设计一样，让设计随着用户需求及期望的变化而不断改变发展。

持续设计允许用户体验通过系统演变不断探索来获得启发。该方式也将我们的注意力集中在功能都将为用户系统交付了哪些价值。希望通过以用户为中心的方式来防止系统常见的功能臃肿现象。

持续交付

与本调研文章的其它话题一样，持续交付的复杂性和全面性能占据多个篇幅，而非几个段落。但是，持续交付背后的概念所提供的机制能使该创新循环执行下去。在这里，与持续交付原理最相关的是快速部署到生产环境，缩短了构想与其价值回馈的循环时间。

完成快速部署需要持续交付多种技术，包括架构自动化，构建自动化，部署和回滚自动化，数据集成自动化，当然还有之前提到的测试自动化。每个技术对支持以下步骤都是必需的：快速开发新功能，快速测试新系统，快速安全部署产品，快速安全回滚以防止系统没有如期工作或新功能被证实为坏主意。

演变循环

最后，上述创新循环的目的在于允许组织能快速测试构想。如果没有该循环，组织就需要在执行某个构想上花费很多资源，而这也意味着只有少数构想被尝试，因此，组织能成功实现的就仅限于某些特定的构想。通过减少费用、时间，和尝试新构想所带来的风险，该创新循环允许组织尝试更多，从而加大了找到更多构想潜在价值的可能性。

演变型架构和全面的测试，连同敏捷软件开发的其它实践，减少了执行某个构想的开发时间。持续设计致力于某一功能应如何与系统其他模块集成，并为如何度量某一想法成功与否提供了建议。试验型设计和合理的使用度量完成了所需的回馈循环以判定某想法的成功与否。持续交付所提供的机制允许将所有这些工作集成起来以完成该变革循环。

通过减少试验所带来的风险和费用，为组织持续地为其员工和客户提高他们的服务提供了基础。我们认为完成该变革循环能为组织提供了一个非常具有竞争力的优势。