以演进式的架构来让系统为变化做好准备
2016敏捷海滩会议在英国康沃尔举行。会上Rebecca Parsons认为，缩短进入市场的时间和提高业务敏捷性的要求，可以通过构建真正的演进式架构的软件、让系统做好准备改变、降低实验成本（和风险）、最大限度地提高可见度和反馈，以及统一公司的核心价值主张等来实现。
\\在第二天的敏捷海滩会议上，Thoughtworks首席技术官Rebecca Parsons提出的议题是“准备改变”。在发言中，Parsons首先提出，缩短进入市场时间的需求越来越强烈，虽然“敏捷”已经实行了二十多年，但并不是所有的软件交付过程的环节都完全接受这个概念。快速变化的能力和实验往往可以成为竞争优势：
\\在业务水平的敏捷性是至关重要的。缩短到市场时间的良性循环包括：测试假设、快速交付和发布以及测量。Parsons指出，测量是至关重要的，但往往被忽略；虽然在项目开始之前花了很大的努力去做计划和预算，但在交付之后，花费的代价却往往不被测算。组织也必须让项目能安全地失败，因为不是每一个项目都会（或应该）成功。
\\\\\如果你没有失败过，那你就没有创新。让它安全地失败。
\
可以对交付有价值软件有帮助的技术包括：
\\- 持续设计-在系统在开发的时候创建和修改系统的设计，而不是试图在开发开始之前完全指定系统全部细节\\t
- 持续交付（Continuous Delivery，CD）-在短周期内交付软件，确保软件可在任何时间点可靠地发布。持续交付使它能够安全地发布软件，从而能够进行实验\\t
- 实用的软件质量-监控核心软件质量指标的趋势（如重复、周期性复杂度和缺陷率等）是至关重要的\\t
- 演进式架构-把结构渐进改变作为设计的首要原则\\t
- 合理组织IT-了解康威定律（Conway’s Law），并相应地把敏捷原则引入到组织结构设计。Sriram Narayan的“敏捷IT组织设计”一文中写了有关内容\
演进式架构的主题对于许多研发人员来说都是陌生的。相应地要学习各种概念，如绞杀模式（strangler pattern）、波斯特尔定律（Postel’s Law）、可测试性架构、基于可维护性和适应性对演进方式进化优先级排序等等，都是非常有益的。
\\重视非功能性需求同样重要。提前决定在性能、安全性和可靠性方面哪些问题重要，将在整个项目的周期里，使设计的选择变得更容易。
\\\\\非功能性的要求是非常重要的[…]为了学习更多的内容，和那些在出错时的受害者们聊聊天，比如运维团队。
\
Parsons在总结发言时说，IT在传统上被认为是一个成本中心，并相应地以稳定化和标准化为重。现在，IT往往被视为一个企业价值主张的核心，因此应以实验和反应为重。这种成本控制和价值生成的冲突往往会导致组织分裂，必须进行相应的管理。我们必须考虑组织差异（企业的核心价值是什么？），“商品计算”必须从IT需求创新的领域中分离出来，整个IT项目组合必须进行管理，并且考虑到适度的进行外包。
\\在Parsons的总结中，他指出，业务敏捷性的目标可以通过以下技术实现：
\\关于敏捷海滩会议的更多信息可以在会议网站上找到，并可以在推特上关注“agileotb”标签。Rebecca Parsons第二天的主要讲话将很快上传到YouTube敏捷海滩会议频道。
\\查看英文原文：Keeping Systems \"Poised for Change\" with Evolutionary Architecture