敏捷设计法则

不同设计的确定时机会对敏捷团队的效率有重要的影响，不恰当（过早或过晚）的时机都可能会给团队带来不必要的返工。哪些设计需要在迭代前完成作为准备“Ready”的一部分？也就是所谓前期设计（Up Front Design）。哪些设计可以在迭代中完成？也就是增量实现。

在这里我举个盖楼时楼层设计的例子，下图列出了建筑设计需要做的决策。

建筑中楼层的设计决策

地点：           决定大楼建在哪里

结构：           决定地基和楼的框架

外表：           楼层外表设计

服务：           水、电、下水道等系统

内部空间：    内部空间布局设计

材料选择：    灯光、颜色、地板等的选择

注意这些设计决策的次序至关重要，从下到上变更难度和成本都在成倍增加。一线城市可用地越来越少，价格越来越贵。如果在建筑过程开始后，还需要更换地点，那么代价是承受不了的。如果你已经盖了10层楼，需要该地基，那么你就必须把这10层楼全部毁了，代价巨大。而相比之下，换个地毯则是个很简单的事。

错误决策导致短命建筑

通过这个例子我们可以看到有些设计决策需要前期冻结，因为其变更成本会让我们不能承受，如地点、地基。而有些设计可以到需要时再定，如用什么样的地毯或墙上涂什么样的颜色。过早的确定这些决策反而会造成不必要的返工，如果建筑商在墙上用的颜色不是房主想要的，他很可能会重新刷上自己喜欢的颜色。

在软件开发中，其硬件环境、开发语言、开发平台及其他支持体系就像是建筑的地点，系统架构就像是结构。子系统的架构设计就像是外表或服务，而具体模块中的功能实现设计有可能就是材料选择。

哪些设计需要迭代前完成，哪些可以在迭代中完成，这是是团队的一个重要决策。也应该是Ready检查单中的一项。

多少架构设计的投入是比较合适的呢？Barry Boehm和Richard Turner在《Balancing Agility and Discipline》一书中，根据来自161个不同类型项目的数据，对此做了定量分析。他们根据项目的架构及风险因子，给出了敏捷度和约束度的最佳结合点——架构在项目中的投入比例。他们的基本结论是随着项目规模及criticality的增加，这个最佳点会向约束方向倾斜，反之亦然。

他们的研究显示，如果前期架构投入不足，会导致开发后期因为架构缺陷的返工。返工量会和项目规模成正比。下表显示架构方面的投入和项目规模对返工及项目延期的影响。

从表中我们可以很容易看出，项目延时等于架构投入加上返工。如果将上表用图画出来的话，你会发现对于1万行代码的项目来讲，5%是架构前期投入的最佳比例；10万行代码的项目则应在20%，而对1000万行代码的项目来讲，架构前期投入的最佳比例是37%。

太多和太少约束都不行，度的把握是敏捷成功的重要秘诀之一。

摘自 《知行合一： 实现价值驱动的敏捷和精益开发》

可在京东购买