迈向敏捷 CMMI Level 3：需求开发和验证

本文解释了如何在敏捷环境中做需求开发，本文涵盖了相关的概念，并举例说明了敏捷团队应该如何针对标准 CMMI 过程改进评估方法（SCAMPI）去执行 CMMI 开发模型，以达到需求开发和验证域的第三级。

第一部分描述并分析由敏捷实践覆盖的 CMMI 开发模型的过程域。

第二部分列举了一些敏捷 CMMI 实践案例，它们采用了一些公认的最佳实践。这些例子来自于实际的应用，能够与敏捷一起用于 CMMI 过程域。

1.1 敏捷 CMMI 介绍

1.1.1. CMMI 简介

CMMI 在 Wikipedia 上的定义是：“一种过程改进培训和评估程序和服务……它能被用来指导跨项目、部门或者整个组织的过程改进。”

CMMI 模型是用过程域来分类的。每个过程域覆盖一组通过执行某些实践可以达成的目标。CMMI 开发模型的目标不是评价这些实践怎么是最优的。它希望团队能够进一步演变这些实践，从 CMMI 开发模型的视角来看，有一个不怎么完美的实践总比什么都没有要好一些。

CMMI 开发模型过程域有配置管理、验证和确认等。每个域都有一个简称，比如众所周知的配置管理是 CM，验证是 VER 等等。

图 1：CMMI 开发模型分类。CMMI 可以看成是过程域的集合体，过程域由目标组成，这些目标可以分为通用目标（所有过程域通用）和特殊目标（单个过程域专属的）。每个通用或特殊目标都与实践有关，它们分别是为通用实践（GP）和特殊实践（SP）。

这里有两类目标。以下列表是通用目标和相关的通用实践：

• GG 1 达成特殊目标
  • GP 1.1 执行特殊实践
• GG 2 管理流程制度化
  • GP 2.1 建立组织方针
  • GP 2.2 设计过程
  • GP 2.3 提供资源
  • GP 2.4 分配职责
  • GP 2.5 培训
  • GP 2.6 控制工作产品
  • GP 2.7 识别干系人并争取相关干系人的参与
  • GP 2.8 监控过程
  • GP 2.9 客观地测评过程的符合程度
  • GP 2.10 和高层管理一起审查活动的进行状态
• GG 3 制度化已定义的过程
  • GP 3.1 建立一个已定义的过程
  • GP 3.2 收集过程相关经历

通常，通用目标和实践是由组织提供并授权的。个体团队可以更加自主地决定他们想要如何去达成特殊目标。我们在本文中将重点关注需求开发的特殊目标的达成，我们将说明如何用敏捷实践来达成。

当使用 CMMI 开发模型时要考虑工作产品的定义。简而言之，工作产品就是实践的结果。任务的执行如果不能产生任何价值那就是在浪费时间（也是在浪费金钱），所以所有实践应该至少有一个工作产品。

为什么 CMMI 开发模型经常被视为是官僚的呢？其中一个最主要的原因是，它以笨重的过程产生了大量以文档为主的工作产品。所有这些文档非常难以维护。我们在 ALM@团队的经历告诉我们说，一定要按照实际需要开发和发布文档。我们还学会了一种尽可能自动化地生成所需文档的方法。这听起来很神奇吧，其实流行的 ALM 工具更关注团队的工程任务，而不是那些官僚的做法，因此工作都是围绕着 ALM foundation 开展的。

ALM foundation 是中央集中式的平台，它使整个组织单位（例如公司、部门或商业单位）共享流程中的工作产品和知识，自动化地执行那些冗长的流程，比如自动化测试、构建和发布（乃至最终的部署）。如果你想要进一步深入研究 ALM foundation 的概念，可以从 David Chappell 采用通用 ALM foundation 下载这本白皮书。

（点击图片可放大查看）

图2：将Microsoft Team Foundation 服务器中保存的工作项生成文档的示例。

在我们的ALM@团队里，ALM foundation 主要由Microsoft Team Foundation Server 提供支撑。在这个平台上，支持图表类的工件，这些是可以被保管和维护的元素。要发布文档时，团队成员可以利用类似于TeamSpec 或Team4Word 的第三方工具以简易的模版去下载选中的工件。

