AUP2敏捷统一过程之一：序言及降低过程的总体拥有成本

这是敏捷统一过程系列的第一篇。（前篇，之一序言，栏目总目录）

敏捷统一过程的全称是AUP（Agile Unified Process），不过为了能区别已经被提过一次的AUP（就是RUP），这里称之为AUP2。

这个系列会探讨如何在一家企业完整实施敏捷开发过程。在以往业界的讨论中，多数时候将话题集中在如何在一个小范围的团队中实施敏捷，比如Scrum本身的框架仅限于4～7人的团队如何做需求管理+计划管理+任务管理的；即使引入了Scrum of Scrums，其范围虽然扩大到几十人乃至上百人，但管理内容仍仅限于这三个环节。

而实际上一个企业实际要管理的内容很多，以一个产品研发企业为例，最早期的产品规划、用户群定义、团队招聘、绩效考核、产品运营、技术架构这些都是企业要考虑的问题，如果这些内容没有被照顾到，开发人员就可能会同时受到CMMI、Scrum、编程规范、团队模型……等不同的、互不相关的过程或技术的约束，写完这个文档再写那个文档，导致无所适从。

有些企业在实施敏捷开发后，由于很难和别的过程接口，很容易遇到下面这些问题：

1. 为什么我们使用了敏捷开发，但产品并没有成功？（与产品定位的接口，Nokiaer应该经常问这个问题）

2. 我们的队员有些不喜欢敏捷开发怎么办？（与团队模型的接口，比如不喜欢帮助别人，或者不喜欢让别人看代码）

3. 用户故事和用例我们应该写哪个？（与设计方法的接口，若已经实施了UML、面向对象、MVC、用户建模……等等一系列技术方法，问题会很尖锐）

4. 我们想同时使用Scrum和持续集成、自动化测试，他们之间有何关系？

5. 公司负责过程的质量部门在敏捷开发中扮演什么角色？

……

很多企业可能连问这些问题的机会都没有，因为他们发现“敏捷开发并没有想象中那么容易推广”，于是中途就放弃了。

AUP2敏捷统一过程尝试提供一个框架来思考这些问题，从而让软件开发人员不会感觉自己在很多管理方法、技术中分别工作，而是流畅地在一个统一的过程框架下工作。

AUP2的实践环节不是普适的，随着时间的变化也不是一成不变的。它只是提供了一个思路：在任何情况下，我们都应该统一地看待企业所采纳的过程、技术、组织架构……等内容，以期达到最低的拥有价值。

Process过程

Process这个词比较难解，在CMMI传入之前，国内基本上不知道这个词，国外也很少提到。对比下面这几个词汇，可以大致理解Process的含义。

Practice实践

大致指小规模的单一实践，比如需求跟踪矩阵、用例、序列图、用户故事、每日立会、自动化测试等。实践的规模大小不一，有些实践又是若干子实践的集合，比如持续集成。

Process过程

指若干实践的集合，这一集合能解决某些领域的某些范围的问题。

注意：以下的各种模型、方法论并不完全等同于过程，但这里抽取其呈现出来的过程侧面。

CMMI

CMMI中列出的内容大致相当于一家外包领域企业（尤其是为DOD提供外包开发的企业）所需的过程；它所涵盖的范围则是CMMI2级（需求管理、计划、跟踪……）、CMMI3级（需求开发，设计，测试……）等。

CMMI是迄今为止描述过程最完整的体系，它采用级别Level～过程域Process Area～实践Practice的方式来完整描述自己的体系；还有一种不太为人熟知的方法，就是先分为工程/管理/支持/组织级改进四个域（具体名字忘了），然后再过程域～实践三级。

从实用性的价值看，这种分类方法能让我们理解其他过程能管理多大的范围。

UML

UML本身不是一种过程，但在使用UML的时候会使用到CMMI中提到的需求开发、设计、编码三个过程域，还会用到用户建模、部署这两个CMMI没怎么提的内容。

UML对于理解何为“Unified”非常有好处：UML把需求、设计、编码三个环节联合起来思考，一个环节的输出，会变成下一个环节的输入，环环相扣，从而大大节省了开发工作量。

这个特点在后面的AUP2描述中还会提到。

RUP（Rational Unified Process）

RUP的范围包括（含英文缩写的是与CMMI重合的部分，虽然不完全重合）：

商业建模，需求（RD需求开发），分析与设计（TS设计与现实），实现（TS设计与实现，学名叫“technical solution技术解决方案”），测试（VER验证测试/VAL验收），部署（VAL验收），配置与变更管理（CM配置管理/ReqM需求管理），项目管理（PP项目计划/PMC项目跟踪），环境。

商业建模之所以在CMMI中不太重要，应该是因为CMMI应用与外包领域中的乙方，而这个过程则属于甲方的职责。

环境是RUP的一个重点内容之一，目的是向软件组织提供过程与工具的支撑。这正是Rational的业务所在。

RUP还潜移默化地定义了众多角色，虽然从敏捷开发的角度看，这略微有点不“跨职能”，但从实践的角度看，能让团队意识到存在某些复杂的工作需要有人承担。

Scrum/XP

Scrum的主体内容也可以称之为一个过程，应用于需求快速变化但又需要整体计划的企业（这个定义适应面很大，因此才大受欢迎）。按CMMI的名词定义，Scrum涵盖了ReqM需求管理、PP项目计划、PMC项目跟踪与监控这三个过程域。

XP较少提到过程的内容，更像是互相关联的一些实践的松散集合，而XP发展的趋势也是化整为零。按CMMI的名词定义，极限编程覆盖了RD需求开发、TS设计与实现、VER验证与测试。

敏捷开发过程的局限性

与其他过程相比，显然Scrum/XP的覆盖面相对少。

“这正是我们选择敏捷开发的原因，因为它比较轻量级。”或许有人会说。但这个回答的理解有问题：轻量级和覆盖面是两个概念。无论采用什么开发过程，商业建模、绩效考核、团队发展这些内容都是企业必然会考虑的，一个覆盖面过小且无法为自己不覆盖的部分提供支持的过程，尽管降低了局部的管理难度，却有可能反而会使公司的研发管理的总体成本变高。

典型的就是绩效管理，由于敏捷开发未提供绩效管理的模型，导致很多企业仍然采用传统的绩效管理方法（比如面向个人的绩效考核，数代码行，数缺陷数……），而这种管理方法又会反过来导致敏捷开发进行不下去。

在本人参与或了解的企业中，实施敏捷开发的主要阻力不是敏捷开发本身的实践有多难，而是如何将敏捷开发与现有的组织结构和制度相适应，或如何改造现有的结构和制度以适合敏捷开发。

因此应该在敏捷开发的语境下扩展那些周边的过程，以便为实施敏捷开发的大环境提供指导，以降低研发管理的总体成本。

其中一个有效的方法，就是建立以敏捷为指导思想的统一过程，以涵盖敏捷之外的组织结构与制度，并使之与敏捷开发相匹配。

下一篇文章，将会大致提出一个框架，对UP进行分析，并对AUP2潜在的要覆盖的范围进行描述。