敏捷开发与传统软件工程

 

在网上查了许多资料，也看了国内许多人对敏捷开发的见解，大体写一下本身的理解。

传统软件工程是在OS/360的失败后逐渐发展造成的。最开始的软件开发更像是艺术创做，十分依赖程序员我的的技术，软件的质量也基本靠程序员的责任心保证。但随着软件规模愈来愈大，愈来愈复杂，开发周期与成本也愈来愈不受控制，同时软件的可靠性也很难保证。

为了解决这些问题，软件开发行业开始学习工程中的管理方法，为软件开发制定了一套规范，管理软件生存周期的各个阶段。好比普遍使用的瀑布模型，核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协做，采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，规定了相互的衔接次序，如同瀑布流水，逐级下落。传统的软件工程能够保证软件开发过程的可靠与可控，而且可以依靠文档有效的整合不少人的工做，像操做系统，搜索引擎这些有不少人参与的项目，都是在软件工程的帮助下顺利开发的。

然而，传统的瀑布模型也有她的弊端。多数状况下客户并不知道本身真正想要什么，只是有大体的想法。并且如今的软件行业，发展太快，无论先前的需求分析作的多么细，交到客户手中，总会有各类各样的问题，极可能最后获得的产品和客户的指望相差甚远，而这时候修改已经十分困难。

因此就有了迭代开发这样的方法。在迭代式开发方法中，整个开发工做被组织为一系列的小项目，被称为一系列的迭代。每一次迭代都包括了定义、需求分析、设计、实现与测试。采用这种方法，开发工做能够在需求被完整地肯定以前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工做。再经过客户的反馈来细化需求，并开始新一轮的迭代。这样能够更早的获得用户反馈，修改开发中的误差，下降风险。

敏捷像是进行了改进的迭代开发方法。同之前的软件管理方法相比，更加注重人这个因素在软件开发中的做用。敏捷开发强调面对面的沟通，不论是开发团队仍是客户。经过频繁交付新的软件版本，以及自组织的团队，来适应需求的变化并完成项目。

    人和交互 重于过程和工具。

    能够工做的软件 重于求全而完备的文档。

    客户协做重于 合同谈判。

    随时应对变化 重于循规蹈矩。

敏捷开发相对于传统软件工程，下降了文档的做用，而增强了人在开发过程当中的地位。强调团队的高度协做，优先完成重要的任务，充分发挥人的主观能动性。从而相对于传统的软件工程，敏捷开发对变化有着更好的适应性，更适合于创新型软件的开发。但相对的更加依赖于人，团队若是出了问题，相应的开发进度也会受到影响。

 

实际的工做中，每种开发方法都有其适用的地方。当竞争特别激烈的时候，每每需求变化也很迅速，敏捷开发能够快速适应环境抢占市场。但敏捷开发也会遗留一些问题，好比团队的人员变更，以及凝聚力都会影响软件的后续生存，传统软件工程更擅长于软件的长期管理，以及质量的控制。传统软件开发方法与敏捷开发各有侧重，因此，更好的办法是根据具体的状况在多种开发方式中进行选择。

（机器和人的区别大概也是这种状况，机器一丝不苟定下计划就几乎不会出错，可是对于预料以外的状况几乎没法作出反应，而人脑灵活而富有创造力，但经常会犯错，也有偷懒的时候。也许这中间能够找到一个平衡灵活性与正确性的点，软件工程从此的探索道路，应该也是在灵活性与稳定性之间找到平衡）

 

 

参考：

百度百科《瀑布模型》

百度百科《迭代式开发》

百度百科《敏捷软件开发》

以及知乎上关于敏捷开发的讨论