【注：我转贴这篇文章到我的 Blog，原因是我不想失去它。】

 

 

在软件开发中平衡规范与敏捷

来源：深圳汉捷研发管理咨询有限公司 作者：靖爽

如果只有强有力的的规范而缺乏敏捷，将导致官僚作风，进而停滞不前；缺乏规范的敏捷如同一个新公司在盈利之前的不负责任的狂热。          －Barry Boehm

软件系统在我们的社会中扮演着举足轻重的角色，及时构建出稳定高效、符合用户需求的软件系统一直是软件从业者的追求。当今剧烈的商业竞争形势下，在快速构建、快速响应需求变化方面对软件开发提出了更加迫切的要求。我们知道决定软件产品质量的要素主要是参与项目的开发团队、开发团队所遵循的过程（流程）以及所应用的技术。技术方面我们已经拥有了结构化设计、OO、UML、DBMS、CORBA、DCOM、.NET、J2EE，以及不胜枚举的编程工具、编程语言，可以说在已经明确所构建系统范围的前提下，现有的技术基本可以满足构建的要求，那么如何通过人和过程这两个要素的改进为软件系统的质量提供增益？两个要素孰轻孰重？如何在项目实践中进行平衡？

在早期软件开发中缺乏规范的流程就会导致项目和产品的混乱，集中表现为难以集成、交付延期、质量不佳、成本大大超过预算。在一个大型软件项目几近失败的时候，典型的批评的声音如下：“软件工程学科已经有很多年了，但是至今仍未能提供信息时代社会所需的、成熟的软件工程规范”。为了解决软件开发规范化管理的问题，随即出现了若干规范开发的方法。CMM（能力成熟度模型）作为软件过程规范的代表，将软件开发最佳实践分类为若干关键过程域，进而形成了过程改进的框架，并且可以作为衡量组织开发能力成熟度的标准。这种规范是基于工程规范和大型软件系统开发而制定的计划驱动方法，强调软件系统开发的可预见性，通过流程标准的可重复性提高开发的效率和质量。

由于CMM是软件开发最佳实践的集大成者，几乎囊括了软件过程的方方面面，但是软件项目所采用的过程应该与该特定项目的特性（包括规模、业务领域、变更程度）、开发团队的技能和文化、风险等环境相匹配。非常遗憾的是流程的制定者、质量保证人员乃至项目经理几乎不具备足够的经验和专业能力：根据项目的实际情况裁剪出与之匹配的流程，生怕进行了过度的裁剪导致项目失败；结果就是将制定的整套流程不作任何修改（或者仅仅进行了细枝末节的修改）让项目去遵循，甚至任何项目的生命周期模型都简单的选择了瀑布模型或者是V模型。可以想象适用于航空管理系统开发的流程规范被应用于开发周期仅有半年的小型规模系统的情景！另外对CMM的误解：迷信成熟度等级，认为成熟度级别越高就意味着更高的软件质量，就会将全套的流程、文档看成项目成功的安全保障，却将产品、需求扔在一边，软件开发成了彻头彻尾的官僚主义。其实倒不妨将CMM看成一本字典，根据需要表达的意思来选择你必要的字词进行有机组合，而不是将整个字典统统罗列出来。

大量的计划、文档可以作为规范管理的显著特征之一，也是广大软件开发人员对此持有异议的主要原因之一。以极限编程（Extreme Programming ，XP）为代表的敏捷（Agile）开发方法的吸引人之处在于对繁文缛节的官僚过程的反叛：不再面向文档，而是面向可执行的代码，根本的文档应该是源码。其实文档的多少只是表面现象，真正的差异在于敏捷型方法是“面向人”的而非“面向过程”的，是“适配性”而非“预设性”，也就是欢迎过程中的变化。极限编程是一种面临迅速变化的需求进行快速开发的轻量级的开发方式，强调拥抱变化、短迭代周期和短发布周期、简单设计、用户参加开发、持续集成和重构。假设当前的项目特征符合极限编程的要求和约束，实际上应用极限编程的难度偏高，需要紧密的客户关系、精英的团队、对XP各个实践的精通。看看下面这个例子：