虽然文档也很有用，但对于每个工件来说就只有一种可能的格式了。

1.2 纠正错误的观念：CMMI 和敏捷并不对立

这一章的目标是向大家解释其实事实上 CMMI 和敏捷是兼容的。

因为我们都喜欢 90 年代初的一款称为街头霸王的游戏，我们就用它来形象地说明我们的观点吧。很多人是这样来对比敏捷和 CMMI 开发模型的：

图 3：右边的春丽代表敏捷过程——甜美、轻快、灵巧多变。本田代表我们通常对 CMMI 开发模型的认识：厚重、缓慢、一身的肥肉。（© CAPCOM 有限公司）

后来我们开始执行 CMMI，努力使其适用于我们的敏捷团队，我们从中认识到其实它们像是这样的：

图 4：真实的情况是，敏捷和 CMMI 看上去其实像两位类似的街头霸王，只是穿着不同的衣服，有着不同的头发。（© CAPCOM 有限公司）

《 CMMI 或敏捷：为什么不能同时满足！》是 Hillel Glazer 等人于 2008 年发表的一篇很棒的文章，该文章深入探讨了这个主题。我们在之前的文章中曾经讨论过一旦大型组织决定转向 CMMI 所需面对的挑战，那就是敏捷团队如何应用 CMMI 模型。我们发现本质上敏捷和 CMMI 之间并不矛盾。在施耐德电气的 ALM@团队中，我们甚至发现它们彼此间相得益彰毫无违和感。

1.3 良好实践清单

最近几年中，我们在施耐德电气的 ALM@团队进行团队训练，帮他们提升 CMMI 成熟度。在 InfoQ 的文章《在大型组织的敏捷团队中推广 CMMI 实践》中详细描述了我们的经验。将这篇文章概括总结来讲就是，我们学到的最重要的一课是实践必须去适应团队，而不是让团队去适应实践。

（点击图片可放大查看）

图 5：针对需求开发的良好实践清单示例

如果你的责任是和团队一起达成 CMMI 的特殊目标，你就应该分析团队成员是如何完成他们每天的任务的。团队在这里努力为公司创造价值，所以已经实行了很多良好实践。你可以把这些实践增加到组织的良好实践清单。团队实行具有良好实践清单的 CMMI 时，通常会遇到以下几种不同的情况：

1. 他们发现团队早已采用了某些良好实践。
2. 他们发现团队的某些实践有助于 CMMI 目标的达成，所以可以把团队经验充实到良好实践清单中。
3. 团队可能缺少达成某个 CMMI 目标的实践。在这种情况下，团队成员将选择一个已有的实践，或者提出一个新的有助于达成该 CMMI 目标的实践。

2 需求开发和验证

让我们在本章一起探讨一下这个领域吧。

• 需求开发（RD）的目的是得出、分析和确定客户、产品和产品组件的需求。
• 验证（VER）的目的是确保工作产品能够满足需求。

有句话可以很好地概括验证（VER）与确认（VAL）之间的不同：验证证明的是正确地做了事，确认证明的是做了正确的事。RD、VER 和 VAL 是高耦合的（在某种程序上大多数 CMMI 过程域都是这样的）。我们会在后面的文章中介绍确认。

让我们把软件过程比作任何一种其他类型的工厂来进行探讨吧。一家香肠加工厂接收了很多的商品，比如肉类和调味料，以及硬纸板、塑料制品、化合物等等。这家工厂把这些商品加工成一盒盒的香肠，做好交付食品的准备。香肠加工厂就这样增加了肉类的价值。

在软件工厂中，本质上团队是在接收需求，指望对这些需求进行处理，交付最终产品，增加需求的价值。在需求开发中，我们努力地转化客户的输入，使其可以被团队用来开发软件，从而增加价值。

一些敏捷需求开发的良好实践是：

