浅谈敏捷开发

敏捷型（agile〕的软件开发方法是在过去几年中蓬勃兴起的一种软件开发方法，以矫正官僚繁琐过程、许可对过程进行自主调整为特征，在软件业引起了极大的兴趣。
事实上，与敏捷开发方法相对的，是借鉴了其他工程领域的实践的一种软件开发方法，我们把它们称为工程方法（engineering methodologies）（另一个广泛使用的词汇是计划驱动方法（plan-driven methodologies）），这种方法已经出现了几十年，到目前为止，已经可以说的上是非常成熟的一种软件开发方法。
但是，即使是这种比较成熟的工程方法，也并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是它们的官僚繁琐，要是按照它的要求来，那么有太多的事情需要做，而延缓整个开发进程。
在软件开发过程中，一般情况下，一个工程的程序编写时间和它所需要的调试时间是相当的，甚至于有些时候调试的时间占据了更重的比例。这其中很大的一个原因就是多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” （code and fix〕。设计过程充斥着短期的、即时的决定，而无完整的规划。 这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加 入新的功能就越来越困难。同时错误故障越来越多，越来越难于排除。
于是，工程方法就基于软件开发的预见性，提出了将设计与建造分离开来。这种方法从其他工程领域，如土木工程借鉴而来，这类工程实践中，在实际建造之前，通常非常强调设计规划。 工程师首先要画出一系列的图纸，这些图纸准确地说明了要建造什么以及如何建造（包括部分和整体〕。
这种设计方法的基础，就在于软件开发的预见性，但是，需求真的是可以预见的吗？在很多项目都有这样一种情况，开发人员跑来抱怨说，“这个项目的问题是需求老是在变”。软件的“不可触摸”性也是一个原因。在系统建成之前，有时很难判断一项 功能的具体价值。也就是说，只有当你在实实在在地使用系统时，你才能 知道哪些功能是有用的，哪些没什么用。这样的结果颇具讽刺意味，即人们期待需求应该是可变的。但是，即使你能把所有的需求都固定下来，并不意味着你的开发就是阳光灿烂了，你可能仍然会在昏暗之中。在当今的经济形势下，决定并推动软件系统功 能特性的商业因素飞快地变化着。现在一组很好的功能六个月以后可能就不那 么好了。 商业世界并不会因你的系统的需求固定下来了而停止不动，商业世界的许多变化是 完全不可预测的。软件开发的一切都取决于系统需求，如果需求不固定，你就不能制订出一个可 预见性的计划。所有，从理论上来说，通过传统的工程方法来减轻软件开发的工作负担，降低开发成本，是不切实际的，或者说是事倍功半的。
针对软件开发的不可预见性，敏捷软件开发方法提出了迭代的开发过程，要求每次的开发周期要很短，迭代式开发的要点是经常不断地生产出最终 系统的工作版本，这些版本逐部地实现系统所需的功能。它们虽然功能 不全，但已实现的功能必须忠实于最终 系统的要求，它们必须是经过全面整合和测试的产品。
这样做的理由是：没有什么比一个整合了的、测试过的系统更能作为一个项目 扎扎实实的成果。文档可以隐藏所有的缺陷，未经测试的程序可能隐藏许多缺 陷。但当用户实实在在地坐在系统前来使用它时，所有的问题都会暴露出来。 这些问题可能是源码缺陷错误（bug〕，也有可能是对需求理解有误。
说到底，软件开发所遇到的问题，是不断发展的需求和固化的开发产品之间的矛盾，这种矛盾在现实中的所有涉及到设计开发的工程中都有所体现，比如北京的道路是以600万的人口出行为需求建设的，经过20多年的发展，直到现在北京的常住人口超过2000万的时候就显现出了当时设计时的各种弊端。而在软件开发过程中，这种问题表现的更加明显，这是因为信息产业的发展速度实在是太快了，一个在几个月前很新的产品，在几个月后很可能就会被市场淘汰，所以，我们不得不承认这个事实，我们所开发出来的任何软件，都是落后于这个时代的需求的。
所以，这就说明在软件开发之初就想设计出来一个天衣无缝的计划，是完全不可能的，于是，这就体现出来演进式敏捷开发的优势来，并不拘泥于一个既定的而且毫无疑问是过时的计划，又不是纯粹的无计划的“边写边改”，计划随时在更改，要求在最短的时间内做出一个能够运行的版本，相对于其他软件开发过程的遥遥无期，这种已经完成了的版本，即使它本身还存在着各种不完美的地方（我们必须要承认，任何软件都存在不完美的地方），但这已经能够大大方便我们的调试了，这也是目前为止我们所能探索到的最优的折中办法了。