敏捷开发学习总结(1)：传统序列式软件开发方法的缺点，以及迭代开发方法的选择

大部分公司仍使用传统瀑布模型（或序列式开发方法）进行开发

我所工作过的公司，以及我身边的朋友工作所在的公司，再加上招聘时从求职者那里所了解到的其他一些公 司的开发过程，
基本上都是使用传统的软件开发 模式 ，类拟或者就是瀑布开发模式，这种模式有如下特点：

1) 将项目的生命周期明确地划分为几个阶段，完 成一个阶段才进入下一个阶段。

2) 在项目初期希望细化所有的需求，并希望在一个阶段将需求固定后不再改变。

3) 在需求定义完毕后，在编码之前进行较详细的预 先设计，完成所有或者大部分的设计工作才开始编码。

4) 每一个阶段需要产出大量的文档作为下一阶段的输入。

传统瀑布开发 模式有哪些缺点？

由于现代软件系统的功能和设计越来越复杂，市场需求变化较快，所以 瀑布开发模式所要求的严格地完成一个阶段再进入下一个阶段被认为是太过理想化，原因有如下一些：

1) 现代大部分项目，寄望于在某一个阶段将需求固定是不现实的，太多的诱因会引起需求的变化了，例如：

    1a) 没有真正的用户参与需求定义过程，定义的需求可能很难符合最终用户 的工作习惯。

      1b) 就算把需求定义好给到最 终用户，让最终用户去确认，需求也有改变的风险，原因是用户在看到可运行的系统之前，一切都是假想，有不合理的地方他也不能完全看出来，我就假设这个用户 很认真地配合需求的确认，并假设大部分需求能在这个阶段确认了，但一些非功能性的需求用户是没有办法体现到的，例如性能、操作的流畅度等。 这就像给你一本iPhone的手机说明书，再给你一本其它智能手机的说明书，让你去评价哪一个手机更优秀，除了iPhone外观、 界面漂亮点外，你可能真的看不出iPhone到底有什么突出的优点值得这么多年轻人追棒，直到你真正拿在手上用时，体会了iPhone操作流畅的爽快感， 以及爽心悦目的窗口动态效果时，你才能体会它的与众不同之处。

    1c) 竞争者、市场需求在不断变化，用户的需求也在跟着市场进行变化，特 别是研发性的项目，“用户”与研发部之间，不像一些非研发性质的项目需求的变更有合同来约束。

2) 接下来的设计阶段假设需求已经确定，但如果需求在项目后期还会有较大变化的风险，那么早期就做较详细和较完整的设计工作可能是不适当的。

3) 那么，假设需求能够确定，设计是否能够确定呢？我的理解是，只有在我们对所在的技术领域非常熟悉的情况下才有可能，怎样才算对技术领域非常熟悉呢？

我的理解是就像一些做信息化项目的小企业，他们为A企业开发了OA办公系统，再为B企业开发相拟的 系统时，所用的技术几乎是一样的，只是业务有一些异同而以。

但如果是研发性质的公司，常常需要涉足一些陌生的技术领域，你在投入人力进入这些功能的预研之前，你很难去细化这一部分的设计，但这 些技术的预研工作通常又需要很长的工作时程，可能需要经历较长的项目周期，所以说，要在项目初期就细化好完整的设计可能会事与愿违。

4) 当使用瀑布模型（或序列开发模式）时，如果需求与用户的设想出现了偏离，这 种错误将会贯穿整个项目周期，设计受需求的影响，代码受设计的影响，直到项目接近完成，将产品交付给用户使用测试时，错误才被用户提出，这时项目已处于尾 声，为迟已晚。

如何解决传统瀑布开发模式存在的问题？

针对传统瀑布开发模式 所存在的问题， 业界提出的解决方法就是应用迭代开发方式，而敏捷开发更是在迭代开发的基础上，作了进一步的改进，敏捷开发方法由于它应用迭代和增量的开发模式，所以可以 看作是经过改进的迭代开发方法。

敏捷开发提出了以下的一些原则：
1) 假设需求总是会变化的，并欢迎需求的变化，因为需求的变化可能意味着可以提升产品的商业价值。
2) 设计是演进式的，并要保持简单设计和弹性设计，以便能快速响应需求的变化，而需求变化总是会引起设计的腐化，因此，经常性的对代码进行重构是必须的。
3) 短期持续交付可运行的系统给用户，目的是尽早取得用户的反馈。
4) 更多原则可参考书籍：<<敏捷软件开发：原则、模式与实践>>。

近年来，随着敏捷开发思想的提出，以及UP(Unified Process,统一流程) 、敏捷UP、Scrum 和XP(极限编程实践) 等一系列的实践方法得到应用，迭代、增量的开发模式得到了更多的赞誉声音，目前，最为热门的是以Scrum和XP进行组合的敏捷开发方式，已经被腾讯、华 为、上海贝尔等一些大公司所采用。

迭代、增量的开发模式 是如何进行的？

迭代开发模式会将项目周期分为多个迭代来完成，每一个迭代只实现一小部分功能， 完成一次迭代时就将系统给到用户进行演示或测试，进而及早得到用户的反馈来改进需求和设计，每一次迭代也需要经历需求分析、设计和编码和测试等多个活动， 但通常是轻量级的，项目的整个周期可能要进行十多次或更多这样的迭代。

那么，迭代和增量开发模式又是如何进行的呢？下面作一下简述：
1)    项目初期和我们现用的方法一样，会定义好产品设想以及功能列表，并对产品功能排好优先级，但与传统的开发模式不同的是，这个阶段不会去细化所有需求。
2)    根据优先级，挑选一小部分需求进行细化，项目初始阶段通常挑选高风险的、决定核心架构的、业务性质重要的功能需求来细化。
3)    针对细化的一部分需求进行设计和编码，得到可运行的软件然后交付给用户，或给用户演示并收集反馈。
4)    根据用户的反馈修改需求，并提交新版本的软件给用户，直到用户满意。
5)    重复 2~4，直到完成所有的功能。2~4 被称为一次迭代，每次迭代大约需要数周，不宜太长，越短越好，每个项目可能要经历十多次迭代。
6)    其它活动略

瀑布模型 就一无是处吗？

瀑布模型存在多年，很多项目是用它来开发完成的， 一般是这么认为，如果项目的需求可以比较稳定，开发团队对技术领域非常熟悉，从而设计可以直截了当、理解透彻，则瀑布maybe是可行的。

关于项目如何在瀑布模型（序列开发）和迭代之间进行选择的一些建议，可参考<<代码大全 2>>一 书中，关于序列开发与迭代开发之间的选择的这个章节。

本文总结：

并不是说我们选用某种开发模式，或者更前进的开发技 术，就能保证项目走向成功，我们应该要做的是，参考业界的一些成功的实践经验，不断地对我们所用的方法进行检讨，合理地调整我们的开发方法，使在现有的开 发资源的情况下发挥得最好。