• 按照 Scaled Agile Framework 的说法，敏捷资产组合管理或程序资产组合管理（PPM）像“最高水平的信托（投资和回报）和内容权威”那样是可以定义的。换句话说，以投资组合的视角，管理人员决策在哪些方面投资，创作高层次的工件，我们把它称为史诗故事（业务或架构史诗故事）。
• 梳理待办事项是一项活动名称，在待办事项的废弃、恢复、分解时，以及待办事项条目的共性修改时会执行这项活动。随着时间的推移，某些待办事项条目可能失去了原有的商业价值，而新的待办事项会更加地重要。待办事项的条目可以由许多不同的方法来进行修改。我们可以把它们被分解成不同的待办事项条目，还可以修改它们，甚至一旦事件超时还可以取消它们。每个团队都要梳理自己的待办事项。其关键是要认识到待办事项是灵活可变的，团队不应该回避对它的修改。
• 产品待办事项开发是团队接收高层次工件并把它们转化为用户故事、场景等等的过程。这种游戏规划是敏捷环境的基础部分，通过它产出一组工件，然后开发团队就可以围绕这些工件开展工作了。

VER 的主要目标是确保最终产品会按照团队的理解予以交付。大家普遍都认为，VER 是工厂化软件测试（比如单元测试、集成测试等等）。虽然软件测试是软件验证过程的强点，但应该注意的是，这种验证方式并不适用于所有的产品工件。例如，我们评审一个已经完成的文档时（在大多数组织中这就算是彻底完成了），我们采用的验证方式非常类似于代码的同行评审。因此，当源自于某投资组合元素的产品待办项目（比如一个用户故事）完成时，这个产品待办项目也应该得到验证。

3 敏捷 CMMI 实践实例

3.1 良好实践：投资组合管理

就像你正在更加详细地描述功能一样，也可以把投资组合管理条目拆分成数个投资组合的层次。我们会发现拆解的层次取决于多种因素，比如解决方案的复杂度、团队规模和能力。关于如何管理敏捷投资组合，MSDN 有一篇很不错的文章，名字叫做《敏捷投资组合管理：使用TFS 支持跨多个团队的待办事项》。虽然文章特定于Team Foundation Server 的技术，但你仍然可以把它的结论和实践引申到其他的ALM 平台，比如SourceForge 或者CollabNet。

投资组合管理包括两个投资组合的层次：举措和特性

（点击图片可放大查看）

图6：按商业价值把举措进行分解归类

举措和特性通常用客户业务语言来描述。一个不成文的规定是，在待办事项中你用更加地深入、细致的表达方式。举措是概括的、总结的，比方说就像大家所熟知的电梯演讲一样。它概括地描述了解决方案应该满足干系人的什么需求。当举措被发掘了一段时间时，就能用来作为解决方案路线图的主要来源了。

（点击图片可放大查看）

图7：待办事项之前的举措示例。

举措分解为特性，它是以客户业务术语来描述的。在小型团队中，特性可能是唯一的投资组合工件。大型团队将使用举措把一组特性包装起来，以便特定的团队去执行它们。

投资组合管理有助于定义主要的交付物，如果你在项目计划时采用CMMI 过程域（比如项目计划（PP）和项目监控（PMC））中的实践，那么就可以用到它了。

最重要的是要与最终客户对投资组合达成共识。理想情况下，投资组合的举措和特性应该来源于客户，由产品经理以流畅持续的方式审批。一种可行的方式是，做一张表格通过传统的邮件方式与客户达成共识。

（点击图片可放大查看）

图8：ALM 平台工件导出一张传统的Excel 数据表。

最好按需来交付文档，以防文档化对每日的任务造成过重的冲击，我们只需要那些能够为最终产品增加价值的文档。因此，团队应该乐意既简单又快速地创建文档，这不会对他们的工作造成太大的影响。大多数ALM 平台都支持将工件导进文档模版中。

使用这条良好实践，我们就能够考虑RD 部分的覆盖了。它也是下面要讲的实践的基础，这个实践叫做：待办事项开发。

3.2 良好实践：待办事项开发

投资组合管理虽好，但还不够充分。最近流行把它作为需求开发的终点，但这不是敏捷，而是应付。我们需要从投资组合中以更为敏捷的表达方式去开发待办事项。

