控制项目规模

作者：大卫·奎克（Dave Quick）

规模指的是软件项目的大小。完成项目需要多长时间、多少人工和资源？要实现哪些功能？质量上有什么要求？难度如何？风险有多大？要遵守哪些约束条件？这些问题的答案界定了项目的规模。软件架构师都喜欢挑战复杂的大型项目。由于回报非常诱人，甚至有人搞“形象工程”，故意夸大规模。殊不知规模越大，项目失败的可能性越大，这一点常让人始料不及。规模扩大一倍，失败的可能性往往会增加十倍。

为什么呢？请看两条前人的经验：

• 凭直觉判断，只要花两倍的时间或资源，就能完成两倍的工作任务。但是历史告诉我们直觉不可靠，这里不存在简单的线性关系。例如，比较四个人组成的团队和两个人组成的团队，前者花在沟通的时间肯定超过后者的两倍。
• 估算与准确的科学计算相差甚至远，所以产品特性实现起来常常比预期的要困难。

当然，有些项目正是因为具有一定的规模和复杂性，才有开发的价值。好比一款文本编辑器，必须具备文字输入的功能，否则它压根就不是文字编辑器。那么，有哪些策略可以帮助我们缩小和控制项目的规模吗？

• 抓住真正的需求。软件项目的交付目标表现为一组需求，需求定义了软件的功能和功能的质量。不能为客户创造价值的需求应该遭到质疑。如果实现一项需求不能为公司带来收益，就应该放弃。
• 分而治之。寻找机会将大项目分解成独立的小项目。比起由相互依赖的子系统组成的大项目，几个相互独立的小项目更容易管理。
• 设置优先级。业务环境瞬息万变，大型项目在完工之前，需求会改变多次。虽然有些需求会随业务变化甚至被取消，但是关键需求通常会维持不变。理清需求的优先级，优先实现最关键的需求。
• 尽快交付。看到演示产品之前，多数客户都不知道自己想要什么。有一幅漫画流传很广，画的是根据客户的描述搭造秋千的过程。漫画展现了不同的人对客户需求的不同理解，这些人把需求想得大复杂，几乎与软件不沾边。最后一格漫画配的文字是：“实际需求原来如此”，画面片上是一条悬挂着半空中的废旧轮胎。让客户试用演示产品，没准会发现更简单的解决方案。首先实现最重要的需求，尽快获得客户的反馈，越快越好。

敏捷方法的提倡者提倡开发“最简单有用的东西”（the simplest thing that could possibly work）。越复杂的架构越难成功实现。缩小项目规模通常会降低架构的复杂性，这是架构师提高成功机率最有效的途径。