在大型开发组织的敏捷团队中实施CMMI-InfoQ



 写点什么

近年来，敏捷开发方法能够更好地适应现代软件开发，逐渐发展成为一种主流开发方法，也正在改变着软件开发过程。然而，敏捷开发方法常常被认为同 CMMI 过程无法共存，因为 CMMI 被看做是以规格化方法控制软件开发过程。

2008 年，Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad 和 Sandra Shrum 出版了《CMMI 和敏捷方法：为何不彼此相容》一书，为那些既想保持项目过程可控又想体验敏捷开发灵活性的开发组织开启了一扇窗口。CMMI 过程管理通常被看作实施敏捷开发的障碍，看作自组织团队的敌人，因为CMMI 组织和敏捷团队具有不同的文化背景，这也导致了很多误解。比如，敏捷团队很少使用“可预测性”一词，但是“可预测性”却是CMMI 过程管理模型的关键所在。

另一方面，CMMI 是一个跨组织的方法，CMMI 的严格执行可以改进软件质量和控制软件开发成本，尽管执行CMMI 过程管理会花费开发组织的很多精力。

项目管理者往往倾向于采用CMMI 过程管理, 而开发组织内部的那些自组织的开发团队却并不认可, 甚至把CMMI 过程管理视为项目的一大危险。对立的两者如何才能统一起来？大型开发组织的自组织敏捷团队如何才能满足软件开发成熟度（2 级到3 级）呢？

消除语言障碍

让对立的两者统一起来，首先要解决的问题是语言沟通障碍。为了使敏捷传道者或过程管理工程师能使用同一语言跟使用不同技术的开发团队沟通交流，就需要使用一种名为“元语言”的现代技术交流方法。使用元语言，你要能保证团队成员能够把元语言转化成他们的自然生命周期语言。举一个例子，一个PMP 爱好者经常谈论“功能需求”，但是敏捷团队成员却喜欢使用“用户故事”一词。他们在谈论着同一个概念，但是却使用着具有不同意义的词汇。在这个例子中，你可以统一使用“规格说明”作为元语言，使两者都乐意接受并且统一认识。

元语言是统一敏捷开发过程和CMMI 过程管理的关键。如果CMMI 传道者、项目管理者和敏捷成员能用统一的元语言进行沟通交流，那么才能消除语言障碍，才能保证沟通交流通畅。

比如, 在需求开发阶段，敏捷开发者和普通开发者就可以使用元语言来统一他们各自的生命周期语言。如下表所示：

Metalanguage Term

元语言

Formal Methodology

正规开发方法

Agile Methodology

敏捷开发方法

Goal

目标

Functional Scope

功能范围

Epic

史诗故事

Business Case

业务用例

Use Cases

用户用例

User Story

用户故事

Appliance

应用需求

Scenario Requirements

场景需求

Acceptance Conditions

验收条件

Review

复查

Periodical Tracking Meeting

定期走查会

Retrospective

项目回顾

图 1：列举客户需求开发阶段的一些元语言

识别和使用统一的元语言就要求：CMMI 过程管理的传道者能识别元语言，统一元语言，缩小同成熟度模型之间的的差异，而且，还必须认识到元语言需要不断的扩展和提炼，这是一项没有终点的工作。

(点击图像放大)

图 2：你能否识别出这是产品未完成清单还是需求清单？理想情况是你能把你自己的生命周期模型应用于公共模型。

成熟度模型之间的隔阂

没有一个项目管理过程是完美的，CMMI 过程管理也不例外。开发团队中的队员按照CMMI 过程管理来安排每天的工作，而要执行CMMI 过程管理中的那些生命周期模型却是由那些在日常工作中没有处理过这些过程问题的人来定义的。这就导致了在多个开发团队之间实施成熟度模型之间的隔阂，比如有些实践对某些人来说是应该执行，而对另一些人来说却没有执行过。CMMI 非常明确地指出了为了达到某成熟度水平，必须执行哪些具有良好实践（通用的和专用的实践活动）。如果开发组织想通过某CMMI 级别的评估, 那么他们就会冒着 CMMI 评审不通过的风险。当开发组织带着繁重的官僚的过程管理要求从事开发工作时，常常会导致 CMMI 级别评估失败，尽管满足了组织单元的过程管理。很多人都知道，为了尽量节省实践过程，有些文档中的用例可能会被抛弃，或者是没有质量保证下很多测试被简化执行。

