敏捷软件开发VS传统软件开发

敏捷软件开发VS传统软件开发

近年来，敏捷软件开发方法受到越来越多的关注。上图显示的是2001-2011年之间scrum与CMMI的相对搜索量变化趋势比较图。从图中我们可以看出

• 2004年CMMI的搜索量还是scrum的3倍
• 2007年CMMI的搜索量被scrum超越
• 2011年CMMI的搜索量已经不足scrum的$\frac{1}{3}$了

到今天，scrum的搜索热度已然是CMMI的10倍左右了。

这些数据告诉我们：敏捷软件开发方法很火，而且越来越火。那么为什么敏捷软件开发会这么火，或者说，相对于传统软件开发它究竟具有什么巨大的优势？
本文将以敏捷软件开发传统软件开发的概念为引，对它们进行多方面的对比，并谈谈笔者对敏捷开发火起来原因的一些见解。

初窥敏捷与传统开发

敏捷软件开发是一种应对快速变化的需求的一种软件开发能力。它作为一种新型的软件开发方法，从1990年代开始逐渐引起广泛关注。其中敏捷一词来源于2001年美国雪鸟滑雪胜地敏捷方法发起者和实践者的一次聚会。在雪鸟会议上，聚会者起草了敏捷软件开发宣言，宣言强调了个体和互动，客户合作以及响应变化，这些也是敏捷软件开发的代表特征。

传统软件开发的特点是有一系列有序的步骤：需求分析、设计、编码、测试和软件交付。开发者在需求分析阶段充分解读用户需求，在设计阶段得到软件的大概架构，在编码阶段进行代码的编写，之后经过各种类型的测试后进行软件交付。

敏捷与传统开发对比

至此，我们对两种软件开发已经有了一个初步的了解，下面就让我们来对敏捷软件开发和传统软件开发从不同的角度进行对比。

用户参与度

在传统软件开发中，开发者需要用户在软件开发之前提供一份详细的需求，在软件开发完成后再进行交付。对比起来，敏捷式软件开发中迭代式的交付显得更为灵活。在敏捷式软件开发过程中，用户始终参与其中，修订每个阶段的工作并提出改进意见，显然，用户参与度更高。

用户满意度

在敏捷软件开发中，开发者各个阶段都会与用户进行交互，以适应随时可能发生的需求变化。这种迭代式的改进一方面使得他们可以更加容易地修改产品，另一方面极大地提高了用户的满意度。

开销

开销在软件开发过程中是一个关键问题，尤其是返工成本。在传统软件开发中，测试是开发工作全部完成后的一个单独环节。通常产品在经过一系列测试后才返工，造成返工成本的急剧增加。在敏捷软件开发中，测试不会单独作为一个阶段，而是分散在各个迭代过程中。这样每个阶段的潜在问题更容易被发现并被解决掉，因此敏捷软件开发相较于传统软件开发返工成本要更低一点。

开发灵活性

《The Agile Samurai》一书曾写到关于软件项目的三个事实:

1. 不可能在项目开始的时候就收集到所有的需求
2. 不管收集到什么样的需求，它一定会发生变化
3. 要做的功能，一定会超过预期时间和金钱允许的范围

每次软件开发都是对未知的探索，我们无法在开始时就预知一切。在传统软件开发中，开发和需求分析的职能是分离的：程序的架构由客户的需求决定，经过专业需求分析员分析，最后由程序员进行实现。但在敏捷软件开发的过程中，各个阶段程序员与用户之间都有充分的交互，项目在结构和功能方面都具有灵活的可配置性。由此不难看出，传统软件开发更倾向于不考虑项目后续需求的变化：在项目开始时预测用户需求，然后冻结需求，制定相应的开发计划，再按照计划执行。与之形成鲜明对比的是，敏捷软件开发通过不断的用户反馈动态调整需求，最终达成目标。这种自适应的特性使得敏捷开发的产品更符合实际需求，下图形象地展示了这一过程

项目文档

