敏捷式软件开发的特征
敏捷软件开发以交付而不是构造为核心，敏捷软件开发方法强调交付对客户有价值的软件，而不是用户需求中所描述的软件。
敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。这些开发方法的具体名称、理念、过程、术语都不尽相同，但是它们都强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、迭代交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。
敏捷方法虽然在过程和手段上和一些传统方法有很多相似之处，比如迭代的开发模式、注重软件的质量等，但是它和传统软件开发方法在根本上有很大的不同:敏捷软件开发以交付而不是构造为核心，敏捷软件开发方法强调交付对客户有价值的软件，而不是用户需求中所描述的软件。
敏捷方法和传统方法的最根本、最核心的不同就是软件交付的方式，也就是敏捷软件交付。
*传统软件工程的误区
软件工程产生最初产生于一个简单的类比:人们发现研制一个软件系统，同研制一台机器或建造一座楼房一样，有很多共同之处。从而希望参照借鉴机械工程、建筑工程中的一些管理技术来进行软件开发，于是产生了软件工程。
而软件工程从机械工程和建筑工程中继承的最核心的部分，就是确立一个用户的最终目标，然后通过逐步求精的工程化方法达到到这个目标。
通过引入工程化的方式，我们可以在一定程度上，对每一个求精步骤进行评估、计划和控制，进而实现对整个软件开发过程的有计划有组织的控制。
这一类比看起来因果明晰顺理成章，软件也应该按照机械工程的这个方法，也就是构造性方法。可惜的是，这些完美的类比和推论有一个根本上的误区，那就是软件行业与建筑行业，软件行业与机械制造行业是根本不同的行业，两者是不能够简单类比的。
它们的根本差异主要体现在下面两个方面:
工程的价值
软件工程与传统建筑、制造工程的价值体现不同。
在建筑行业中，一栋按质按量按时建设完成建筑其本身就具有价值。而软件行业在这个信息化的社会中所处的地位略微有些特殊:一个按质按量完成但未交付上线的软件其本身所具有的价值极其有限的;一个按质按量完成但却根本不能满足企业需要的软件就没有任何价值。
软件的存在性和软件的有用性并不具有传统建筑、机械制造行业那种天然的内在关联。在建筑行业中，一栋建筑只要质量过关总可以保证它是有用的。但是不幸的是，很多质量过关的软件确是根本无用的。
因此，软件工程的价值体现在实现软件的有用性而不是把软件完成。传统行业由于天然的优势可以不用特殊地考虑制品的有用性，而仅考虑如何更好地完成该制品就可以。这一点是软件工程和传统建筑、机械制造工程的根本不同，也是传统软件工程的一个根本误区。
商业环境敏感度
由于软件工程和传统工程在价值取向上有很大的不同，这两种工程在实施过程中对用户所处的商业环境敏感度有很大的不同。
对于传统行业而言，在项目的初期对与项目最终实现的用户价值会有一个大致的估算，这个估算值在传统行业中是一个相对稳定的值，也就意味着项目初期的用户价值估算受到用户所处商业环境影响较小。我们可以用一个常数函数来表示，如图1中目标用户价值曲线所示;随着项目的发展以及一系列的逐步分解求精步骤，最终我们可以实现最初的既定用户价值目标。
通过上述分析我们发现，在项目终期由于我们基本上可以实现了最初估算的客户价值，纵然客户的价值期望随商业环境的变化产生了变化，大多数用户最终也会接受并认可这个工程的价值。
通过上述分析我们发现，软件工程比起传统的工程学受到用户所处的商业环境影响更为明显，用户商业环境的变化直接影响了软件的价值。因此，用户往往在经过长时间的等待之后，却拿到一个低于预估价值的软件。用户对于软件不满意也就是理所应当的。
*从重视软件价值开始
传统软件工程方法受到传统方法的影响，错误地认识了软件价值的所在，过于强调过程与软件价值的必然因果性关系，忽略了客户商业环境对软件价值的影响。
由此我们可以断言:忽略或错误定义软件价值、漠视软件价值随客户商业环境的变化的传统软件工程学方法，都不可能解决软件行业所面对的问题。要解决这些问题，首先要解决的问题就是软件价值与客户商业环境变化的问题，其次才是工程性的问题。
*应用敏捷方法的优势
相比传统软件过程，敏捷方法在如下几个方法具有显著的优势:
短期交付
如前所述，软件的实际价值体现在对于企业的有用性上。一个软件越早交付上线就能够越早地为企业提供价值，也就能越早地体现出软件以及构造它的工程的价值。敏捷方法中一个广为人知的最佳实践称作小版本发布，也就是将传统项目周期分为更小的周期，在每一个周期结束的时候提供可以生产上线的应用系统。
可以看出敏捷方法强调缩短软件的上线周期，使软件可以更早地为用户发挥实际价值。
文章来源于领测软件测试网 https://www.ltesting.net/
