以演进式的架构来让系统为变化做好准备

2016 敏捷海滩会议在英国康沃尔举行。会上 Rebecca Parsons 认为，缩短进入市场的时间和提高业务敏捷性的要求，可以通过构建真正的演进式架构的软件、让系统做好准备改变、降低实验成本（和风险）、最大限度地提高可见度和反馈，以及统一公司的核心价值主张等来实现。

在第二天的敏捷海滩会议上，Thoughtworks 首席技术官 Rebecca Parsons 提出的议题是“准备改变”。在发言中，Parsons 首先提出，缩短进入市场时间的需求越来越强烈，虽然“敏捷”已经实行了二十多年，但并不是所有的软件交付过程的环节都完全接受这个概念。快速变化的能力和实验往往可以成为竞争优势：

在业务水平的敏捷性是至关重要的。缩短到市场时间的良性循环包括：测试假设、快速交付和发布以及测量。Parsons 指出，测量是至关重要的，但往往被忽略；虽然在项目开始之前花了很大的努力去做计划和预算，但在交付之后，花费的代价却往往不被测算。组织也必须让项目能安全地失败，因为不是每一个项目都会（或应该）成功。

如果你没有失败过，那你就没有创新。让它安全地失败。

可以对交付有价值软件有帮助的技术包括：

• 持续设计 - 在系统在开发的时候创建和修改系统的设计，而不是试图在开发开始之前完全指定系统全部细节
• 持续交付（Continuous Delivery，CD）- 在短周期内交付软件，确保软件可在任何时间点可靠地发布。持续交付使它能够安全地发布软件，从而能够进行实验
• 实用的软件质量 - 监控核心软件质量指标的趋势（如重复、周期性复杂度和缺陷率等）是至关重要的
• 演进式架构 - 把结构渐进改变作为设计的首要原则
• 合理组织 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