我们能够从特性中导出用户故事。在 ALM@时，为了同时支持正规的（例如，RUP 或 PMP）和敏捷的过程（比如，Scrum 或看板），我们把它们称之为业务用例。（不要把它与营销的业务案例相混淆。它仅仅是业务故事和用例的融合物。）

（点击图片可放大查看）

图9：来源于特性的用户故事

用户故事通常用以下模式来编写：“我，作为< 角色> 想要< 触发动作>，所以< 增加了价值>”。你如果想要了解更多关于编写用户故事的详细内容，可以扩展阅读Ronica Roth 的文章《编写好的用户故事》。

（点击图片可放大查看）

图10：用户故事示例

CMMI 开发模型的一个目标是需求应该是已确认的。作为用户故事的扩展，我们的 TFS 模版包括一个检查表，这个检查表可以用来决定该用户故事是不是可以发给开发人员了。它包括通过同行评审来确认需求。通常，敏捷用户会在此时设置验收标准和定义完成标准，但在我们选定的良好实践清单中，在下列的良好实践中我们将它划分为不同的工件。

3.3 良好实践：需求梳理（待办事项条目完善）

需求梳理是在敏捷社区广泛应用的一项实践。我们要关注需求的验证。梳理确保待办事项的条目是一致的，不是重复的，不是废弃的。在非敏捷环境中通常用检查表来执行这项工作，但在敏捷环境中也没理由不用检查表来检查产品待办事项的条目，用它可以提醒我们好的用户故事应该是什么样的。既然在正规生命周期中也要检查相同的工件，为什么不和敏捷实践一起使用相同的检查表呢？

（点击图片可放大查看）

图11：验证检查表。

一个用户故事包括一名同行去执行需求评审。当用户故事状态有变化时，TFS 支持用户去自动化地指派。当一个用户故事分配给评审人员，并将状态改为待评审时，文章就会自动地指派给该评审人员。

如今，大多数流行的ALM 平台都支持这种自动化：

（点击图片可放大查看）

图12：用户故事的提供者和评审人员

这项验证实践是需求管理域（REQM）和项目计划域（PP）的一部分，在后续文章中我们会对它们进行更加详细地探讨。此时的重点是，需求是要被验证的，它是我们的良好实践梳理的一部分。

3.4 良好实践：场景定义和实现

许多敏捷团队在达到用户故事这一层时就不再开发他们的待办事项了，而是直接开始实现，这需要定义验收条件和完成标准。然而，还有一种早期测试的方法，叫做 BDD。BDD 是行为驱动开发。它是一项强大的技术，非常地适合于 CMMI 开发模型。详细地解释 BDD 超出了本文的范畴，但让我们简单了解一下它是如何用于定义组件和接口的吧。让我们看一下用 Gherkin（比如 Cucumber 或 SpecFlow）编写的示例场景。

 
Feature: HoldingEnhancedVisibility 
      I, as ALMC User, want to filter Holding combos, so I could select only Holdings 
I am allowed to see 
 
@ScenarioTests 
@EnhancedVisibilityTests 
@XX4147CRBCShowHoldingInformation 
Scenario: An administrator wants to display all available holdings 
      Given an admin user who will display holdings 
      And a Regular User so at least one holding were created 
      When admin displays Holding 
      Then all available holding in ALMC are returned 
 
@ScenarioTests 
@EnhancedVisibilityTests 
@XX4147CRBCShowHoldingInformation 
Scenario: A Holding Manager can display only his Holding 
       Given a Regular User to create a Holding Structure 
       And a 'HoldingManager' for this Regular User 
       When manager displays Holding 
       Then only one holding is displayed 
       And holding for user and holding for manager is the same 

BDD 开发人员熟悉并能读懂特定的架构术语（SOA/DDD），能够和服务及实体一起识别出类似于“When”动作之类的组件。换句话说，这时没必要定义复杂的图表，它们太难以维护了。这也是一种定义 UI 动作的方式（比如，当参与者点击按钮时）。

在本例中，“Then”能够用来作为验收条件和完成的标准。