极限编程专家Robert C. MARTIN曾经碰到过一个人，此人声称自己的组织正在使用XP。MARTIN问他如何看待结对编程，此人答道：“我们不结对编程。”MARTIN又问他重构进行得怎么样，此人答道：“我们不重构。” MARTIN又问他计划游戏的效果如何，此人答道：“我们没有计划游戏。” MARTIN问道：“那么你们做了什么？”得到的回答是：“我们只是不写任何文档！”

我想这位老兄是将极限编程当作了无序的“code-and-fix”，根本不了解各个实践的含义，更谈不上对各个实践的熟练运用，可以想象该项目失败肯定 “会归于极限编程所赐”；甚至有人攻击极限编程的“40小时”工作，认为IT人员不得不加班，因此通过5×8的工作无法完成工作，殊不知极限编程提倡的稳定的工作节奏（Sustainable Pace），是指项目开发需要持续稳定的工作效率，是马拉松式的长跑，而不能通过跑百米的方式奢望一蹴而就。其实对于规范和敏捷两个方面都存在了大量一知半解的人，他们根据自己的喜恶来随意扭曲原来的真正涵义、“裁剪”流程或者断章取义的割裂活动实践，并将项目的失利归咎于流程。下面让我们看看两种开发方式真正的区别在哪里（下面仅仅列举了主要区别）：

敏捷方式采用较短的迭代和发布周期，根据上一次迭代的完成情况、需求的变化等信息规划未来的进度计划，在制定计划过程中强调协调沟通，开发人员和用户统一确定需要完成任务的优先级；规范方式通常采用瀑布模型，即使采用了增量式、螺旋式的开发生命周期模型，一般的发布周期也较长，通常会在开发过程中不同的阶段修正计划，这种方式在项目规模较小、需求变化较大的情况下，开发过程会显得臃肿而低效：“规范化”的处理需求变更活动会占用大量的时间，令人烦恼的是即使在需求开发阶段投入大量工作，也很难获取最终的用户需求（用户在真正触摸到系统并用一用它之前无法提供完整的需求），也就无法使需求变更率下降到“理想”的程度；

对于开发成员之间的沟通，敏捷方式将系统的“隐式知识”保存在项目成员的头脑中并保持一致，并不维护大量显式的文档，在项目规模和成员数量不大（100人行吗？50人？20人？——20人到底行不行无法确定，不过10个人肯定行。现在就回顾一下你领导和参与的项目行不行吧！）并且具备足够的业务水准的情况下，确实可以节省大量的时间，将主要精力聚焦于需求和尽快可执行交付件；而规模进一步增加、团队中包括一些新手时，“隐式知识”就会凸现扩展能力不足、人员无法通过头脑和少量文档同步和维护大量信息的劣势，这时通过文档进行显式的维护信息一致性会更加适合；

敏捷开发的一个基本假设就是变更成本/时间曲线可以保持平稳，这样后期的持续设计、重构等活动才会是低成本的，但是其强调的简单设计是否会保证架构具有足够的伸缩性，进而使变更成本/时间曲线可以保持平稳呢？这似乎自相矛盾；不过Martin Fowler、Robert C. MARTIN这种设计模式方面的泰斗认同简单设计是可行的，我等凡人也就无话可说啦，不过我想不明白到底什么样的设计才能算作“简单设计”呢？以上就是敏捷方式所提倡的“反射（或者响应）式”的设计方法，另一种就是预见式的方法：架构师会预计变更并实现通过设计避免这种变更带来的影响。听起来不错，问题是变更是否会象你所期望的那样变更？如果答案是否定的，根据猜想的需求而进行设计的系统架构可能会失效，那么耗费的大量时间是否值得？要知道修改的时候有大量的文档工作等着哪！

敏捷方式将用户作为开发团队的一分子，开发过程中用户和开发人员就坐在一起进行无缝的沟通，用户提供了基本需求并指出优先级、随即验证了实现的需求并及时给出反馈，这种方式无疑会使开发效率更高、真实需求的真正实现有了保证，风险就是开发团队具有良好的客户关系使得客户就坐在你旁边吗？你能找到称职的客户进行合作吗？当用户看到软件修改是如此的“简单”，是否会大大增加他不再认真审视自己的需求、频繁变更的勇气？如果这样，开发人员会陷入没完没了的变更当中！另一种处理需求的方法就是与用户签订合同（敏捷方式当然也要签订合同，否则如何付费），要求用户对需求规格进行确认并基线化，需求变更太多就要额外付费啦。实际上在这个时候要求用户对自己的需求和变更进行承诺，如果你是用户，你会有勇气承诺吗？

