过程与方法论的关系

一个过程的定义——一个工作比较复杂，我们将它分解为一系列活动，给出每个活动的时机、输入、角色、输出，并将活动串起来，最终达到工作的目标。

在上述的定义中，可以看到任何带有目的性的一系列活动的集合都可以称之为过程，由于一个复杂过程中的活动常常还可以继续分解成更多的子活动的集合，那么这通常被称之为子过程。

另外，在上面的定义里，还有一个容易被忽视的地方：“将活动串起来”。这里隐含着一个问题——活动应该如何被串起来？大家都有这样的体会，按照不同的顺序执行的活动，有着可能完全不同的效果。因此，好的过程应该是一系列互相协调一致的、能产出更好结果的活动的集合。由此可见，一个软件组织所尽力追求的“流程”实际上一个组织所寻找和认定的对自身而言好的过程，这显然不仅仅是管理的需要，对每一位软件开发人员而言都是同样的重要。但是，“好的过程”究竟是怎样的？对这一问题的理解是造成开发人员和管理人员之间对“流程”看法的冲突所在，一个致力于发展的软件公司必然会不断的努力寻找“好的过程”，而这正是“持续改进”的意义所在。

下面是经典过程定义中的三要素：活动、产品、角色，这里就不再多作解释了：

方法论则是研究方法的理论，或者说是方法的系统论。它的任务是研究和批评具体的方法，是将某一领域分散的各种具体方法组织起来并给予理论上的说明。

可见，方法论包含了两个方面：

1、研究和批评具体的方法

2、研究如何将某一领域的各种具体方法组织和协调起来，并给出基本的原理

现在来看看过程和方法论之间到底是什么关系？

一个软件组织为了提高客户满意度、提高生产率必定会不断的追寻一个“好的过程”。在这个过程里包含了一系列协调一致的活动，每个活动都有自己一系列的特定的实现技术和工具（见下面的图示），那么这些技术应该怎样如何选定的呢？——这就是方法论所研究的对象了。方法论除了选定某个特定活动的特定技术外，更要的是如何将这些零散、具体的技术组织起来，让它们协调一致的共同发挥更大的作用。从这里可以看出，对一个软件组织来说，割裂的研究单个实现技术是没有意义的，必须将一系列的活动以及它们的可选技术结合起来进行研究。大多数的软件组织以及开发人员本身并没有这么多的时间来系统的研究各种方法以及它们之间的关系，这项艰巨的任务显然落在了那些方法论学者的身上，而对于软件组织以及开发人员，大多数的时候，只需要实行拿来主义，然后再在这一套方法论的指导思想（基本原理）上，制定自己的开发过程以及基于自己的实践不断的优化和改进某项活动的具体特定技术，形成自己的开发过程。可见，在软件组织没有自己过程的初期，只需要关注那些方法论研究的结果，如：RUP、敏捷，而在后期，则必须基于对选定方法论原理的深刻理解上以及自身的实践基础上，改进和优化自己的过程，也许有一天当对方法论的基本原理都进行了深刻的改变，便形成了自己的独特方法论。

从上面的论述里看，似乎只要方法论就足够了，还要自己定义的过程干什么？其实，方法论更多的关注选定技术的方法和基本原理，它所生成的结果往往是一系列的方法集合以及它们之间的联系顺序，但是，它对每个方法的输入、输出、工作产品、模板等往往没有非常明晰的定义，而缺少这些会使人们在执行时不知所措，尤其是在没有理解方法论背后本身的原理时。

可以这样做一个粗略的总结：

1、方法论是“好的过程”背后的基础

2、过程则是方法论在具体组织的特化和落实

3、对一个组织来说，脱离方法论背后的基本原理孤立的研究单个活动的技术，在初期意义不大。

4、在没有理解方法论的基本原理和目标时，争论方法论本身没有意义，尤其是仅对不同方法论中的单个技术进行比较、争论时。

咨询顾问的咨询费凭什么那么高？他们到底对我们做了什么？理解了过程和方法论的关系后，再来看这个问题就一目了然。咨询顾问卖的核心根本就是某一方法论的结果，当然方法论并不能直接对组织产生作用，于是大家就在顾问的帮助下，建立自己的初始过程，包括各种活动的输入、输出、工作产品、角色、文档模板等等。当然这些具体的活顾问是不会做的，顾问就象是服装设计师，而真正把衣服做出来的还是软件组织自己，顾问只是因为理解方法论而基于此对这些具体活动提供指导和评估。难怪，一旦组织的基本过程建设起来后，常有人看着自己输出的一大堆流程定义、文档模板、工具、指导书等等发出这样的感叹：“这不都是我们自己做的，还花了那么多钱？”

在我看来，CMM还算不上方法论，至少它不是严格意义上的方法论，因为它缺少了方法论中一个重要的因素：“将各种具体方法协调和组织起来”。我想这也应该是各种软件组织直接推行CMM时，造成各式各样困惑的原因——缺少了已方法论为基础的过程。当然这不是说CMM没有用，只是说它没办法直接拿来用。其实，这也和CMM的起缘有莫大的关系，因为CMM的诞生直接来源于美国国防部对软件组织评估的需要，它必须回答谁是好的、谁是不够好的问题。这么难的问题也真亏了SEI的大拿们，将这个问题变换了描述，改成了这样“什么样的软件组织是好的”。这个问题和“什么是人”一样，无法直接给出定义，于是改道而行，SEI采用了回答“什么是人”一样方式回答了这个问题，它通过尽量描述一个好的软件组织都有什么样的特征、都做了哪些活动来给出了能力成熟的的模型。也难怪有人将其称之为“字典”。其实这是一种比较取巧的思路，也正是因为这样CMM具有一定的普始性，拿它去和RUP、敏捷过程进行比较，就象拿大象和非洲大象进行比较一样是不恰当的。因为只要RUP或者敏捷过程具备了CMM描述的特征，它自然就是符合CMM的。

为什么？这都是因为当初没有弄清楚CMM所惹的祸啊！缺少方法论支撑的过程很难说出它是好是坏，即使它表面上看起来都满足了CMM的特征！当然，还有另外一种情况，就是对大型的软件企业来说，过程是要全公司范围内遵守的，为了满足各式的项目要求，必须提高过程的抽象程度，减少对具体活动如何实现的说明。当然这样的后果，和CMM一样，提高了普始性，却让大家总感觉缺少了什么。对于这样的软件企业，真正要做好，其下的各个部门必须有自己的方法论（技术）去支撑公司的过程，权当是一个特化的过程吧。缺少了这个，是很难把过程真正定义好的。