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

Posted 2020-08-15 14061064

软件工程的概念早在1968年便被提出，一路发展至今，也演变为了一门学科，而其中的方法也是层出不穷。这里，我们便讨论一下敏捷软件开发与传统软件工程的异同。说到敏捷软件开发，其实很早便有这类方法在实践中运用了，不过在2001年，一些牛人搞出了一个“敏捷宣言”，从此便明确了敏捷软件开发的方法。

个体和互动：高于 流程和工具。

工作的软件：高于 详尽的文档。

客户合作：高于 合同谈判。

响应变化：高于 遵循计划。

 

对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。

我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。

经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。

业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。

围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。

在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。

可以工作的软件是进度的主要度量标准。 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。

对卓越技术与良好设计的不断追求将有助于提高敏捷性。

简单——尽可能减少工作量的艺术至关重要。

最好的架构、需求和设计都源自自我组织的团队。

每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

 

敏捷软件开发又是在何种背景下产生的呢？

 

随着软件行业发展壮大，软件系统的规模也越来越大，复杂程度越来越高，开发周期与开发成本便面临极大的挑战，与此同时，软件的可靠性也无法很好的保证。为解决这一系列问题，软件行业便开始借鉴传统的工程学、管理学方法。

以“瀑布模型”为代表的传统软件开发模型开始出现，它们针对软件生命周期的各个阶段提供了一套规范，以期使工程的进展达到预期的目的。核心强调在软件开发活动中，所有的活动计划，日程安排，交付工作都要直接或间接的和需求保持一致，同时强调软件需求必须形成“文档”。最初的软件(20世纪60-70年代)的顾客都是大型研究机构，军方，NASA这些，他们需要软件系统来搞科学计算，军方项目，和登月项目等，这些系统相当庞大，对准确度要求相当高。20世纪80年代到90年代中，软件进入了桌面软件的时代，开发的周期明显缩短，各种新的方法开始进入实用阶段。但是软件发布的媒介还是软盘，CD，DVD，做好一个发布需要较大的经济投入，不能频繁更新版本。互联网时代，大部分的服务是通过网络服务器端实现，在客户端有各种方便的推送(push)渠道。由于网络的转播速度和广度，知识的获取更加容易，很多软件服务可以由一个小团队来实现。同时技术更新的速度在加快，那种一个大型团队用一个固定技术开发2-3年再发布的时代已经过去了。用户需求的变化也在加快，开发流程必须跟上这些快速变化的节奏。

这种基于计划的生命周期的软件开发方法曾极大地促进了软件行业的发展，但现如今却并不能很好的适应社会。为了适应现代的商业环境，与之对应的敏捷软件开发方法提了出来。

 

那敏捷软件开发又是如何运作的呢？

 

个体和交互 胜过 过程和工具

其实便是更注重人与人的交流，而不是文档的约束。敏捷开发强调把关注点定位到“人”上，其背后的哲学思想可追溯到康德的“人即目的”。同时，主张面对面交流和客户参与开发，弥补了缺少文档而产生信息流通不畅问题，认为开发人员之间、开发人员和客户之间相互协作、相互信任、彼此尊重是保证沟通成功的必要条件。

看似一个深奥的算法可以节省很多硬件上的压力与花销，但在现今这种人力花销更加巨大的环境，易读易扩展的程序节省的人力将为公司带来更多利益。很多聪明的程序员也许可以发现奇妙的方法节省20%的硬件开销，然而他们使得源程序难懂并且难以维护，表面上他们节省了许多硬件的开销。但财务事实告诉我们，如果程序简单而且容易扩展，我们将至少节省10%的人力开销，这将是一笔更大的节省。同时，软件开发的职业本身也决定了数量少但精干的团队的效率与产出大于臃肿、混乱的大团队。敏捷开发一般适用于20-40人、甚至更少。

 

可以工作的软件 胜过 面面俱到的文档

区别于传统的软件开发模式，客户只有在系统被开发完成以后才能真正去体会它。敏捷编程通过要求不断交付可用的软件，周期越短越好，加强客户的反馈来缩短开发的周期，同时获得足够的时间来改变功能和获得用户的认同。

可用的软件可以让客户更直观的提出更多建议与需求，区别于工业社会的利用流水线、规模化的生产模式，信息时代更强调对用户需求的快速响应。标准化生产所带来的低成本、高可靠性的特点不能直接保证市场的高份额。相反，对用户需求的细腻把握和快速响应却是以用户为导向的服务型公司的生命线。

 

客户合作 胜过 合同谈判

敏捷开发要求在项目过程中，业务人员与开发人员必须在一起工作，参与开发，采用高效信息的交互平台以及能够减少歧义沟通和交流的方式进行支持。敏捷方法完成了从重视文本到重视对话，从重视书写到重视理解的转换。

很简单的道理，那便是用户无法对其自身需求进行有效描述。就像iPhone，在乔布斯没有推出iPhone前，用户并不知道他们需要智能机，更准确地来说就是无法对智能机的需求进行有效描述的，他们不知道他们想要触屏，想要在手机上做什么，换句话说其实是用户并不知道什么可以实现，什么无法实现，怎么样的实现会有一个良好的化学反应。这也就是为什么诸如诺基亚、摩托罗拉等公司失败的原因之一。他们不是没有市场部门，不是没有进行市场调研、用户需求分析，问题在于一般用户在缺乏相关知识与指导的情况下是无法对自身需求进行有效描述。这一缺陷在市场竞争随着节奏的加快显得愈发致命。

 

响应变化 胜过 遵循计划

敏捷开发的口号是拥抱变化，即欢迎对需求提出变更，甚至是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

信息世界发展如此之快，创业公司更是数不胜数，一个想法的成功，势必会带领一个热潮，占得先机才能得到更多利益。现代社会最重要的特点就是多元化，用所谓的“互联网思维”就是“去中心化”，具体到个人应该就是Open mind。这一社会现实反应在软件开发上就是 把想法变成实际的成本变得相当较低。但与此同时，快速变化的商业大环境也对执行力提出了高要求，而执行力的关键指标就是对变化的快速响应。

 

说到底敏捷软件开发便是适应现实社会的一种软件工程方法，我想我们也不能把精力局限于文档，局限于个人，我们也应从敏捷软件开发中学到我们作为社会的一份子怎样更好地融入现实社会。

 

[1] https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91 维基百科

[2] http://www.cnblogs.com/xinz/archive/2011/04/27/2031118.html 博客园 博文

[3]专题讨论作业提示