管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革

管理从砖瓦进化为人

——浅谈传统软件工程到敏捷软件开发之变革

前言

 

若是把软件开发过程比做修筑一座建筑的话，传统的软件工程方法对人的管理就像是把人化做一砖一瓦，秩序地堆砌，一层一层构建起摩天大厦。

显然地，人是不一样于砖瓦那样的死物的。人做为一种复杂的动物，软件开发者会有喜怒哀乐，枯燥重复的工做内容会使他们提不起兴趣而缺少激情；客户想法会随变更的现实而一每天有所转变，软件需求很难保持一成不变；开发者与测试者对于项目的认识会存在差别，而差别将致使效率的下降……于是传统的有些“反人类天性”的软件开发方式也就天然而然会产生诸多矛盾与问题，在整个开发过程当中不断带来负面影响与做用。

敏捷软件开发价值观的提出，像是无机物原子忽然间化做有机物，有机物构建成为生命，让软件开发开始摆脱“比照着蓝图堆砌砖瓦”的模式，一步步把软件开发管理的根本回归到人自己，让人从砖瓦从新进化为了人。

笔者试着运用较为生动的类比，从开发者、客户、软件自己等多个视角，阐述传统软件开发到敏捷软件开发的变革带来的进步与益处。

欲言其弊，则必先言其质。首先笔者将对传统软件开发进行一个较为全面客观的描述，其中的不少软件开发的标准与思想其实是准确且贴合实际的，于是并不能片面地认为传统软件开发即是落后陈旧的，相反，其中提出的众多标准与思想是经久不衰的，从此还将继续指导咱们软件工程方法的探索与发展，值得咱们学习和参考。

传统软件开发

       软件开发方法诞生至今产生了许多模型与方法，通常来说，传统软件开发方法是指瀑布模型、螺旋模型、喷泉模型、RUP(Rational Unified Process)这4个重型软件开发方法。其共同的特色是注重文档的完整性，程序的易读性，结构的完整性，它们在公司的大型软件开发中普遍地获得运用。

软件开发标准

软件开发是一个把用户须要转化为软件需求，把软件需求转化为软件设计，用软件代码来实现软件设计，对软件代码进行测试，并签署确认它能够投入运行使用的过程。在这个过程当中的每个阶段，都包含有响应的文档编制工做。

判断一个软件的好坏，是没有什么绝对标准的，但一些定性的准则，能够判断什么样的软件更好一些。

（1）    正确性

正确性是指软件符合规定的需求的程度。正确的软件具有且仅具有软件“规格说明”中所列举的所有功能，可以在预期的环境下完成规定的工做。

（2）    可靠性

可靠性指的是在规定的条件和时间内软件不引发系统失效的几率。它主要取决于正确性和健壮性两个方面。正确性如前所述；健壮性则是指系统万一遇到意外时能按照某种预约的方式作出适当的处理，从而避免出现灾难性的后果。

（3）    简明性

简明性是要求软件简明易读。好的软件设计风格有助于软件达到简明性要求。软件应当结构清晰，编排得体，容易看懂，最重要的是不要人为地增长复杂性。

（4）    有效性

有效性是指软件的时间效率和空间效率要高。

（5）    可维护性

可维护性指的是软件可以修改和升级的容易程度。它目前已经成为愈来愈重要的软件开发标准。好的可维护性要求软件有好的可读性、可修改性和可测试性。

（6）    适应性

适应性是指软件使不一样的系统约束条件和用户需求获得知足的容易程度。它要求软件尽量适应各类软、硬件运行环境，以便软件的推广和移植。

传统软件开发的阶段

从工程学角度出发，软件开发过程包括计划、分析、设计、编码、测试和维护等几个阶段，如图所示。

 

这也就是咱们通常意义上讲的瀑布模型。

瀑布模型

       瀑布模型(Waterfall Model)是由Royce在1970年提出的。该模型最先强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，所以瀑布模型又能够称为‘系统发展生命周期’（System Development Life Cycle, SDLC）。

因为该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，所以能有效的确保系统品质。它像工厂流水线同样，把软件开发过程分红各类工序，而且每一个工序能够根据软件产品的规模、参与人员的多少进一步细分红为更细的工序。每一个工序中的人员仅仅须要面对本身所负责的内容，而没必要考虑除此之外其余工序的实施方式。该模型以其很是符合软件工程学分层设计思路的特色，成为了软件开发企业使用最多的开发模型。

瀑布模型的特色

一、强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的惟一信息。因此不少开发人员好象是在开发文档，而不是开发软件，由于要到开发的后期，才能够看到软件的“模样”。

