XP

　　在各种敏捷方法学中，极限编程(XP)是知名度最高的一种。XP的主要实践有:Sit Together(坐在一起)、Whole Team(完整团队)、Informative Workspace(信息化工作场所)、 Energized Work(精力充沛地工作)、Pair Programming(结对编程)、Stories(用户故事)、Weekly Cycle(每周开发循环)、Quarterly Cycle(每季度开发循环)、Slack(松弛计划)、Ten-Minute Build(10分钟构建)、Continuous Integration(持续集成)、Test-First Programming(测试优先编程)、Incremental Design(增量式设计)。除此之外，XP还有一些配套实践。

　　让我们来看看其中的持续集成。如果前期的工作做得很到位，需求错误的风险得到了有效控制，那么项目进入构建阶段之后的主要风险就是无法得到可以工作的软件。在我经历的一个项目中，在大年三十下午，项目小组还在努力，公司的大老板也来到了开发现场。但是不幸的是，直到最后一刻，我们也没能实现大老板的心愿，在过年以前拿出一个能工作的测试版本。

　　持续集成不仅仅是针对无法得到可以工作的软件这一风险。通过在持续集成过程中执行各种层次的自动化测试，各种自动化的代码分析工具，我们就可以清楚地认识项目当前的状态，并努力保证项目处于健康的状态。

　　例如，通过代码依赖关系检查，我们可以确保在MVC架构中View没有直接调用访问持久层数据，从而保证架构在实现过程中没有被破坏。“信任，但要检查”，这应该是我们对待项目团队的态度。如果我们知道目标，但不知道我们目前在哪里，这种情况就叫做“迷路”。由于对项目当前的状态没有正确的认识，项目成员会对项目的进度产生错误的观念。持续集成有效地控制了“迷路”的风险，使软件开发的进度变得更透明、更可预测。

　　另外，持续集成和自动化测试、自动化代码分析一起，为我们提供了适应变化、将软件修改得更好的机会。我们可以大胆地对代码进行重构、采用新的组件、实现新的功能，同时保证这些修改与系统的其他部分很好地集成。如果没有人愿意、没有人敢修改原有的代码，这个项目的生命周期也就差不多走到尽头了。保留不断改进的机会，这对每个项目都是很重要的，这也大大降低了运营维护的成本和风险。

　　CMMI

　　CMMI(Capability Maturity Model Integration)是针对产品开发和服务的一个过程改进成熟度模型。它包含了一些最佳实践，关注开发和维护活动，覆盖从概念到交付和维护的完整产品生命周期。这些最佳实践按照关注的领域进行了分类，即所谓的“过程域”。

　　CMMI的过程域包括:项目计划(PP)、项目监督和控制(PMC)、供应商协议管理(SAM)、需求管理(REQM)、配置管理(CM)、过程和产品质量保证(PPQA)、度量和分析(M&A)、组织过程核心(OPF)、组织过程定义(OPD)、组织培训(OT)、集成供应商管理(ISM)、风险管理(RSKM)、集成项目管理(IPM)、集成团队(IT)、需求开发(RD)、技术解决方案(TS)、产品集成(PI)、验证(VER)、确认(VAL)、决策分析和解决方案(DAR)、集成组织环境(OEI)、组织过程绩效(OPP)、定量项目管理(QPM)、组织创新和实施(OID)、因果分析和解决方案(CAR)。

　　让我们来看看配置管理。任何严肃的商业开发都不能冒没有配置管理的风险，好的配置管理让我们能重复任何一个时间点的项目状态。在与一名项目经理的闲谈中笔者了解到，她对公司多年来实施CMMI的效果很不满意。我试着从积极的方面来引导她，问她觉得有什么方面进步很大吗?她说进步还是有的，感受最深的一点就是大家都习惯了使用版本控制系统。另一方面，我们仍然看到许多新参加软件开发工作的开发者，他们需要花一段时间才能熟悉版本控制的概念和操作。

　　如果与需求管理、变更控制和持续集成等其他最佳实践配合，配置管理将为项目成功提供更多的机会。

　　如果你持续关注配置管理这个过程域，你可能会看到许多使用cvs的开发者迁移到了Subversion上，也许还会看到Mozilla项目采用了Hg(http://www.selenic.com/mercurial/wiki/)，并给出了对配置管理工具的需求和选择的理由。Sun的Netbeans项目也迁移到了Hg，也给出了理由。如果你不关注这个过程域，你可能错过一些机会，给组织机构的发展带来一些风险。例如试图用微软的Visual Source Safe来管理大规模的项目，进行全球化开发。

　　融合

　　许多人都已经注意到将两大阵营的最佳实践进行融合的可能性。Jacobson提出只有敏捷是不够的，我们需要一种明智的(smart)软件开发方法。在一次演讲中，他用一个笑话解释是什么是明智:明智就是不要让自己受到伤害。我理解这就是在讲控制项目风险的问题。

　　Boem和Turner的著“Balancing Agility and Discipline”直接讨论了两种方法学的融合，并将结论导向了风险驱动的开发。Tom DeMarco和Timothy Lister的著作《与熊共舞》也是讨论风险问题。你甚至可以这样理解:项目管理过程就是一个风险管理的过程。

　　软件开发是一项风险事业。报告显示，即使放松条件，软件项目成功的比例也只有50%。更糟糕的是，这个数字没有变好的趋势。但我想指出的是，数字会欺骗。因为今天面对的是更复杂的系统开发，就像下棋，我们的对手在变得更强。对于一个职业棋手来说，他的胜率可能和业余棋手差不多，但他无疑更强大。也许项目成功的比例不会再提高，但我们的能力却在变得更强。

　　另一个强调得不多的方面是最佳实践所创造的机会。最佳实践为我们提供了许多得到更好解决方案的机会。换句话说，不仅提供了赢的机会，而且提供了赢得漂亮的机会。

　　冰冻三尺，非一日之寒。当你经过多年的学习、练习和持续改进，终于成为一名职业棋手时，你就能对复杂的棋局有更深刻的理解，在危险发生前二十步就将它化解，敏锐地发现漂亮的着法，取得重大的胜利。

　　风险和机会是所有最佳实践关注的东西。和下棋一样，你必须时时评估盘面上出现的风险和机会，并采取相应的战术手段。这些最佳实践就是为了有效地控制风险，并不要漏掉机会。如何让最佳实践服务于项目的目标，服务于组织机构的战略目标，这才是最重要的。最佳实践的意义在于它为你变得更强大指出了方向。

更多相关的软件测试文章：http://www.51testing.com/?action_category_catid_104.html