序：我在准备一个敏捷初级知识的ppt的时候，忽然觉得我写的东西很眼熟，再一想，这不就是我论文么。忽然想起这论文写了有3年了都忘记发在博客上。 干脆拆散了发出来好了。
本论文题为《软件组织敏捷转型过程的研究与改进》，有删节。
（一）敏捷软件开发方法的历史和现状
敏捷方法作为软件工程的一种，其起源和发展都和软件行业和软件技术本身的发展息息相关。软件工程的诞生是为了解决当时软件开发的问题。几十年过去了，许多问题却依然存在。
1.1.1 软件工程的诞生
计算机软件诞生于20世纪50年代。早期的编程工作量大，但逻辑并不复杂，因为计算机的应用还仅限于一些数学计算等领域。一个好的程序员就能设计和编写整个程序。
从60年代中期到70年代中期是计算机系统发展的第二个时期，在这一时期软件开始作为一种产品被广泛使用，第三代计算机出现，过程化程序设计，多用户系统，人机交互，数据库，使得软件从分钟级变成了毫秒。从那时起，计算机的软件开始陡然复杂起来。当程序变得越来越大时，就需要越来越多的程序员一起来开发程序。这种更大一些的程序的交付变得非常的难以预料。
这时期软件开发的方法基本上仍然沿用早期的个体化软件开发方式，但软件的数量急剧膨胀，软件需求日趋复杂，维护的难度越来越大，开发成本急剧增高，而失败的软件开发项目却屡见不鲜。
OS 360操作系统被认为是一个典型的案例[[i]]。到现在为止，它仍然被使用在IBM360系列主机中。这个经历了数十年，极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。OS 360是第一个超大型的软件项目，它使用了1000人左右的程序员。 Fred Brooks在随后他的著作《人月神话》（The Mythical Man-Month）中曾经承认，在他管理这个项目的时候，他犯了一个价值数百万美元的错误。很多的软件项目开发时间大大超出了规划的时间表，一些项目导致了财产的流失，甚至某些软件导致了人员伤亡[[ii]]。同时软件开发人员也发现软件开发的难度越来越大。
这种情况使得人们开始对软件及其特性进行更深一步的研究。1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”(Software Crisis)这个名词。软件危机包含如下的含义：
· 项目超出预算
· 项目延期交付
· 软件效率低
· 软件质量差
· 软件常常无法满足业务需求
· 项目难以维护，代码难以修改
· 软件无法交付
人们意识到，或许一种更加正式化的流程能够改变软件开发的现状。于是北大西洋公约组织的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（Software Engineering）这个概念。
软件工程是一门研究如何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和维护的学科。软件工程包括两方面内容：软件开发技术和软件项目管理。软件开发技术包括软件开发方法学、软件工具和软件工程环境。软件项目管理包括软件度量、项目估算、进度控制、人员组织、配置管理、项目计划等。
“软件工程”这个词的提出，使得用工程化方法研究软件开发的思路在软件研究中广泛传播，因而产生了一系列的软件过程方法。
1.1.2 软件过程方法的演变
软件工程发展的一个方面，是依靠对于过程的精确掌控和管理，来达到提高软件开发效率和交付质量的要求。
“像架桥一样架设软件”。具有机械和土木工程背景的开发执行人提出了解决方案。他们建议使用工程学的原则来构建软件，并因此催生了软件工程的“瀑布式”方法。
图表 1‑1瀑布模型示意图
瀑布式开发方法，也称线性顺序模型，源自Winston W. Royce在1970年最初提出的软体开发模型，是严格按照软件开发的步骤进行实施的软件开发方法。瀑布式方法将开发过程分为需求分析和定义、系统设计、开发和单元测试、系统集成测试、运行维护等多个阶段，整个过程都以线性方式进行。
然而，瀑布式开发流程依赖于一个重要的假设，就是所有的需求在开发之前就已经被明确定义。也就是说，从一开始的程序确认之后，就一次完成每一步骤的开发作业，一切都是不可修改的。然而这种假设在商业环境中几乎是不存在的。这导致了许多采用瀑布方法开发出来的软件完全无法适应用户的需求，项目的失败率高居不下。
原型法相对于瀑布式方法具备了对变化需求的响应功能。原型法是在20世纪80年代中期为了快速开发系统而推出的一种开发模式，旨在改进瀑布方法的不足。
这种方法首先建立一个能反映用户需求的原型系统，让用户在计算机上运行，试用这个原型系统，通过实践，了解未来系统的全貌。用户通过实际使用原型系统，提出修改意见。根据这些意见快速修改原型系统，经过对原型系统的反复改进，最终建立完全符合用户需要的系统。原型模型可以在运行中被检查、测试、修改，直到它的性能达到用户需求为止，因而这个工作模型很快就能转换成目标系统。原型法的意义是可视化，强化沟通，降低风险，节省后期变更成本，提高项目成功率。
然而，原型方法的问题在于当时软件开发技术的不成熟。许多团队为了建立原型，采用了一些快速易于实现的技术，等用户确认完毕要进行真正的系统建设的时候，团队将面临一个两难的选择：继续在该原型上开发，使用不成熟的技术，还是采用成熟技术重新开发一个新的系统？两者的风险都极高，况且重新开发时很多团队又采用了瀑布式过程。
增量模型和螺旋模型方法融合了线性顺序模型的基本成分和原型的迭代特征，由Barry Boehm在1988年提出[[iii]]。在理想增量螺旋模型中，开发周期一直很短。开发团队有机会停下来，调整项目代码，然后继续开发下去。螺旋模型被认为是后期所有基于迭代模型的鼻祖。
图 1‑2 螺旋模型示意图
不幸的是，由于当时的软件技术正处于面向对象技术的初期阶段，开发团队该技术的掌握不熟练导致采用螺旋模型时交付问题并没有消失。模型的第一周期的会进行得不错。当下一部分需求被考虑的时候，开发小组发现自己已经身陷困境。第二阶段新的需求并不适合第一阶段对系统的设计，尤其是尚未成熟的面向对象设计。虽然很不情愿，大多数螺旋模型的倡导者和支持者还是被迫回到了瀑布式过程。
几乎与此同时，在20世纪80年代中后期，美国卡内基梅隆大学(Carnegie-Mellon University)的软件工程学院(Software Engineering Institute)通过对几个采用瀑布式方法的美国空军项目的研究，对软件开发过程模型本身进行提出了软件成熟度模型(CMM)，其结果发布在1989出版的《管理软件过程》[[iv]]一书。
值得注意的是，CMM并不是一种实际的软件工程方法，而是一个描述软件工程方法的元模型，其目的是为了进行过程的改进。
1.1.3 需求分析和设计方法以及重量级方法的产生
软件工程发展的另一个方面，是侧重于对软件开发过程中分析、设计的方法的研究。这方面的重要成果就是在70年代出现的面向过程的开发方法，以及结构化的分析、设计和相应的测试方法。这些方法被用于瀑布模型中，取得了一定的效果。
这方面的成果，使人们认识到了文档的标准以及开发者之间、开发者与用户之间的交流方式的重要性。一些重要文档格式的标准被确定下来，包括变量、符号的命名规则以及原代码的规范式。
20世纪80年代末期开始，面向对象的分析、设计方法（OOA和OOD）的出现使传统的开发方法发生了翻天覆地的变化。随之而来的是面向对象建模语言（以UML为代表）、软件复用、基于组件的软件开发等新的方法和领域。
软件项目居高不下的失败率孕育出了新的产业。他们致力于对瀑布流程提供严格的控制，CASE（计算机辅助软件工程，Computer-Aided Software Engineering)工具应运而生。这些工具基于以下前提：更加严格的获得流程中每一个阶段的信息；通过审查这些时期产生的文档来保证准确度；只有当缺陷被解决时才继续进行开发。CASE工具很昂贵，很多开价高达每个程序员数千美元。其中流传最广的是产生于20世纪90年代中期的Rational工具及其所支持的RUP方法。
Rational统一过程（RUP）参考了瀑布模型、螺旋模型的特点，是由IBM Rational公司开发并投向市场的一种过程产品，该工具为项目的执行提供了必需的细节：包括指南、模板以及辅助工具。
图 1‑3 RUP中的软件生命周期[[v]]
RUP将整个开发生命周期分为4个阶段：初始阶段、精化阶段、构建阶段、产品化阶段。RUP的每个阶段又可分为一到多个迭代周期。采用迭代式开发，目的是尽早降低风险[[vi]]。
然而，许多使用RUP方法的人发现，很多“软件危机”中所提到的问题并没有被减轻。RUP中规定了许多需要开发团队制作的“工件”,这些工件常常以文档出现，例如需求规格说明书等等。有的开发团队为了节省时间而忽略了这些“工件”，这成了被人诟病之处，认为团队忽视了工件才导致了软件交付失败。
在20世纪90年代，另一些人提出了对软件过程进行标准化的方法。1995年发布的ISO/IEC 12207[[vii]]标准，对软件开发生命周期做了详细的规定，包括投标、签署合同到开发过程中的文档以及后期的维护支持。然而该标准是按照瀑布模型定制的标准，并且在定制的过程中忽视了软件需求的多样性。
由于开发过程标准的出现，许多美国的政府机构开始认为，只有符合标准的软件公司才是最佳的选择，因此导致了本来被定义为迭代过程的RUP过程被迫简化为标准中的线性过程[[viii]]，而关注于过程改进的CMM被认为是要检查开发过程中的工件即文档[[ix]]。在90年代后期，上述的RUP方法，CMM模型和ISO标准开始常常被人一起提及。这三种不同的东西被绑定在一起的后果，就是被称为“重量级方法”(Heavyweight Method)。
它们过多的关注了过程本身，它们认为保证过程正确执行的方式是通过文档记录，这使得文档工作占用了相当大的时间。而为了弥补时间的损失，软件公司只好依靠增加专门的文档编写人员来提高生产效率，用成本换效率的结果，就是软件开发依然无法跳出超预算、超期的怪圈。
1.1.4 轻量级方法－－敏捷方法的前身
20世纪90年代，除了软件技术中面向对象开发方法的兴起之外，软件领域另一项令人激动的技术是互联网技术的兴起。尤其是90年代末期，随着互联网的发展，越来越多的传统企业开始意识到，他们获得了另一个商机。这时候，软件快速的交付投入使用成为决定一个企业生死存亡的必要条件。而重型软件开发过程的繁重与拖沓，使得许多开发团队决定放弃标准，尝试新的软件开发过程和方法。这些注重快速交付，减少文档的方法被人称为轻量级方法。
轻量级方法一般意义上包括： XP（极限编程），SCRUM，Crystal Clear(水晶方法族)，Context Driven Testing，Lean Software Development（精益软件开发），DSDM以及Adaptive Software Development等。这些方法分别由不同的人基于软件开发不同的角度提出。以下将对其中几个影响比较大的方法做简单介绍。
1.1.4.1 eXtreme Programming(极限编程）
XP根源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在20世纪80年代末的密切合作。90年代初，他们在一系列项目上的实践深化扩展了他们关于软件开发应是适应性的、应以人为中心思想。
Kent Beck在其后的项目咨询实践中继续发展了他的思想，特别是在1996年春Chrysler C3 项目。该项目后来成了广为人知的XP的创生项目。他在 1997年左右开始使用“extreme programming”这个名称。Kent Beck和一些初始的实践者在世纪之交出版了多本书，对XP方法的种种方面加以了详细阐述。
XP始于五条基本价值观（values）：交流，反馈，简洁，勇气和尊重（Communication, Feedback, Simplicity, Courage, and Respect）。在此基础上细化出了十四条原则（principles）和二十四条实践方法（practices）。其基本思想是：实践是项目组的日常的具体活动，而价值观是根本性的知识和理念，其构成了该方法基石。没有实践法的价值观是难于应用的，或失之于过于宽泛而不知从何着手。没有价值观的实践法则是一堆杂乱无章的活动。价值观和实践法都是需要的，但中间还有一个空档－－而原则正是用来连接价值观和实践的。许多XP的实践法都是以前就存在的并经过实践检验的，而常常被许多过程，包括那些计划型过程，给忽略了。XP重新建立了这些准则，并把它们编织成了一个和谐的整体，使得每一项准则都能在其他准则里得以强化[[x]]。
XP最具独创性的是它对测试的极端重视。虽然所有的过程都提到测试，但一般都不强调。XP将测试作为开发的基础，要求每个程序员写一段源码时都得写相应的测试码。这些测试片段不断地积累并被整合到系统中。这样的过程会产生一个高度可靠的建造平台，为进一步开发提供了良好的基础。这种方法常被描述成Test Driven Development(TDD)（测试驱动开发），它对许多不是完全采用XP的方法都有很大的影响。
XP及其注重软件开发实践的风格使得XP在后来的敏捷方法家族处于基石的地位。其他的轻量级方法对于开发实践的重视均不如XP。
1.1.4.2 SCRUM方法
SCRUM是在20世纪80和90年代从面向对象圈子里发展出来的一种高度迭代性的方法。 SCRUM的主要开发者有Ken Schwaber, Jeff Sutherland和Mike Beedle。
SCRUM的着重点是在软件开发的管理方面。它把一个项目分成若干个为期三十天的迭代阶段，每一阶段称之为一个Sprint。每天有一个短会，称之为一个Scrum。这样管理者能对项目有近距离的观察与控制。SCRUM对工程实践方面强调比较少。
1.1.4.3 水晶（Crystal）方法族
Alistair Cockburn提出了一系列的水晶（Crystal）开发方法，它们可以在不同的项目中加以裁剪。Alistair相信不同类型的项目需要不同的方法，这与两个因素有关：项目参与人数和出错的严重性。
所有水晶方法都有三个需考虑的优先因素（priorities）：项目的结果（safety），效率（efficiency），和习惯性（habitability）（即开发人员多大程度上愿意使用水晶方法）。其他的特征有：频繁发布，反思改进，紧密交流等。
习惯性（habitability）这个优先因素是水晶方法心理基础中的一个重要组成部分。Alistair希望使用最少的纪律性而依然能使项目成功，其基本假设是人的无纪律性是不可避免的。因此，Alistair 把水晶方法视为较XP的纪律性要低的方法，是用较低的效率以期获得更大的习惯性而减少项目失败的可能。
1.1.5 敏捷方法的提出和发展
20世纪最后的几年，许多不同的社群都在发展着持相似的软件开发理念[1]。大部分的工作都是出自那些在面向对象软件开发圈内拥护迭代开发的人士。那时这些方法还没有一个共同的名称，以“轻量级”（lightweight）来称呼这些方法的人越来越多。
2001年，一些轻量级方法的代表人物们在一次聚会中达成共识，他们发表了一份敏捷软件开发宣言（Manifesto for Agile Software Development）。 “敏捷”（agile）一词被提出，作为所有轻量级方法的统称。
敏捷软件开发宣言中这样写到：“我们通过亲身实践和帮助其他人实践，揭示更好的软件开发方法，通过这项工作，我们认为：人和交流胜过过程和工具；可工作的软件胜过面面俱到的文档；客户协作胜过合同谈判；响应变化胜过遵循计划。虽然右项也有价值，但是我们认为左项更重要。”[[xi]]
敏捷方法提出之后，随即得到了广泛的宣传。一批以敏捷开发为名的著作得以出版，许多软件方法研究机构也开始转而研究敏捷方法。从2001年开始，不停的有新的基于敏捷的开发方法和实践被提出。敏捷开发的概念被扩展到了建模[[xii]]、测试[[xiii]]、数据库方法[[xiv]]、需求分析[[xv]]、项目管理[[xvi]]等软件开发的各个方面。
Mary Poppendieck和Tom Poppendieck将敏捷方法和他们曾经经历过的精益生产做了对比[[xvii]]，发现二者之间的共通之处。因此也为敏捷方法找到了管理模型。
采用敏捷方法的团队在客户满意度、软件交付期、代码质量、软件成本、团队个人能力等方面都得到了很大的改善[3]。成功的案例越来越多。敏捷方法的成功开始吸引越来越多的公司和组织来向敏捷转型。大型的软件公司如微软，IBM，Google也曾在公开场合发表过对于敏捷实践的经验。
2006年之后，由于大量公司开始从SCRUM方法进行尝试敏捷，SCRUM隐然成为敏捷方法的领头羊。近期的技术社区讨论最多的话题是，一些许多公司忽视了敏捷的技术实践（XP等），仅采用SCRUM的管理实践，使得开发得不到有效的保障，导致了项目的失败或延期，最终将原因归罪于敏捷。
另外有的公司按照各种书籍和文档上关于敏捷的描述来进行实践，由于没有足够的经验，其效果并不理想。更有部分产品公司，为了销售自己的产品，硬是把产品贴上了敏捷的标签，以此来获取开发团队的注意。这些都是在敏捷实施和向敏捷组织转型中常常出现的情况。
近两年来，一些大型的软件公司开始进行敏捷的尝试。IBM、微软、华为等开发团队超过万人的大型公司都或多或少的考虑实施敏捷转型。然而，大型公司本身庞大的组织结构导致了敏捷方法在推广的过程中障碍重重。起源于小团队的敏捷方法实践者尚未积累出足够的经验来进行大型公司的转型。关于敏捷转型和敏捷实施的话题这两年开始在敏捷大会（Agile Conference）上特别得到重视。
国外对于敏捷转型的研究始于2003年左右，如前文所述，Mike Cohn首先研究了将敏捷应用于组织的方法。Michael Hirsch研究了从计划驱动的企业文化转向敏捷文化的经验。Iva Krasteva, Sylvia Ilieva研究了敏捷实施过程中效果不佳的一些原因；Elke Hochmüller和Roland T. Mittermei对敏捷实施中的一些误解做了研究。
1.1.6 敏捷方法在中国
在中国，由于政府强制规定只有通过CMM3级认证的软件企业才有资质能够承接政府项目，导致了向印度IT业学习、通过CMM认证的潮流在世纪之交兴起。中国的软件行业发展时间过短，他们只看到了国外的推荐标准和印度的成功，而没能经过类似“软件危机”的痛苦和洗礼，在实行了几年CMM改进或ISO标准之后，国内的IT企业终于认识到了沉重过程所带来的高昂成本和代价。
2002年开始，一些极限编程的书籍被翻译成中文版，然而却并没有引起软件公司的注意。2003年初，一些技术杂志发表了对敏捷方法的介绍开始引起人们的注意，大量的敏捷著作随后被一一翻译。2004到2005年，受Kent Beck, Martin Fowler等人的影响，Java技术社区最早开始讨论敏捷，中国第一批实践敏捷的团队在无人带领中开始自己的摸索。
2006年开始，敏捷中国大会以一年一次的频率召开，成为中国敏捷方法的旗帜。到了2008年，以华为、腾讯、阿里巴巴为代表的中国本土软件企业开始了敏捷的尝试，标志着敏捷方法在中国已经开始步入主流行列。然而敏捷转型过程本身的复杂性和艰巨性，使得各大公司都仅仅止步于小团队的试点，真正敢于进行全面敏捷的组织屈指可数。
1.1.7 精益思想与持续交付
2009-2012年，这几年间精益思想被不断的深化，将持续改善自动化的思想做到极致，就是持续交付。持续交付是许多企业进行敏捷实践所追求的机制。 这段是2012年在写了论文3年之后应该补充的部分。 但是目前先不写啦。以后再单独写。
[[i]] Brooks, Frederick. The Mythical Man-Month [M], Addison-Wesley, 1995.
[[ii]] Leveson, Nancy, University of Washington. Turner, Clark S., University of California, Irvine. “An Investigation of the Therac-25 Accidents” [J], IEEE Computer, July 1993, vol.26,no.7, pp. 18-41.
[[iii]] Boehm, Barry, “A Spiral Model for Software Development and Enhancemant” [J], Computer, May 1988, vol.21, no.5, pp. 61-72
[[iv]] Humphrey, WS, “Managing the Software Process” [M], Addison-Wesley, 1989
[[v]] Sinan Si Alhir, sunyanjia译，领会统一过程，[EB/OL]，http://www.uml.org.cn/softwareprocess/200510311.htm ，2006, 2009-04-20
[[vi]] P Kruchten, The rational unified process: an introduction [M], Addison-Wesley, 2000
[[vii]] ISO 12207, Information technology-Software life cycle processes [S], 1995/ISO, IEC
[[viii]] Kruchten, Philippe, “How the Rational Unified Process Supports ISO 12207” [EB/OL],http://www.yoopeedoo.org/upedu/references/papers/iso12207.htm ，Rational Canada, 2002, 2009-04-20
[[ix]] Machado, C.F.; De Oliveira, L.C.; Fernandes, R.A., “Experience report-restructure of processes based on ISO/IEC 12207and SW-CMM in CELEPAR”， [J], Software Engineering Standards, 1999. Proceedings. Fourth IEEE International Symposium and Forum, 1999, pp.82 – 87.
[[x]] Beck, Kent. “Extreme programming explained: embrace change” [M], Addison-Wesley,2004
[[xi]] Agile Alliance. “Manifesto for Agile Software Development”. [EB/OL],
http://www.agilealliance.org , October 2001, 2009-04-20
[[xii]] Ambler, Scott. “Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process” [M], Wiley, 2002
[[xiii]] Crispin, Lisa & Gregory, Janet, “Agile Testing: A Practical Guide for Testers and Agile Teams” [M], Addison-Wesley, 2009
[[xiv]] Ambler, Scott W. and Sadalage, Pramodkumar J.”Refactoring Databases: Evolutionary Database Design” [M], Addison-Wesley, 2006
[[xv]] Cohn, Mike. “User Stories Applied: For Agile Software Development” [M], Addison-Wesley, 2004
[[xvi]] Highsmith, Jim. “Agile Project Management: Creating Innovative Products” [M], Addison-Wesley, 2004
[[xvii]] Poppendieck, Mary & Poppendieck, Tom. “Lean Software Development: An Agile Toolkit” [M], Addison-Wesley, 2003
0 条评论