敏捷能够应用于所有项目吗？

在前面的文章中我们曾讨论过敏捷和瀑布，并曾谈到二者划分的维度是范围不确定性，那么今天我们再深度分析一下，在这里我想先问一个问题，敏捷能够应用于所有项目吗？我直接给答案吧，答案是不能，下面我们来分析一下。

敏捷是什么?

敏捷是使用适应型生命周期来替代预测型生命周期。预测型生命周期预先定义和设计产品，它的目标是根据计划来实现设计。那么，当无法对产品进行预测时，就可以使用适应型生命周期。在适应型生命周期中，它遵循一个反馈环，那就是先创建一个小的但可以使用的产品的子集，并通过对它们的使用获得反馈，然后根据获得的反馈设计和创建下一个产品子集。下面的动画演示了敏捷是如何在Scrum框架中工作的:

下图演示了预测型方法和适应型方法的不同：

为什么敏捷不能应用于所有的项目?

对于一个适应型生命周期而言，有两个主要的需求，在这两个需求中都需要启用真正的反馈环:

1、增量交付

增量交付意味着你应该一步一步地创建产品的“可用”子集，而不是在项目结束时一次性交付。比如说一个软件系统：你可以拥有一个简单的版本，并通过每隔几周添加新特性来创建一个新版本(增量)。每个版本都是可用的，新的特性为用户/客户带来了更多的价值。而无法使用的可交付物不能创建所需要的真实反馈。比如说在建筑类项目当中，你能想到可能有用的子集吗?你能假设使用一个有墙但没有门窗的建筑吗？即使可以，你是否能够从完成的墙中得到反馈来决定门窗?

2、迭代开发

为了增量交付，你需要迭代开发，这意味着你应该重复开发过程。对于一个软件来说，你需要单独的设计、编码、集成和测试每一个产品的子集，而不是将所有的东西一起设计、一起编码，然后一次性集成(瀑布模式)。比如在建筑类项目当中有可能实现吗？你能在不设计建筑其余部分的情况下设计地基吗？不可能，因为在这一类产品中，元素之间存在不可避免的依赖关系。

这就是为什么敏捷并不能应用于每一个项目当中，就好比不能应用在建筑类项目。

但是，你可以确定一个项目的某些部分，它们可能具有迭代开发和增量交付的能力。对于一个建筑类项目来说，室内装饰是一个很好的例子，它可以用一个敏捷方法来完成。

你可能会问，在一个建筑类项目当中，使用了时间盒（time-box）技术，并且在每个时间盒的结束时都会提交可交付成果。但是，由于前面解释过的原因，这些时间盒并不是迭代，完成的交付也不是增量。在这种情况没有使用适应型生命周期，因此，并不是敏捷。

你可以使用很多所谓的敏捷实践，但是它们不会让你变得敏捷。我们在后面的文章中会专门讨论这样一个话题。