[转]从瀑布模型、极限编程到敏捷开发
从瀑布模型、极限编程到敏捷开发—软件开发管理者思维的变化
Jack zhai 软件开发是一种对人类智慧的管理，对人大脑思维的“工厂化”管理。人是有感情的、有情绪的、变化的、相对独立的工作单元，这与冰冷的机器是不可比的，所以在中国的历史上，管理人是最难的工作；“学而优则仕”的观点就是让最聪明的人应该选出来做官，做官就是管理人的。软件开发不仅是代码编程，而是人员的有效组织，如何既发挥人的主观能动性，避免情绪变化对工作的影响，又可以让大家有效的交流，让多个大脑的思路统一，快速完成目标呢？多年来软件企业的管理者一直在不断地探索。另外有一个问题一直是软件开发管理人员的心病：软件是工具，开发的是客户业务的应用，但客户不了解软件，开发者不了解业务，如何有效沟通是软件质量的重大障碍。把开发者变成客户业务的专家是个没有办法的办法，让软件企业付出的代价也是昂贵的。瀑布模型、极限编程、敏捷开发是有代表性的开发模式，在对开发者、客户、最终的产品的关注上的变化，体现了软件开发管理者在管理模式上的变化。
一、瀑布开发瀑布模型(Waterfall Model)是Royce在1970年提出的，他把大型软件开发分为：分析与编程，象工厂流水线一样把软件开发过程分成各种工序，并且每个工序可以根据软件产品的规模、参与人员的多少进一步细分成更细的工序。该模型非常符合软件工程学的分层设计思路，所以成为软件开发企业使用最多的开发模型。 瀑布模型的特点：
1、 强调文档，
前一个阶段的输出就是下一个阶段的输入，文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档，而不是开发软件，因为要到开发的后期，才可以看到软件的“模样”。
2、 没有迭代与反馈。
瀑布模型对反馈没有涉及，所以对变化的客户需求非常不容易适应，瀑布就意味着没有回头路。
3、 管理人员喜欢瀑布模型的原因是把文档理解为开发的速度，可以方便地界定不同阶段的里程碑。
瀑布模型的用户很多，也有一些反对的意见：
第一、瀑布模型不适合客户需求不断变化的软件开发，尤其是客户的业务管理的软件，业务随着市场变化，而软件初期的设计可能已经大大变化，而后期的需求更改成本是开始的10倍基数。在ERP盛行的软件市场里，一方面市场带动需求变化，另一方面初期客户对需求描述不清楚，都为瀑布模型的使用团队带来困难。
第二、瀑布模型是一种软件文档的开发，把开发者变成流水线上的机器，大量重复性的工作让编程人员提不起兴趣，工作很枯燥，没有激情，编程成了一种没有创意的机械劳动，这让一向以高科技为标志的高级程序人员大为恼火。在这种背景下，极限编程(extreme Programming, XP)带来了新鲜的空气。
二、极限编程极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通，一定要用客户理解的语言，先测试再编码就是先给客户软件的外部轮廓，客户使用的功能展现，让客户感觉到未来软件的样子，先测试再编码与瀑布模型显然是背道而驰的。同时，极限编程注重用户反馈与让客户加入开发是一致的，让客户参与就是随时反馈软件是否符合客户的要求。有了反馈，开发子过程变短，迭代也就很自然出现了，快速迭代，小版本发布都让开发过程变成更多的自反馈过程，有些象更加细化的快速模型法。当然极限编程还加入了很多激励开发人员的“措施”，如结队编程、40小时工作等。
极限编程是一种开发管理模式，它强调的重点是：
1、 角色定位：
极限编程把客户非常明确地加入到开发的团队中，并参与日常开发与沟通会议。客户是软件的最终使用者，使用是否合意一定以客户的意见为准。不仅让客户参与设计讨论，而且让客户负责编写拥护故事(User Story)，也就是功能需求，包括软件要实现的功能以及完成功能的业务操作过程。用户在软件开发过程中的责任被提到与开发者同样的重要程度。
2、 敏捷开发：
敏捷开发追求合作与响应变化。迭代就是缩短版本的发布周期，缩短到周、日，完成一个小的功能模块，可以快速测试、并及时展现给客户，以便及时反馈。小版本加快了客户沟通反馈的频率，功能简单，在设计、文挡环节大大简化。极限编程中文挡不再重要的原因就是因为每个版本功能简单，不需要复杂的设计过程。极限编程追求设计简单，实现客户要求即可，无需为扩展考虑太多，因为客户的新需求随时可以添加。
3、 追求价值：
极限编程把软件开发变成自我与管理的挑战，追求沟通、简单、反馈、勇气，体现开发团队的人员价值，激发参与者的情绪，最大限度地调动开发者的积极性，情绪高涨，认真投入，开发的软件质量就大大提高。结对编程就是激发队员才智的一种方式。
极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了测试->编码->重构(设计)的软件开发管理思路。
极限编程的12个实践是极限编程者总结的实践经典，是体现极限编程管理的原则，对极限编程具有指导性的意义，但并非一定要完全遵守12个实践，主要看它给软件过程管理带来的价值。
1、 小版本。
为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。
2、 规划游戏。
就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。
3、 现场客户。
极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。
4、 隐喻。
隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。
5、 简单设计。
极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。
简单设计包括四方面含义：
1、通过测试。 2、避免重复代码。 3、明确表达每步编码的目的，代码可读性强。 4、尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。
6、 重构。
重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。
7、 测试驱动开发。
极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。
8、 持续集成。
集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。
9、 结对编程。
这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。
10、 代码共有。
在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。
11、 编码标准。
编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。
12、 每周40小时工作。
极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也为了单位时间可以完成的工作安排。
三、敏捷开发极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。
2001年，17名编程大师分别代表极限编程、Scrum(“棒球”团队开发模式)、特征驱动开发、动态系统开发方法、自适应软件开发、水晶方法、实用编程等开发流派，发表“敏捷软件开发”宣言。敏捷软件开发是一个开发软件的管理新模式，用来替代以文件驱动开发的瀑布开发模式。敏捷方式也称轻量级开发方法。
敏捷软件开发宣言内容： - 个体和交互胜过过程和工具 - 可以工作的软件胜过面面具到的文档 - 可户合作胜过合同谈判 - 响应变化胜过遵循计划敏捷开发集成了新型开发模式的共同特点，它重点强调： - 1. 以人为本，注重编程中人的自我特长发挥。 - 2. 强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。 - 3. 客户与开发者的关系是协作，不是合约。开发者不是客户业务的“专家”，要适应客户的需求，是要客户合作来阐述实际的需求细节，而不是为了开发软件，把开发人员变成客户业务的专家，这是传统开发模式或行业软件开发企业的最大面临问题。 - 4. 设计周密是为了最终软件的质量，但不表明设计比实现更重要，要适应客户需求的不断变化，设计也要不断跟进，所以设计不能是“闭门造车”、“自我良好”，能不断根据环境的变化，修改自己的设计，指导开发的方向是敏捷开发的目标。敏捷开发避免了传统瀑布方式的弊端，主要是吸收了各种新型开发模式的“动态”特性，关注点从文档到开发者，管理方式也从工厂的流水线到团队的自我放松式的组织。总结敏捷开发与瀑布模式的不同，主要是下面几个“敏捷”的关注点： - 迭代。软件的功能是客户的需求，界面的操作是客户的“感觉”，对迭代的强调是缩短了软件版本的周期 - 客户参与。以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求 - 小版本。快速功能的展现，看似简单，但对于复杂的客户需求，合理地分割与总体上的统一，要很好地二者兼顾是不容易的。
敏捷就是“快”，快才可以适应目前社会的快节奏；要快就要发挥个人的个性思维多一些，个性思维的增多，虽然通过结队编程、代码共有、团队替补等方式减少个人对软件的影响力，但也会造成软件开发继承性的下降，因此敏捷开发是一个新的思路，但不是软件开发的终极选择。对于长时间、人数众多的大型软件应用的开发，文档的管理与衔接作用还是不可替代的。如何把敏捷的开发思路与传统的“流水线工厂式”管理有机地结合，是软件开发组织者面临的新课题。
对企业软件开发能力衡量的理解—CMM学习经验 大型软件的开发需要很好的管理与组织能力，来保证软件开发的质量。从软件工程的角度来说，不存在没有Bug的软件，但尽量减少致命性的Bug是所有软件开发组织者所追求的。那么如何衡量一个组织具备了大型软件的开发能力呢？CMM提供了一种衡量的方法，尤其是CMM的认证已经成为国际上认可的软件能力标签，所以很多大的企业都组织通过该认证，提供自己的知名度，提升自己在客户心目重点形象。
一、组织能力在于团队的“战斗力”CMM模型注重的是软件开发组织对软件开发过程的管理，是从团队的角度，对软件最终质量的保障。软件的质量就是在完成客户需求的同时，尽量少的留下Bug，减少业务服务的中断与故障。既然是团队能力的衡量，就不是个人天才的展现，所以CMM对一个软件组织的意义远不只认证这么简单。
1、 团队开发能力的保障，就象工厂的流水线一样，每个环节都有严格的输入与输出，并且配置有效的测试检验，软件的开发就象流水线上的汽车，走下流水线的就应该是成品。所以制度、操作流程定义、成套的检测手段都是流水线上必备的。
2、 个人的能力强，往往体现在经验而不是文档，而团队的能力就很大程度地体现了文档的管理，因为在一个“加工”过程中，较为头痛的首先就是人员的流动，组织的能力就是在任何职位的人员调动，都不影响整个项目的进行，能很好地衔接开发的继续，一般只有两种方法：言传身教的师傅带徒弟，完整的文档让新人可以彻底了解过去的经过。所以CMM模型注重的是组织的内部协调，组织执行力对软件开发过程的控制，确保开发过程中的每个环节都得到测试与规划。软件开发组织目前使用最多的是瀑布开发模型与极限编程管理，无论采用那种方式，其目标都是保证开发的软件高质量。CMM衡量的是整个组织的开发能力，用什么管理方式并不重要。
二、瀑布模式与极限编程对组织的影响瀑布模型非常适合流水线的管理，把软件设计变成软件工厂。瀑布模型管理方式：注重开发过程的文档，保证规划的功能的高质量实现，但忽视了客户应用的经常变化，瀑布模型的缺点是开发周期长，要实现迭代非常困难。但瀑布模型能很好地保证设计的功能的实现，尤其是初期设计非常充分，程序重用、类提取都非常精练，所以都年来，瀑布模型一直是主要的开发方式。极限编程更加注重客户需求的变化，采取快速看到结果的开发方式，有些象早期的快速模型开发方式，能看到结果，客户就可以尽早感觉系统，提出最切合的改革建议，避免开发后期的更改。极限编程还有一个程序员喜欢的地方，就是以编码为主，文档次之。极限编程关注程序员的感觉，把编程变成一种乐趣，与瀑布模型的大量烦琐文档相比更有吸引力，大大提供了开发人员的积极性。但是，极限编程设计部分相对较弱，先测试再编程的思想是否可以消除这些缺陷还有待于进一步实践。采用那种开发模式，是组织根据自己团队的侧重与开发产品的特点选择的，对于方式的选择有下面的建议：
1、 软件产品比较程式化，也就是说客户需求比较明确，开发重复性强，好比流水线的生产，每个汽车的工序与工艺要求一致。建议采用瀑布模型方式，文档的完备特别适合重复性的开发。
2、 软件产品创新性强，客户需求不明确，甚至要在开发的过程中不断重新确认，同时要求开发人员有足够的敏捷思维，发挥开发者的想象思维，建议采用极限编程。极限编程中的结对编程非常适合能力差不多的开发人员发挥创造性思维。开发模式的选择，直接影响团队的组织与管理，对CMM的评定也息息相关。CMM更关心软件产品的质量，对组织来说，还要注意对团队人员工作积极性的调动，人在心情舒畅的情况下往往能发挥的能力是通常状态下的数倍。很多团队领导都强调队员的无障碍沟通，但要实现无障碍沟通不是靠领导的命令，而是发自队员的内心。团队的能力与个人天才的本质不同应该是：1+1>2。也许这才是CMM评价的真实意图吧。