传统软件开发在项目交付前的每个阶段都有严格的文档编写和校对，因此，传统软件开发的文档编写过程也更容易一些。而在敏捷软件开发过程中，是先产生代码，再产生文档。文档编写和校订的主要参考来源只有代码本身和程序员添加的注释。从沟通和理解项目的角度来说，这方面是敏捷软件开发的一个缺陷。

系统规模

随着系统规模的增长，面对面的沟通就愈加困难。敏捷开发依赖于面对面的沟通，因此敏捷方法更适用于较小的队伍，比如40、30、20、10人或更少。在实际工程中，我们可以选择传统软件开发来解决规模较大的项目，或者可以将大型系统拆分成很多小规模的项目，再利用敏捷软件开发逐一实现。

补充

敏捷开发有非常多的优点，但只运用敏捷软件开发并不是一定会成功。由反摩尔定律可知，同样的产品所能获得的价值会随着时间按一定斜率下降。所以对于产品来说，时间关乎生死。交付产品的时间不仅影响获得回报的时间，更影响到产品价值的多少甚至是有无。敏捷软件开发的应对之道是改变价值的交付模式。在敏捷软件开发模式下，产品开发进程被划分成固定时长的短迭代周期，每一个迭代产出潜在可交付的产品增量，产品的一部分价值得以实现。但只有增量是远远不够的，交付可持续才是有意义的。下面以Netscape为例来说明可持续交付对敏捷开发的重要性。

Netscape(网景)是第一家尝试利用新生万维网的公司，它曾最高占据过浏览器市场80%的份额。但2007年，AOL停止了对Netscape的支持。Netscape的衰退发生在短短几年内：从1997年到2001年，Netscape与微软在浏览器的市场上进行了激烈的竞争。1997年6月Netscape推出了Netscape4.0，其后的三年半时间里，Netscape没有推出过一个主要版本，而微软先后推出了突破性的IE4.0和IE5.0，取得了完胜。1997年微软推出IE4.0，1999年推出IE5.0，此时IE在功能上远超Netscape4.0，而Netscape4.0面临越来越多奇怪的bug。更严重的是，Netscape的代码十分糟糕，以至于团队认为无法基于它再做出修改，最终决定重写代码。2001年初，Netscape终于推出了6.0（中间无5.0）但此时Netscape的市场占有率降到了5%以下，浏览器之争胜负已定。

Netscape的工程师们看着Netscape的市场份额急剧萎缩却无法在产品上采取行动，一定程度上Netscape死于自己糟糕的系统质量。长期忽视质量的价值交付最终将无法持续。敏捷软件开发遵循迭代和增量的开发模式，价值得以更快的实现，但如果忽略了质量，这也意味着更快的累积问题。
迭代交付过程中忽略质量容易引发诸多问题：

1. 前期迭代的烂摊子始终没有清理，问题越积越多
2. 既有功能越来越多，迭代中的测试工作量越来越大
3. 既有功能被新的发布破坏
4. 代码越来越复杂，添加一个新的功能所需工作量越来越大

因为上述原因，我们需要增强敏捷软件开发的内建质量，主要手段有如下两种：

1. 从根源上预防问题的发生。使用及时和有效的自动化测试，利用一些管理和技术实践，如持续集成、结对编程等。
2. 在开发过程中不让问题累积。每一个迭代的交付都要达到指定的质量标准：质量标准包括用户可见的外部质量（集成测试和性能测试）和系统的内部质量（不良代码设计是否被重构，是否包含必要的自动化测试覆盖等）。

总结

综合上述对比来看，我们可以得出敏捷开发相比于传统软件工程的几大优势：产品更符合用户期望，返工可能性更小，返工成本更低，采取迭代开发的模式，具有较强的灵活性。但敏捷开发同时对团队要求较高，它需要团队成员面对面的沟通，持续高质量的交付，所以它更适合人数较少的精英团队。面对规模较大的工程中，可以选择将其拆分成若干个子项目，再使用敏捷开发的方式进行。

转载于:https://www.cnblogs.com/vivianBlogs/p/agile_vs_traditional_software.html