敏捷软件开发以交付而不是构造为核心,敏捷软件开发方法强调交付对客户有价值的软件,而不是用户需求中所描述的软件。
敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。这些开发方法的具体名称、理念、过程、术语都不尽相同,但是它们都强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、迭代交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。
敏捷方法虽然在过程和手段上和一些传统方法有很多相似之处,比如迭代的开发模式、注重软件的质量等,但是它和传统软件开发方法在根本上有很大的不同:敏捷软件开发以交付而不是构造为核心,敏捷软件开发方法强调交付对客户有价值的软件,而不是用户需求中所描述的软件。
敏捷方法和传统方法的最根本、最核心的不同就是软件交付的方式,也就是敏捷软件交付。
*传统软件工程的误区
软件工程产生最初产生于一个简单的类比:人们发现研制一个软件系统,同研制一台机器或建造一座楼房一样,有很多共同之处。从而希望参照借鉴机械工程、建筑工程中的一些管理技术来进行软件开发,于是产生了软件工程。
而软件工程从机械工程和建筑工程中继承的最核心的部分,就是确立一个用户的最终目标,然后通过逐步求精的工程化方法达到到这个目标。
通过引入工程化的方式,我们可以在一定程度上,对每一个求精步骤进行评估、计划和控制,进而实现对整个软件开发过程的有计划有组织的控制。
这一类比看起来因果明晰顺理成章,软件也应该按照机械工程的这个方法,也就是构造性方法。可惜的是,这些完美的类比和推论有一个根本上的误区,那就是软件行业与建筑行业,软件行业与机械制造行业是根本不同的行业,两者是不能够简单类比的。
它们的根本差异主要体现在下面两个方面:
工程的价值
软件工程与传统建筑、制造工程的价值体现不同。
在建筑行业中,一栋按质按量按时建设完成建筑其本身就具有价值。而软件行业在这个信息化的社会中所处的地位略微有些特殊:一个按质按量完成但未交付上线的软件其本身所具有的价值极其有限的;一个按质按量完成但却根本不能满足企业需要的软件就没有任何价值。
软件的存在性和软件的有用性并不具有传统建筑、机械制造行业那种天然的内在关联。在建筑行业中,一栋建筑只要质量过关总可以保证它是有用的。但是不幸的是,很多质量过关的软件确是根本无用的。
因此,软件工程的价值体现在实现软件的有用性而不是把软件完成。传统行业由于天然的优势可以不用特殊地考虑制品的有用性,而仅考虑如何更好地完成该制品就可以。这一点是软件工程和传统建筑、机械制造工程的根本不同,也是传统软件工程的一个根本误区。
商业环境敏感度
由于软件工程和传统工程在价值取向上有很大的不同,这两种工程在实施过程中对用户所处的商业环境敏感度有很大的不同。
对于传统行业而言,在项目的初期对与项目最终实现的用户价值会有一个大致的估算,这个估算值在传统行业中是一个相对稳定的值,也就意味着项目初期的用户价值估算受到用户所处商业环境影响较小。我们可以用一个常数函数来表示,如图1中目标用户价值曲线所示;随着项目的发展以及一系列的逐步分解求精步骤,最终我们可以实现最初的既定用户价值目标。
通过上述分析我们发现,在项目终期由于我们基本上可以实现了最初估算的客户价值,纵然客户的价值期望随商业环境的变化产生了变化,大多数用户最终也会接受并认可这个工程的价值。
通过上述分析我们发现,软件工程比起传统的工程学受到用户所处的商业环境影响更为明显,用户商业环境的变化直接影响了软件的价值。因此,用户往往在经过长时间的等待之后,却拿到一个低于预估价值的软件。用户对于软件不满意也就是理所应当的。
*从重视软件价值开始
传统软件工程方法受到传统方法的影响,错误地认识了软件价值的所在,过于强调过程与软件价值的必然因果性关系,忽略了客户商业环境对软件价值的影响。
由此我们可以断言:忽略或错误定义软件价值、漠视软件价值随客户商业环境的变化的传统软件工程学方法,都不可能解决软件行业所面对的问题。要解决这些问题,首先要解决的问题就是软件价值与客户商业环境变化的问题,其次才是工程性的问题。
*应用敏捷方法的优势
相比传统软件过程,敏捷方法在如下几个方法具有显著的优势:
短期交付
如前所述,软件的实际价值体现在对于企业的有用性上。一个软件越早交付上线就能够越早地为企业提供价值,也就能越早地体现出软件以及构造它的工程的价值。敏捷方法中一个广为人知的最佳实践称作小版本发布,也就是将传统项目周期分为更小的周期,在每一个周期结束的时候提供可以生产上线的应用系统。
可以看出敏捷方法强调缩短软件的上线周期,使软件可以更早地为用户发挥实际价值。
*用户价值驱动
在传统软件工程方法中,我们已经注意到一个事实,客户对于需求的认识往往是含混不清的,不能够简单地认为用户在需求说明中所描述的软件就是他们真正想要的软件。
因此传统软件工程的方法强调了对于需求的管理,从而形成了以需求驱动整个软件开发的方法学。但是,传统软件工程方法同时忽略的一个问题是,用户对于需求价值的评估随时间的变化也有一些不同。
传统方法往往无法作做到令人满意需求价值跟踪管理。虽然优先级重排等方法在一定程度上代表了传统方法对于需求价值的重视,但是由于传统方法中软件的构造和软件的实施有较长的周期间隔,用户的反馈往往严重滞后于软件开发过程,从而造成高昂的成本。同时用户缺乏一个可以实际上线的软件,大多数价值变化来自于简单的臆想,因此估算价值和实际价值变化存在较大的出入。
敏捷软件开发强调缩短第一版本上线周期,持续为用户提供有价值的软件。用户对于需求价值的评估都来自于实际的使用评价,而不是无根据的猜想,因此敏捷方法中的价值估计具有更高的可靠性。同时敏捷开发方法中,上线与软件开发并不是工程的截然不同的两个阶段。在大多数的时间里,上线的软件和围绕这个软件的开发是同步进行的。用户的反馈以及变化的需求可以较容易的得到实现。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
“以建应变”:敏捷+DevOps驱动数字化转型
数字化转型由软件驱动。如今在数字化转型中,交付软件实际上处于每一个业务的核心,这一软件趋势也正好与CA Technologies一直强调的应用经济相一致。
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
开发运维一体化(DevOps):协作是成功的保障
如今的IT部门存在一个矛盾:敏捷开发者希望可以快速部署常规软件,而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响