很多团队并没有意识到：当他们在日常工作中使用良好实践的过程管理时，他们也倾向于忽略那些能增加解决方案价值的做法。其失败的主要原因就在于被称之为“设定”的 CMMI 过程管理的首要原则。

“建立”（Establishing）和“维护”（maintain）在 CMMI 中意义非凡，它们通常成对出现。简言之，这两个词的含义是任何过程活动都应该被明确定义的、文档化和可以使用的。CMMI 2 和 CMMI 3 过程管理都包含了一个或者多个“建立和维护”活动。

开发团队中的成员从一个团队转到另一个团队时不可避免会带来一些麻烦（这在大型开发组织中常常发生）。无论新团队成员的能力如何，他们都要花费比预想中更多的时间去适应新团队。原因很清楚：新成员在努力适应新团队过程中是会犯错的，并且我们都知道这是一个压力巨大的过程。

尽管存在隔阂，为何还要使用 CMMI 呢？这是为了让开发团队知道如何完成他们的工作。他们用一个足够正确的方式做一个足够正确的事情，所以高管也能忍受这些成熟度隔阂。开发团队再也不会做错事，但也不能适应持续业务发展。CMMI 传道者应该知道尽管存在成熟度隔阂，但是团队遵守的活动对业务交付价值是足够的。进化，而不是革命，适用于那些工作良好的团队。考虑到 CMMI 实施周期（即达到目标成熟度等级所需时间），值得向更高成熟度等级而努力。

良好实践清单

参考以往按照同样工作方式完成相同工作量的团队 / 项目，从而评估出团队 / 项目工作的假设，但是这往往同现实产生超出我们想象的冲突。如果我们用假设来引导变化，这将会成为开发组织的梦魇：部分实施的地狱。在这种情况下，团队不能适应新的工作方式，以至于他们仅部分地采用它，而放弃那些能让他们做的足够好的以往的实践活动。这种挫败感常驱动一个开发组织放弃实施 CMMI。

然而，CMMI 提供了一个广泛的良好实践的集合。 CMMI 开发版本 1.3 提供了很多良好实践，以达成通用的和专用的目标。这些过程域仅仅是一个样例，说明了要达到成熟度等级需要完成那些过程域。模型永远无法控制开发组织应该完成那些实践。CMMI 传道者和过程管理工程师应该倾听团队的想法。在这方面，我的经验是：聆听团队成员的想法，优化他们的工作，而不是迫使他们去改变工作方法。

想达到 CMMI 2（已管理级）的 SCRUM（一种迭代式增量软件开发过程）团队在日常工作中需要实施下列过程域：“需求管理”（REQM）、“项目计划”（PP）、“项目监控”（PMC）、“过程和产品质量保证”（PPQA）、“配置管理”（CM）和“度量与分析”。

SCRUM 团队在 SCRUM 规划会议期间执行项目计划，在每天的 SCRUM 中执行项目监控，但他们处理积压的订单时需要执行需求管理。很多时候，他们持续交付环境需要一个好的配置管理。此外，他们还需要实施一些 CMMI 3 的过程域，为他们进行审查性会议，使用类似 TFS 和 CollabNat 平台支持他们日常活动，以提供分析标准。

然而，CMMI 3 的一个集成项目管理（IPM）却要求 SCRUM 团队改变管道生产方式，放弃纯 SCRUM，这是很难实现的。集成项目管理提供了强大的良好实践过程以帮助团队满足特定项目的几乎所有需求。想象一下，一个利益相关者谁还需要一系列基于模板而编写的特定文档。这类事情本应该由产品所有者来解决，现在 CMMI 却优雅地把这活给干了。

