在软件开发中平衡规范与敏捷 睿思成 靖爽.pdfVIP

在软件开发中平衡规范与敏捷 睿思成靖爽 如果只有强有力的的规范而缺乏敏捷，将导致官僚作风，进而停滞不前；缺乏规范的敏 捷如同一个新公司在盈利之前的不负责任的狂热。 －Barry Boehm 软件系统在我们的社会中扮演着举足轻重的角色，及时构建出稳定高效、符合用户需求 的软件系统一直是软件从业者的追求。当今剧烈的商业竞争形势下，在快速构建、快速响应需 求变化方面对软件开发提出了更加迫切的要求。我们知道决定软件产品质量的要素主要是参与 项目的开发团队、开发团队所遵循的过程（流程）以及所应用的技术。技术方面我们已经拥有 了结构化设计、OO 、UML 、DBMS 、CORBA 、DCOM 、.NET、J2EE ，以及不胜枚举的编程 工具、编程语言，可以说在已经明确所构建系统范围的前提下，现有的技术基本可以满足构建 的要求，那么如何通过人和过程这两个要素的改进为软件系统的质量提供增益？两个要素孰轻 孰重？如何在项目实践中进行平衡？ 在早期软件开发中缺乏规范的流程就会导致项目和产品的混乱，集中表现为难以集成、 交付延期、质量不佳、成本大大超过预算。在一个大型软件项目几近失败的时候，典型的批评 的声音如下：“软件工程学科已经有很多年了，但是至今仍未能提供信息时代社会所需的、成 熟的软件工程规范 ”。为了解决软件开发规范化管理的问题，随即出现了若干规范开发的方 法。CMM （能力成熟度模型）作为软件过程规范的代表，将软件开发最佳实践分类为若干关 键过程域，进而形成了过程改进的框架，并且可以作为衡量组织开发能力成熟度的标准。这种 规范是基于工程规范和大型软件系统开发而制定的计划驱动方法，强调软件系统开发的可预见 性，通过流程标准的可重复性提高开发的效率和质量。 由于 CMM 是软件开发最佳实践的集大成者，几乎囊括了软件过程的方方面面，但是软 件项目所采用的过程应该与该特定项目的特性（包括规模、业务领域、变更程度）、开发团队 的技能和文化、风险等环境相匹配。非常遗憾的是流程的制定者、质量保证人员乃至项目经理 几乎不具备足够的经验和专业能力：根据项目的实际情况裁剪出与之匹配的流程，生怕进行了 过度的裁剪导致项目失败；结果就是将制定的整套流程不作任何修改（或者仅仅进行了细枝末 节的修改）让项目去遵循，甚至任何项目的生命周期模型都简单的选择了瀑布模型或者是 V 模型。可以想象适用于航空管理系统开发的流程规范被应用于开发周期仅有半年的小型规模系 第 1 页共 6 页 睿思成研发管理咨询 国内首家集成IPD 咨询和西门子PLM 实施的专业服务机构 统的情景！另外对 CMM 的误解：迷信成熟度等级，认为成熟度级别越高就意味着更高的软件 质量，就会将全套的流程、文档看成项目成功的安全保障，却将产品、需求扔在一边，软件开 发成了彻头彻尾的官僚主义。其实倒不妨将 CMM 看成一本字典，根据需要表达的意思来选择 你必要的字词进行有机组合，而不是将整个字典统统罗列出来。 大量的计划、文档可以作为规范管理的显著特征之一，也是广大软件开发人员对此持有 异议的主要原因之一。以极限编程（Extreme Programming ，XP ）为代表的敏捷（Agile ）开发 方法的吸引人之处在于对繁文缛节的官僚过程的反叛：不再面向文档，而是面向可执行的代 码，根本的文档应该是源码。其实文档的多少只是表面现象，真正的差异在于敏捷型方法是 “面向人”的而非“面向过程”的，是“适配性”而非“预设性”，也就是欢迎过程中的变 化。极限编程是一种面临迅速变化的需求进行快速开发的轻量级的开发方式，强调拥抱变化、 短迭代周期和短发布周期、简单设计、用户参加开发、持续集成和重构。假设当前的项目特征 符合极限编程的要求和约束，实际上应用极限编程的难度偏高，需要紧密的客户关系、精英的 团队、对XP 各个实践的精通。看看下面这个例子： 极限编程专家 Robert C. MARTIN 曾经碰到过一个人，此人声称自己的组织正在使用 XP 。MARTIN 问他如何看待结对编程，此人答道：“我们不结对编程。”MARTIN 又问他重构进行 得怎么样，此人答道：“我们不重构。” MART