下面还有很多，如果你想接着比下去的话。不过上面的比较已经能够说明问题啦。

对于软件开发管理持有规范化方法和敏捷方法，究其根源大约是对软件系统开发的本质的认识：软件开发究竟是什么？是工程过程、艺术创造？或是两者兼而有之？如果是这样，在不同的项目中，他们所占的比例有多少，如何界定软件开发中哪些活动是工程过程，哪些却是艺术创造呢？如果都不是，那么会是其他的什么呢？

如果认为软件开发属于工程过程（或者工程过程的成分居多），多半会支持采用规范化的管理方法——已经被传统系统工程、质量控制领域所实践证明的行之有效的方法；如果认为软件开发属于艺术创造（或者艺术创造的成分居多），而艺术创造的管理是很困难的——几乎会采用所谓敏捷式的方法进行管理。但是软件系统的开发是如此的复杂，很难明确界定到底属于哪个范畴（比较实际或是折中的看法是两者兼有，并且在不同项目中比例不同），这就决定了对软件开发所采取的管理方法不是一元的——敏捷和规范方式不是零和游戏中的双方，需要根据不同项目的特征来选择不同的方法，或是在一定程度上进行平衡和融合。

对于一个项目选择哪种开发方法，我认为首先需要考虑的因素是“人”：软件系统毕竟是由人开发的，其过程也是人去执行和改进的。谁来决策呢？项目经理、 SE、QA、项目成员采用民主集中制——投票选举、还是遵循公司规范的流程定义或是裁剪指南（如果有的话）？我的看法是谁能够清楚项目的特性、参与项目的开发团队等信息，并且对各种软件开发过程（敏捷式、规范式）、流程中各个活动对整个流程的意义都有充分的认识（基于实践的、而不是仅仅从书本上得来的），这样的人才有资格为即将启动的项目选择开发过程，并且这个人还需要主导（或是重点关注）这个项目的运作，在过程中动态取舍和调整流程活动。当然，他需要对业务有一定的了解，例如一个应用软件项目的主导者不清楚XML和UML的区别，我就很介意他是否会将XP（Extreme Programming）方法与Windows XP的开发建立可笑的联系——这样的人绝对不能主导你的项目，如果你期望项目成功的话。你会怀疑公司是否有这样的稀缺资源？我就要反问一句：如果公司没有人对流程有透彻的理解，或是不屑于深入项目去了解那些“细枝末节”但是却至关重要的琐事，评什么认为你的项目所遵循流程的质量是合格的？如果向Watts S.Humphrey 所言“软件系统的质量取决于用于开发和改进它的过程的质量”，有问题的过程会指导未来的项目取得成功吗？难道执着追求的CMMI的等级会成为项目成功的倚天屠龙的利器？我看充其量只是不称职的主导者逃避责任的护身符！你可能会认为根据公司现有的流程定义或是裁剪指南、并结合项目的实际情况操作即可，但是我要说的是文档永远只是文档（许多公司的流程定义和裁剪指南自从通过认证那天起就再没变过，这东西是否象人参一样时间越长越有疗效？），如果不真正理解它，不真正深入到项目中去，将规范指南看成一个神奇的专家系统：输入的是项目的特性，输出的就是理想的项目过程（或者认为不懂流程而“懂”项目的项目经理配合不懂项目而“懂”流程的QA就可以完成项目过程的定义——“合格”的零件没有润滑会紧密咬合在一起运作吗？！），我只能惊讶于你对软件系统开发的理解程度的肤浅，并确信项目即将成为死亡之旅！当然一个称职的流程负责人在制定项目流程时会遵循公司相关的原则规范，然而更加重要的是他的聪明才智：对流程和项目的洞察力和宝贵经验，并且对新鲜的方法持有积极的态度，因为对于软件这个领域我们需要知道的东西太多啦！如果你的公司还没有人具备这样的能力，就快点培养或是招募吧！没时间？——有的是时间和金钱承受一次又一次失败，而不在培养人上面下功夫，实在佩服这种勇敢的本末倒置的管理！

