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
评论