让我们再举一个其他的例子吧：

 
@ScenarioTests 
@EnhancedVisibilityTests 
@XX3216CRBCShowDependencyTasks 
Scenario: An administrator user displays combo to create a dependency among two tasks 
Given a registered user with administration permissions 
  And a Task with description "AdminTaskDependency" which is unique 
  And a set of Tasks non associated 
       | Description | 
       | AdminNotDependency3216A | 
       | AdminNotDependency3216B | 
  And a set of Tasks already associated 
       | Description | 
       | AdminDependency3216C | 
       | AdminDependency3216D | 
When combo is displayed for associating with pattern 'a' from previously created task 
Then all non associated task will be displayed 
       | Description | 
       | AdminNotDependency3216A | 
       | AdminNotDependency3216B | 
  And Master Task wont be among them 
  And Task with taskid to be associated with wont be among them  
{1}

BDD 易于被团队学习和采用，他们很欢迎这项技术。经过一些练习并具有适当的架构之后，是可以把参数（上例中粗体字）理解为接口参数的。BDD 是一种可以轻松定义组件、接口和参数的方式，换句话说，这也是一种定义产品需求的方式。

当需求已经插入到 ALM 平台，并历经了待办事项条目成熟完善，BDD 可以把测试和需求绑定在一起。

以下是待办事项的展现方式：

（点击图片可放大查看）

最终，像Jenkins 或Team Foundation Server 之类的持续集成平台就可以随着每一次源码的上传而去执行那些测试了。这应该需要定义一个控制配置环境。

3.5 良好实践总结

这四种良好实践在敏捷环境中相当普遍，通过执行这些实践只需要很少的工作量就可以覆盖一个过程域中的大多数特殊实践。

按照之前介绍过的良好实践去做，会达成以下域及其目标：

• 绿色 -> 完全实现
• 黄色 -> 部分实现（这种情况是因为我们未随着 CM 和 PI 一起执行代码同行评审）
• 黑色 -> 未实现，因为它应该由 CM 和 PI 来覆盖

需求开发特殊实践目标

• SG 1 开发客户需求

  • SP 1.1 引导需求
    • 投资组合管理
  • SP 1.2 把相关干系人的需要转化为客户需求、待办事项开发、场景定义和实现

• SG 2 开发产品需求

  • SP 2.1 确定产品和产品组件需求
    • 待办事项开发
    • 场景定义和实现
  • SP 2.2 指定产品组件需求
    • 场景定义和实现
  • SP 2.3 识别接口需求
    • 场景定义和实现

• SG 3 分析和验证需求

  • SP 3.1 确定运营理念和场景
    • 场景定义和实现
  • SP 3.2 确定功能性需求和质量属性
    • 场景定义和实现
  • SP 3.3 分析需求待办事项开发
    • 场景定义和实现
  • SP 3.4 分析需求以取得平衡
    • 待办事项开发
  • SP 3.5 确认需求
    • 需求成熟度评审

• 验证特殊实践目标

• SG 1 为验证做准备

  • SP 1.1 选择用来验证的工作产品
  • SP 1.2 建立验证环境
    • 不采用本组良好实践
  • SP 1.3 建立验证程序和准则
    • 不采用本组良好实践

• SG 2 执行同行评审

  • SP 2.1 为同行评审做准备
    • 通过待办事项条目成熟完善检查待审需求
  • SP 2.2 实施同行评审
    • 通过待办事项条目成熟完善检查待审需求
  • SP 2.3 分析同行评审数据
    • 通过待办事项条目成熟完善开展需求评审

• SG 3 验证选定的工作产品

  • SP 3.1 执行验证

    • 待办事项条目成熟度
    • 场景定义和实现

  • SP 3.2 分析验证结果

    • 在本组良好实践中未实现

关于作者

Nicolás Afonso Alonso现在是施耐德电气的软件开发技术领导人。他作为航天工业集成项目的质量保证团队领导人有多年的工作经验。加入施耐德电气之后，他主要关注适用于软件开发主导的 Team Foundation Server 活动和 ALM foundation 计划的过程工程学。

Victor Jara是施耐德电气的运维架构工程师。他的一部分职责是根据技术需求去实现特定的解决方案以完成配置管理与产品生命周期。

查看英文原文： Towards Agile CMMI Level 3: Requirement Development and Verification