二、没有迭代与反馈。瀑布模型对反馈没有涉及，因此对变化的客户需求很是不容易适应，瀑布就意味着没有回头路。

三、能够把文档理解为开发的速度，管理人员能方便地界定不一样阶段的里程碑。

瀑布模型的缺点

Royce提倡重复地使用瀑布模型，以一种迭代的方式。可是，大多数人并不知道这一点，一些人也不相信它能被应用在现实生活中，由于过程不多可以以连续由上而下的方式进行。常常会须要回到前面的阶段，或改变前一阶段的结果。讽刺的是，在Royce 1970年的那篇文章中他提到：这种模型的目的是做为用来讲明这种模式有缺陷，而不适用。事实上，软件开发相关文章中对这个名词的大量引用正是对这个普遍流行的软件开发作法的一种评判。

瀑布模型的缺点有五：

一、这种模型依赖于早期进行的惟一一次需求调查，当客户难以表达真正的需求或发生须要求变动时，这种模型没法解决具备二义性问题存在的问题， 并难以适应用户需求的变化。

二、瀑布模型风险的暴露时间滞后，每每要延迟至后期的开发阶段才显露出来，于是失去及早纠正的机会。

三、有可能出现“堵塞状态”。采用这种线性模型，在过程的开始和结束时会常常碰到等待其余成员完成其所依赖的任务才能进行下去的状况，从而有可能花在等待的时间比开发的时间要长。

四、因为是单一流程，在项目各阶段之间极少有反馈，开发中的经验教训不能反馈应用于本产品的过程。

五、因为经过过多的强制完成日期和里程碑来跟踪各个项目阶段，使开发者将大量时间和精力放在定制的文档中，增大了工做量。

 

瀑布模型的用户不少，但反对的意见一直接连不断，笔者认为，其基于软件文档的开发形式是最本质的问题所在。把开发者变成砖瓦，去堆砌事先规划好的设计图纸，然而事实上，砖瓦会由于工做的枯燥而缺少激情，原先的图纸会随着时间推移暴露出设计缺陷，最终客户手到的建筑或许已不是客户当前真正想要的样子，同时漫长的开发周期也让需求急迫而需求软件规模较小的客户苦恼不已。

在这样的背景之下，以极限编程(extreme Programming,xp)为首的敏捷软件开发方法逐渐在软件开发业界掀起变革的风潮。

敏捷软件开发(Agile Software Development)

       几乎全部富有个性的程序员都有这样一个观点，软件开发应具备艺术性，这也是笔者所认同的一种思想：“编程自己是一种个体的，富有灵感的、逻辑性强的活动，可是现代的软件开发更是一种群体活动。”

       敏捷软件开发是一种从1990年代开始铸剑引发普遍关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调开发团队与业务专家之间的紧密协做、面对面的沟通（而不是书面的文档）、频繁交付新的软件版本、紧凑而自我组织型的团队、可以很好地适应需求变化的代码编写和团队组织方法，换句话说，也就是更注重软件开发过程当中人的做用。

       接下来先对敏捷开发进行一个简单的介绍：

敏捷联盟

 

       敏捷(Agile)一词最先来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会。他们汇集在一块儿归纳出了一些可让软件开发团队具备快速工做、响应变化能力的价值观(value)和原则。他们称本身为敏捷联盟(Agile Alliance)。在随后的几个月中，他们建立出了一份价值观声明，也就是敏捷联盟宣言(The Manifesto of the Agile Alliance)。

       在笔者看来，这份宣言高度凝炼地归纳了当下软件开发的思想和要素，将以人为本的思想具象化到了软件开发方法中，极富吸引力又与实际牢牢贴合。若是把软件开发的变革比做人类进化，那么这一宣言的诞生，就仿佛蒙昧的人类第一次拥有了语言和文字。

敏捷联盟宣言

在敏捷联盟的网站首页写着以下内容：

 

咱们一直在实践中探寻更好的软件开发方法，

身体力行的同时也帮助他人。由此咱们创建了以下价值观：

l  个体和互动 高于 流程和工具

l  工做的软件 高于 详尽的文档

l  客户合做 高于 合同谈判

l  响应变化 高于 遵循计划

就是说，尽管右项有其价值，

咱们更重视左项的价值。

 

第一条价值陈述认识到，流程和工具的本质是服务于个体和互动的，这与业界传统的以文档编写为核心的方法偏偏相反，强调了我的是独一无二的，于是互动联系必须更加紧密、直接，即面对面的交流。