大多数敏捷团队采用敏捷实践以适合各自敏捷的生命周期。但请记住，敏捷只是一个宣言，仅列举符合常理的一些原则。一个过程管理工程师，就应该能识别出那些良好实践，并能让自己的工作过程同 CMMI 实践相匹配。例如，找到一种适合他们的同行评审方式。队员们甚至都不需要知道，这是 CMMI 过程管理的一部分。敏捷团队之间经常进行一些演示，以发现各个小组的缺陷，这是不是同行评审？在需求收集的尾声，也可以采用同样的演示方法帮助利益相关者在改善积压下来的需求。

(点击图像放大)

Fig 1. 团队中提升成熟度的建议流程图

挑选出那些良好实践，用元语言重新描述后，加入到过程域目录之中。CMMI 传道者和过程管理工程师可以通过分析这些目录，让团队成员认识到在某个过程应该执行那些实践。为了修复或者弥补一个放弃的好的实践，他们可以从实践目录中挑选合适的满足其目标的实践来执行。记住 CMMI 不但能评估成熟度还能评估能力，所以过程域目录应该包含所有 CMMI 通用实践和专用实践，这将是团队执行 CMMI 的一个路线图（参考 CMMI 路线图: Improving IT for the Business )。应该鼓励团队执行良好实践清单中的实践，或者把他们的最佳实践添加到清单中。对于任何一个想参加 CMMI 过程评估的人来说，这个任务类似于团队 PIID（实施标识描述）所阐述的那样，类似于对良好实践目录的分类。

良好实践的一个例子就是：在提交任何代码更改之前执行“双人复核”和联机结对编程，前者是一种特殊的“同行评审”形式，也是 CMMI 过程域中最递归的概念之一。双人复核要求至少两位成员。比如，Bob 修复缺陷，Joe 执行双人复核。经过一系列检查（无非就是一些常识，测试，检查样式，等等）后，Joe 负责复核 Bob 解决的缺陷，并把源代码提交。Schneider 电气公司的 ALM 团队指出，双人复核可以减少缺陷数和编译错误数近百分之七十。

(点击图像放大)

图3. 微软Team Foundation Server 的审查工具

(点击图像放大)

图4. 从发布补丁来看敏捷持续集成构建示意图。请注意，某一团队成员执行变更，并复核上传源代码。可以从代码变更视图中看到它。

敏捷反馈的另一个良好实践是记录漏洞。漏洞就是指破坏的过程或流程，它遵循着水管法则：水管中有少量漏洞是问题不大，但是漏洞太多时就难以保证足够水量继续往前流淌。当一个团队成员需要打破某一过程以继续工作时，这个成员就可以发布一个漏洞，并把其作为一个反馈和改进过程加以分析。漏洞分析工具可以帮助分析过程，或者识别风险（协助纠正措施，例如，培训课程）。这符合敏捷宣言中的“个体和交互高于流程和工具”，但当流程在某些方面对最终产品交付有用，那么这个流程就是合理的、有用的。

(点击图像放大)

图5. 项目中一个漏洞，用户在没有经过复核的情况下需要上传源代码到源代码资源库。这种情况其实是负责维护的团队成员需要在周末紧急修复缺陷。

结论

由上可知，敏捷方法和CMMI 并不是对立的，而是彼此之间一个很好的补充。传统的CMMI 团队可以从传统敏捷团队中吸取一些新的过程实践，但是他们之间还需要使用共同的元语言来做到这一点。CMMI 传道者的成功第一步确定元语言中的共同要素。良好实践清单有助于开发组织标准化团队开发过程，有助于训练敏捷团队以达成某成熟度级别。该目录提供了必要的良好实践，为此团队需要达到更高的能力，自然而然地导致了较高的成熟度级别。

关于作者

Nicolás Afonso Alonso 目前是公司的软件开发技术主管和 Schneider 电气公司实施 CMMI 的传道者。在此之前，他作为航天工业领域集成项目的质量管理团队主管，工作了好几年。加入 Schneider 电气公司以后，他主要致力于引领软件开发的 Team Foundation Server 活动的过程管理和 ALM 基础规划。