两种方法——敏捷、规范，他们适用的范围的确不同，这是流程制定者需要考虑的重要因素。在kent beck的《Extreme Programming Explained》一书中提到XP对于10人以下的项目团队可以适用，但是超过20人就可能运作困难，当然项目成员需要掌握XP的若干实践和原则，否则还是采用传统的规范方式吧（如果成员加上项目经理都是新手，新的连什么样的流程都不知道，我只能预先为项目默哀啦）。对于指定的项目，成员的技能水平也会影响到参与项目的人数，技能越高，需要的人数越少，那么可以支持的项目的系统规模就会相对大一些——毕竟人数减少可以大幅度减少沟通的工作量的支出。小规模的项目中，采取“隐式”的方法进行项目信息的同步，削减工作量支出的好处是诱人的；但是无法想象数十人参与的项目也可以采用同样的方法——大量的变更信息、架构设计等等，毕竟头脑记忆的信息量是有限的，这时候文档会派得上用场。一般说来，系统规模越大，其安全性、稳定性（神州X号太空飞船的控制系统）等方面的要求也较高，用户对需求的认识相对深刻和稳定一些，寄希望于通过简单设计、持续重构和集成等方法保证系统的质量，风险较大；反之，敏捷的方法适用。至于处理需求的不断变更，敏捷方法看来做得不错，规范的方法则可以采用有计划控制的迭代、增量式的生命周期模型，这样除了加快变更的响应速度，也可以尽早暴露技术风险，提高计划的准确性。

但是当前的软件项目的特性并不能绝对严格的符合敏捷、规范方式要求的适用范围，这就需要在两者之间互相借鉴，取得一定程度上的平衡：说起来有点玄，其实不然。无论CMM、DoD、RUP、XP、Crystal、还是其他的方法，都是对以前软件项目成功实践的总结和归纳而形成不同的框架，例如象需求管理、配置管理、风险管理、测试驱动、增量式开发都不是什么新玩意儿，甚至比较新鲜的“结对编程”则远在50年代就已经有应用的实践了，无所谓君临天下、适用于特性参差不齐的各类项目的统一的最佳实践，而只有适用于某类特定项目的过程实践。在确定一个项目的过程时，应该根据实际情况对统一的过程进行修改。如果项目和人员组成的特征更加符合规范式方法的擅长范围，就可以将规范式方法作为过程的主体，辅助以适当的敏捷化实践，例如按照需求优先级和技术风险规划版本的开发，让用户更加密切的参与到项目中来；反之亦然，在敏捷化开发中加大架构设计的力度，增加架构的伸缩性，根据业务经验对明显的需求变化及早准备，尽量减少变更成本/时间曲线的斜率，定义里程碑以确定项目的进度等等。在流程制定者真正掌握了其必须的知识（主要是各种方法的适用约束）和项目信息时，其定义的流程才是有效的和有生命力的，而不是机械的抱定某种模式不放，遇到挑战时象王明一样祭出马列原著作为挡箭牌。

流程的认识、定义和改进不是一朝一夕的，但是路却在脚下——“不积跬步，无以致千里”。CMM适时的加上了一个“I”——变成了CMMI，我们可以发现其中增加了“集成团队”、“风险管理”等过程域，更加贴近了敏捷思想（不知道原著者是否同意这种说法）——我们的项目又为何视变化为洪水猛兽？各个软件项目中都充满了特有的风险和不确定的因素，这才使一代又一代精英义无反顾地投入到了充满魅力（当然也充满了荣誉和利益）的IT行业，随着实践经验的积累会增加项目主导者对流程的深入理解，只有这样才能制定出适当的流程，找到规范与敏捷的恰当的平衡点。

评论

1 楼 ozzzzzz 2007-03-11  

作者基础概念匮乏，显然这个论题他驾驭不了。
首先cmm是方法还是标准这个就是一个问题，而作者显然不能统一他的观点。其次现在流行的管理是“基于《过程》的管理”，但是这个《过程》同cmm中说的过程根本就是南辕北辙的，这一点作者显然不清楚。其次xp至少在3年前就有80人规模的商业化团队使用，这一点只是看xp那本书是看不到的。类似的例子很多。
这个文章同现在那个张询都是一个路子，是看cmm现在臭了，agile火了，所以要换个说法来开点新思路骗取信任了。