敏捷的竞争

没有毫无竞争的比赛，也不存在毫无冲突的系统。如果没有反对意见，那我们的世界将了无意趣。幸运的是，在敏捷的世界里有很多良性的竞争，比如Scrum与极限编程，Scrum与看板（Kanban），甚至Scrum 与Scrum 之间。然而，各式各样的敏捷方法并不是这场竞赛中唯一的选手，还有几个很有前途的、强劲的竞争对手贡献了各自的想法，这些想法有时是相似的，有时是互补的，有时又是绝对矛盾的。

较大的竞争对手之一是 精益软件开发 。精益软件开发是指将精益生产的概念应用于软件开发的领域。精益的七个原则[Poppendieck 2009:193]以在丰田方法 （丰田公司的管理理念）的14个原则和戴明 的14个管理要点为基础。精益和敏捷有明显的共通之处，这就是为什么精益和敏捷经常会有相同的专家从事相同的领域，分享相同的信众，出现在同样的博客、杂志和电视节目中。精益软件开发旗帜鲜明地集中于消除浪费和整体优化，从管理学的角度对敏捷世界做出了巨大的贡献。虽然精益方法较敏捷晚几年加入软件开发联盟，但精益运动通过发展自己的会议、顾问、教练和协会，已逐步迎头赶上。

软件工艺 运动是一个规模略小却颇具实力的竞争对手，其指导思想是软件工艺宣言 （参见图2.3），该宣言既是对原有敏捷宣言的扩展，也是对它的挑战。软件工艺的支持者认为软件开发者不是工程师，而是工匠（一些人以中世纪欧洲学徒模式作比喻）。工艺运动通过自己的（小型）活动、图书和论坛，正成为敏捷和精益共同面对的一个灵活而无畏的新对手。由于同处于轻量级软件开发阵营，所以尽管它们偶有冲突，但这三者似乎正在汇合成一个伟大的团队。

当然，重量级方法和框架也没有停滞不前。这其中最著名也最具争议的就是 能力成熟度模型集成 CMMI 。CMMI始于1987年，由卡耐基·梅隆大学软件工程研究所（SEI）开发和维护。起初，CMMI充当的是软件工程过程改进的描述，但它已逐渐发展成为一个更加抽象的框架，目前其涵盖除软件开发以外的其他许多行业。CMMI这一方法学旨在通过描述5个成熟度级别和22个过程域来指导软件开发。CMMI只能指出在过程改进的工作中可以解决哪些过程域的问题，但没有规定如何实现。正是由于这个原因，一些敏捷实践者相信CMMI是可以和敏捷软件开发相互兼容的——尽管CMMI有着长达数百页的描述，因为敏捷方法可以补充CMMI所缺失的过程实现部分。然而敏捷实践者倘若不彼此反对的话，他们就不是敏捷实践者了。因此，有些人认为，尽管CMMI出发点是好的，但是CMMI相当繁琐，以至于它不但把机构推向官僚化，还使团队陷入金玉其表而败絮其中的境地。

由项目管理学会发布和维护的项目管理知识指南 （PMBOK）也不乏类似的矛盾信号。有趣的是，指南最初旨在介绍项目管理通用的最佳实践。但自1987年第1版之后，经过若干次修订，该指南已变得越来越“敏捷”了，以回应敏捷项目经理所取得的成果。和CMMI相反，对于很多流程，PMBOK具体指导项目经理的工作。但是这些推荐的实践并非总与敏捷原则相切合，因此，很多项目经理正积极地尝试解决这些差异。当然必须指出，PMBOK涉及的大部分领域和敏捷是有差异的。 PRINCE2 与PMBOK完全相同，PRINCE2是由英国政府商业办公室发布和维护的一种相似的项目管理方法，主要在欧洲使用。

最后同样重要的是 统一过程 方法 ，其最著名的改进版本就是 Rational统一过程 （RUP），由Rational软件（现在属于IBM）在1997年制定。RUP之于软件开发人员就如同PMBOK之于项目经理。RUP定义了相当全面的过程框架，可以（并应当）剪裁以适应特殊的项目环境，但是从要求交付的文档来看，整个框架看上去还是很官僚，很笨重。敏捷专家认为，过程应当从最简单的少量实践开始，并贯穿整个项目不断地改进。RUP尝试了相反的方法，一开始就定义了很多实践，然后建议删除那些不需要的实践（我经常把RUP方法比喻为为了改装成自行车而去购买波音747，其实很多项目用自行车就够了）。当然为了应对敏捷在全球的流行，统一过程推出了几种敏捷选择，包括 敏捷统一过程 （AUP）， 开放统一过程 （OpenUP）和 精炼统一过程 （EssUP）。但是它们当中没有一个在全球敏捷联盟中表现良好。 fSdnBj2t30pXznmpYezlDqgUTSXrqVD/1XleVIm9W9iS3Cp2ivub3RMBxlqJvAWF