一样，相较于一份严谨、宏观、详尽的文档，开发团队与客户真正关心的主体，必定是在于最终产品——一个能实际工做的软件上。换句话讲，将软件开发过程当中文档交付的决定权返还给项目组，由他们本身决定哪些文档是非有不可的。与其管理者循规蹈矩地苛求开发人员循序渐进，不如由开发团队来选择更有效率的内部运做方式。与此同时，在当下的软件开发环境里，瞬息万变的形势与需求并不能容许开发团队在文档计划阶段过分停滞，一个快速产出的能解决眼前核心需求的工做软件远赛过历时久远、深谋远虑的鸿篇巨制。快速的版本迭代、适应形势的动态维护，无疑更能适应这个时代。

软件开发的过程实际上相似于人与人交流的过程，只有持续不断的沟通，才能准确无误地领会对方所要传答的意思。比起经过死板的外部合同规定，客户和供应商的团队协做多是最好的解决方案。合同只提供边界条件，保证参与者的工做，但只有不断协调合做，开发团队才有但愿交付客户须要的产品。

俗话说“计划赶不上变化快”。忠实地执行计划在软件开发中并非一件那么好的事，不管是多么详细的计划，若是它会阻碍人的随机应变，那么它就会变得很危险。所以开发团队必须足够敏捷，不断适应外部的变化，才能取得成功。

敏捷宣言遵循的原则

• 对咱们而言，最重要的是经过尽早和不断交付有价值的软件知足客户须要。
• 咱们欢迎需求的变化，即便在开发后期。敏捷过程可以驾驭变化，保持客户的竞争优点。
• 常常交付能够工做的软件，从几星期到几个月，时间尺度越短越好。
• 业务人员和开发者应该在整个项目过程当中始终朝夕在一块儿工做。
• 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，知足他们的须要，并相信他们可以完成任务。
• 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
• 能够工做的软件是进度的主要度量标准。
• 敏捷过程提倡可持续开发。出资人、开发人员和用户应该老是维持不变的节奏。
• 对卓越技术与良好设计的不断追求将有助于提升敏捷性。
• 简单——尽量减小工做量的艺术相当重要。
• 最好的架构、需求和设计都源自自我组织的团队。
• 每隔必定时间，团队都要总结如何更有效率，而后相应地调整本身的行为。

敏捷方法

       敏捷方法是一个开发软件的管理新模式，用来替代以文档驱动开发的瀑布开发模式。敏捷方法也称轻量级开发方法。根据环境的变化，修改本身的设计，指导开发的方向是敏捷开发的目标。

敏捷开发避免了传统瀑布方式的弊端，主要是吸取了各类新型开发模式的“动态”特性，关注点从文档到开发者，管理方式上实现了开发者从砖瓦进化为人的过程。

敏捷方法的特色

一、以人为本，注重编程中人的自我特长发挥。

二、强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

三、客户与开发者的关系是协做，不是合约。开发者不是客户业务的“专家”，要适应客户的需求，是要客户合做来阐述实际的需求细节，而不是为了开发软件，把开发人员变成客户业务的专家，这是传统开发模式或行业软件开发企业的最大面临问题。

四、设计周密是为了最终软件的质量，但不代表设计比实现更重要，要适应客户需求的不断变化，设计也要不断跟进，因此设计不能是“闭门造车”、“自我良好”，能不断根据环境的变化，修改本身的设计，指导开发的方向是敏捷开发的目标。

敏捷方法的核心思想

• 迭代。软件的功能是客户的需求，界面的操做是客户的“感受”，对迭代的强调是缩短了软件版本的周期
• 客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求
• 小版本。快速功能的展示，看似简单，但对于复杂的客户需求，合理地分割与整体上的统一，要很好地两者兼顾是不容易的。

总结

       敏捷开发是一种全新而快捷的软件开发方法，在很大程度上是关于程序员能够生成简单、灵活性高的软件技术。测试、连续集成以及重构，这些关键实践结合在一块儿可使设计风格比计划更具可进化性。在当下需求多变的环境里，这样的风格无疑是最为重要的。

参考文献

[1]周莹莹. 敏捷软件开发技术研究[D].长春理工大学,2006.

[2]wikipedia:Agile software development

https://en.wikipedia.org/wiki/Agile_software_development

[3]wikipedia:瀑布模型

https://zh.wikipedia.org/wiki/%E7%80%91%E5%B8%83%E6%A8%A1%E5%9E%8B

[4]郭晓娴. 浅析瀑布模型[J]. 福建电脑,2011,07:137-138.

[5]agilemanifesto:

http://agilemanifesto.org/iso/zhchs/manifesto.html

[6]Jack zhai. 瀑布模型、极限编程到敏捷开发---软件开发管理者思惟的变化

http://zhaisj.blog.51cto.com/219066/46187