敏捷流程破解瀑布式流程

下面就让我们来看看敏捷流程如何将瀑布式流程的问题逐一破解：

Ø 瀑布式流程问题之一：

版本发布的时间越来越长。在敏捷流程中，版本是由一系列增量集成在一起组成的，这些增量通过一个一个迭代按顺序开发。我们还可以在任意时间停止迭代。一旦发现产品的价值已经达到最大，尤其是发现软件里过半的功能很少被使用的时候，就可以停止迭代。我们还可以在到达交付期限或者预算上限的时候，停止迭代并发布软件。我们只会开发并积累有价值的增量。

Ø 瀑布式流程问题之二：

无法按时发布。在敏捷流程中，版本的发布延迟最多不会超过30天，因为每个迭代的最长期限就只有30天。当到达交付期限的时候，就可以交付累积的增量。由于不会在迭代中开发低价值的功能，因此可以比以往更早地发布完整的系统。在传统开发流程中，常用功能占所有功能总数的不到一半。而在敏捷流程中，我们根本不会在不常用的功能上浪费时间。

Ø 瀑布式流程问题之三：

在版本发布的最后阶段让软件稳定的时间越来越长。在敏捷流程中，每个迭代所产生的增量都是完整和可用的，后续迭代所产生的增量都会包含之前所有迭代产生的增量，因此任何迭代产生的增量都是完成且可用的。也就是说，没有软件稳定化时期，因为软件一直保持稳定。

Ø 瀑布式流程问题之四：

做计划的时间越来越长，而且不准确。在敏捷流程中我们不再做大而全的计划，而只是设定最终目标，然后确定为了达到该目标所需的高价值功能和特性，同时还会确定交付日期以及估算成本。这样在第一个迭代开始前做计划所需的时间通常只有瀑布式或预测型流程的20%。我们只会为即将到来的迭代的需求做详细的计划，因此我们把每个迭代的计划称为“及时雨计划”。另外值得注意的是，需求是涌现的，在评审迭代产生的软件增量的时候，我们可能会发现下一个迭代需要实现的最佳需求。

Ø 瀑布式流程问题之五：

在发布期间很难进行改变。版本发布中期的概念在迭代增量式项目中已经不复存在了。我们能够以最小的代价，在每个迭代开始前发现或者提出需求。

Ø 瀑布式流程问题之六：

质量持续恶化。在敏捷流程中，每个迭代产生的增量都是完整可用的。因此，增量必然已经通过质量测试。而后续迭代产生的增量同样要满足相同的质量要求，也就是说我们再也不必在项目的最后阶段为了赶上交付期限而牺牲质量，因为质量始终伴随着这个软件的整个开发过程。

Ø 瀑布式流程问题之七：

拼命竞赛进度使员工士气受挫。版本稳定化阶段已经不再需要了，因此加班的“死亡之旅”也随之而去。