敏捷和架构的冲突

  • Vikas Hazrati
  • 金毅

2011 年 6 月 18 日

话题:敏捷架构设计模式文化 & 方法

实施敏捷方法和设计企业架构之间总是存在某种冲突。敏捷开发强调随着对业务领域的深入理解,逐步调整设计和计划。架构设计则要求建立起技术架构(technology stack)。它可以满足质量属性(quality attributes),也可以向感兴趣的利益关系人进行展示,作为一种沟通的途径。当使用敏捷方法来引领所需的架构设计的时候,两者强强联手将会是双赢

Tom Graves 认为敏捷需要一个脊柱来支撑。而软件架构提供了这个脊柱。

敏捷通常需要一个脊柱来指引方向——根据这个方向,推动一些工作的进行。这样做,相对于随意出牌,可以完成更多的工作。通常,这是个平衡问题——要在坚实的脊柱和敏捷之间有个良好的平衡。

Jan Van Til 赞同 Tom 的观点,他认为没有后台的脊柱,前端也很难看得出有多敏捷。

我们当然需要一个相对进展“缓慢”的“后台”,这样才能让我们看清我们有多敏捷(“前端”)。如果所有的东西都很时尚... 我们还能从中识别出哪个是时尚吗?我们当然需要一个有点“缓慢”的“后台”,这样才能让我们看清时尚(“前端”)。换句话说,我们需要传统的东西,没有传统的东西,也就没有了时尚。

Simon Brown 觉得,甚至“绝大部分的敏捷项目”可能都有或大或小的架构方面的问题。我们需要在项目早期迭代中解决它们。Simon 认为,敏捷和架构的冲突可以归结为是通过短迭代来交付商业价值,还是做一个庞大的预先设计。这里的关键点是设计要“刚刚好”(just enough)。准备好一个初步的结构是很重要的,但这不意味着就要画出无数的详细类图。

John Bauer 则提到,在对几个项目观察了一段时间以后,他发现了一个有趣的模式

敏捷以及那些类似敏捷的方法有个好处,对于产品来说,它能减少那些架构设计过度的软件解决方案(over architect-ed software solutions)的产生。架构设计过度的解决方案会强调软件应用项目的交付,也会使得软件开发和维护的成本上升,通常来说,是跟交付商业价值背道而驰的。

James Coplien 和 Kevlin Henney 给我们介绍了一种从项目开始的时候就进行“刚刚好”的架构设计,并且确保项目成功的有效方法

但是,这一切在现实世界里又是怎么实现的呢?

Simon Brown 在他的博文中提出了一个有趣的挑战:他要求在 4 个月左右的时间内,重新开发一个程序来取代老迈的在线银行系统 。他要求大家仍然使用敏捷方法,但最终还是能够交付。博文中提到了大家提出的一些方案,包括KeroJohn Bauer的。你可以查询到更多的方案,也可以提出你自己的想法

这样看来,架构设计和敏捷需要共存。不是有你没我,而且相互合作。这里的关键点就是做“刚刚好”的设计。 Simon 定义了“刚刚好”

做一个“刚刚好”的架构,可以让你条理清晰,明确愿景。换句话说,“刚刚好”让你知道了你的目标是什么,你怎么去完成这个目标。背后的关键就是架构是一个重大的决定,而“重大”是由进行改变所需要的成本来衡量的。换而言之,这就是架构,想要修改真的会很贵,而且你真的必须尽早做出正确的决定。举个例子,质量属性,比如高性能,高扩展性,高安全性以及高可用性,通常都需要在早期就把这些考虑在基础框架内,因为想要在后期重新修改现有的基础代码库会很难。这也就是架构,你不可能在某个下午很简单地就进行重构,比如核心技术选择、架构模式、核心框架等。

查看英文原文:Agile and Architecture Conflict

敏捷架构设计模式文化 & 方法