管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革
Posted buaa_jt
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革相关的知识，希望对你有一定的参考价值。
管理从砖瓦进化为人
——浅谈传统软件工程到敏捷软件开发之变革
前言
如果把软件开发过程比作修筑一座建筑的话，传统的软件工程方法对人的管理就像是把人化作一砖一瓦，秩序地堆砌，一层一层构建起摩天大厦。
显然地，人是不同于砖瓦那样的死物的。人作为一种复杂的动物，软件开发者会有喜怒哀乐，枯燥重复的工作内容会使他们提不起兴趣而缺乏激情；客户想法会随变动的现实而一天天有所转变，软件需求很难保持一成不变；开发者与测试者对于项目的认识会存在差异，而差异将导致效率的降低……因而传统的有些“反人类天性”的软件开发方式也就自然而然会产生诸多矛盾与问题，在整个开发过程中不断带来负面影响与作用。
敏捷软件开发价值观的提出，像是无机物原子突然间化作有机物，有机物构建成为生命，让软件开发开始摆脱“比照着蓝图堆砌砖瓦”的模式，一步步把软件开发管理的根本回归到人本身，让人从砖瓦重新进化为了人。
笔者试着运用较为生动的类比，从开发者、客户、软件本身等多个视角，阐述传统软件开发到敏捷软件开发的变革带来的进步与益处。
欲言其弊，则必先言其质。首先笔者将对传统软件开发进行一个较为全面客观的描述，其中的很多软件开发的标准与思想实际上是准确且贴合实际的，因而并不能片面地认为传统软件开发便是落后陈旧的，相反，其中提出的众多标准与思想是经久不衰的，今后还将继续指导我们软件工程方法的探索与发展，值得我们学习和参考。
传统软件开发
软件开发方法诞生至今产生了许多模型与方法，一般来讲，传统软件开发方法是指瀑布模型、螺旋模型、喷泉模型、RUP(Rational Unified Process)这4个重型软件开发方法。其共同的特点是注重文档的完整性，程序的易读性，结构的完整性，它们在公司的大型软件开发中广泛地得到运用。
软件开发标准
软件开发是一个把用户需要转化为软件需求，把软件需求转化为软件设计，用软件代码来实现软件设计，对软件代码进行测试，并签署确认它可以投入运行使用的过程。在这个过程中的每一个阶段，都包含有响应的文档编制工作。
判断一个软件的好坏，是没有什么绝对标准的，但一些定性的准则，可以判断什么样的软件更好一些。
（1） 正确性
正确性是指软件符合规定的需求的程度。正确的软件具备且仅具备软件“规格说明”中所列举的全部功能，能够在预期的环境下完成规定的工作。
（2） 可靠性
可靠性指的是在规定的条件和时间内软件不引起系统失效的概率。它主要取决于正确性和健壮性两个方面。正确性如前所述；健壮性则是指系统万一遇到意外时能按照某种预定的方式做出适当的处理，从而避免出现灾难性的后果。
（3） 简明性
简明性是要求软件简明易读。好的软件设计风格有助于软件达到简明性要求。软件应当结构清晰，编排得体，容易看懂，最重要的是不要人为地增加复杂性。
（4） 有效性
有效性是指软件的时间效率和空间效率要高。
（5） 可维护性
可维护性指的是软件能够修改和升级的容易程度。它目前已经成为越来越重要的软件开发标准。好的可维护性要求软件有好的可读性、可修改性和可测试性。
（6） 适应性
适应性是指软件使不同的系统约束条件和用户需求得到满足的容易程度。它要求软件尽可能适应各种软、硬件运行环境，以便软件的推广和移植。
传统软件开发的阶段
从工程学角度出发，软件开发过程包括计划、分析、设计、编码、测试和维护等几个阶段，如图所示。
这也就是我们一般意义上讲的瀑布模型。
瀑布模型
瀑布模型(Waterfall Model)是由Royce在1970年提出的。该模型最早强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为‘系统发展生命周期’（System Development Life Cycle, SDLC）。
由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质。它像工厂流水线一样，把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成为更细的工序。每个工序中的人员仅仅需要面对自己所负责的内容，而不必考虑除此以外其他工序的实施方式。该模型以其非常符合软件工程学分层设计思路的特点，成为了软件开发企业使用最多的开发模型。
瀑布模型的特点
1、强调文档，前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。
2、没有迭代与反馈。瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。
3、可以把文档理解为开发的速度，管理人员能方便地界定不同阶段的里程碑。
瀑布模型的缺点
Royce提倡重复地使用瀑布模型，以一种迭代的方式。但是，大多数人并不知道这一点，一些人也不相信它能被应用在现实生活中，因为过程很少能够以连续由上而下的方式进行。经常会需要回到前面的阶段，或改变前一阶段的结果。讽刺的是，在Royce 1970年的那篇文章中他提到：这种模型的目的是作为用来说明这种模式有缺陷，而不适用。事实上，软件开发相关文章中对这个名词的大量引用正是对这个广泛流行的软件开发做法的一种评判。
瀑布模型的缺点有五：
1、这种模型依赖于早期进行的唯一一次需求调查，当客户难以表达真正的需求或发生需要求变更时，这种模型无法解决具有二义性问题存在的问题， 并难以适应用户需求的变化。
2、瀑布模型风险的暴露时间滞后，往往要延迟至后期的开发阶段才显露出来，因而失去及早纠正的机会。
3、有可能出现“堵塞状态”。采用这种线性模型，在过程的开始和结束时会经常碰到等待其他成员完成其所依赖的任务才能进行下去的情况，从而有可能花在等待的时间比开发的时间要长。
4、由于是单一流程，在项目各阶段之间极少有反馈，开发中的经验教训不能反馈应用于本产品的过程。
5、由于通过过多的强制完成日期和里程碑来跟踪各个项目阶段，使开发者将大量时间和精力放在定制的文档中，增大了工作量。
瀑布模型的用户很多，但反对的意见一直接连不断，笔者认为，其基于软件文档的开发形式是最本质的问题所在。把开发者变成砖瓦，去堆砌事先规划好的设计图纸，然而事实上，砖瓦会因为工作的枯燥而缺乏激情，原先的图纸会随着时间推移暴露出设计缺陷，最终客户手到的建筑或许已不是客户当前真正想要的样子，同时漫长的开发周期也让需求急迫而需求软件规模较小的客户苦恼不已。
在这样的背景之下，以极限编程(extreme Programming,xp)为首的敏捷软件开发方法逐渐在软件开发业界掀起变革的风潮。
敏捷软件开发(Agile Software Development)
几乎所有富有个性的程序员都有这样一个观点，软件开发应具有艺术性，这也是笔者所认同的一种思想：“编程本身是一种个体的，富有灵感的、逻辑性强的活动，但是现代的软件开发更是一种群体活动。”
敏捷软件开发是一种从1990年代开始铸剑引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调开发团队与业务专家之间的紧密协作、面对面的沟通（而不是书面的文档）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，换句话说，也就是更注重软件开发过程中人的作用。
接下来先对敏捷开发进行一个简单的介绍：
敏捷联盟
敏捷(Agile)一词最早来源于2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者的聚会。他们聚集在一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观(value)和原则。他们称自己为敏捷联盟(Agile Alliance)。在随后的几个月中，他们创建出了一份价值观声明，也就是敏捷联盟宣言(The Manifesto of the Agile Alliance)。
在笔者看来，这份宣言高度凝炼地概括了当下软件开发的思想和要素，将以人为本的思想具象化到了软件开发方法中，极富吸引力又与实际紧紧贴合。如果把软件开发的变革比作人类进化，那么这一宣言的诞生，就仿佛蒙昧的人类第一次拥有了语言和文字。
敏捷联盟宣言
在敏捷联盟的网站首页写着如下内容：
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
l 个体和互动 高于 流程和工具
l 工作的软件 高于 详尽的文档
l 客户合作 高于 合同谈判
l 响应变化 高于 遵循计划
就是说，尽管右项有其价值，
我们更重视左项的价值。
第一条价值陈述认识到，流程和工具的本质是服务于个体和互动的，这与业界传统的以文档编写为核心的方法恰恰相反，强调了个人是独一无二的，因而互动联系必须更加紧密、直接，即面对面的交流。
同样，相较于一份严谨、宏观、详尽的文档，开发团队与客户真正关心的主体，一定是在于最终产品——一个能实际工作的软件上。换句话讲，将软件开发过程中文档交付的决定权返还给项目组，由他们自己决定哪些文档是非有不可的。与其管理者循规蹈矩地苛求开发人员按部就班，不如由开发团队来选择更有效率的内部运作方式。与此同时，在当下的软件开发环境里，瞬息万变的形势与需求并不能允许开发团队在文档计划阶段过度停滞，一个快速产出的能解决眼前核心需求的工作软件远胜过历时久远、深谋远虑的鸿篇巨制。快速的版本迭代、适应形势的动态维护，无疑更能适应这个时代。
软件开发的过程实际上类似于人与人交流的过程，只有持续不断的沟通，才能准确无误地领会对方所要传答的意思。比起通过死板的外部合同规定，客户和供应商的团队协作可能是最好的解决方案。合同只提供边界条件，保证参与者的工作，但只有不断协调合作，开发团队才有希望交付客户需要的产品。
俗话说“计划赶不上变化快”。忠实地执行计划在软件开发中并不是一件那么好的事，不论是多么详细的计划，如果它会阻碍人的随机应变，那么它就会变得很危险。因此开发团队必须足够敏捷，不断适应外部的变化，才能取得成功。
敏捷宣言遵循的原则
- 对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
- 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
- 可以工作的软件是进度的主要度量标准。
- 敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性。
- 简单——尽可能减少工作量的艺术至关重要。
- 最好的架构、需求和设计都源自自我组织的团队。
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。
敏捷方法
敏捷方法是一个开发软件的管理新模式，用来替代以文档驱动开发的瀑布开发模式。敏捷方法也称轻量级开发方法。根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。
敏捷开发避免了传统瀑布方式的弊端，主要是吸收了各种新型开发模式的“动态”特性，关注点从文档到开发者，管理方式上实现了开发者从砖瓦进化为人的过程。
敏捷方法的特点
1、以人为本，注重编程中人的自我特长发挥。
2、强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。
3、客户与开发者的关系是协作，不是合约。开发者不是客户业务的“专家”，要适应客户的需求，是要客户合作来阐述实际的需求细节，而不是为了开发软件，把开发人员变成客户业务的专家，这是传统开发模式或行业软件开发企业的最大面临问题。
4、设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应客户需求的不断变化，设计也要不断跟进，所以设计不能是“闭门造车”、“自我良好”，能不断根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。
敏捷方法的核心思想
- 迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”，对迭代的强调是缩短了软件版本的周期
- 客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求
- 小版本。快速功能的展现，看似简单，但对于复杂的客户需求，合理地分割与总体上的统一，要很好地二者兼顾是不容易的。
总结
敏捷开发是一种全新而快捷的软件开发方法，在很大程度上是关于程序员可以生成简单、灵活性高的软件技术。测试、连续集成以及重构，这些关键实践结合在一起可以使设计风格比计划更具可进化性。在当下需求多变的环境里，这样的风格无疑是最为重要的。
参考文献
[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
以上是关于管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革的主要内容，如果未能解决你的问题，请参考以下文章