问:这套理论起源于什么?您是否随时间在更新发展这套理论?

答:这是个好问题。我是个咨询师,曾在Ernst and Young 做了10 年软件开发。 这么多年里,做了许多次商业咨询或过程咨询,我注意到几乎每一个过程的实现都 失败——类似于大型软件实现或者软件 开发实施常有的失败。

我努力探究原因,发现了两件事:一 是,人们并不是用瀑布方法,而是用增量 的方式来学习的。采用和使用新流程也是 学习的过程,所以也是用增量的方法来学 习。人们学习如何做事情——人们学习是 因为这有利于他们。想法改变做事方式, 所以想要有一个有效的过程改进就必须改 变他们的企业文化和思维习惯。近十年来,我一直思考:“我们本末倒置了,所以我们应把过程改进转回学习经 验的模式”。我得出的结论是,用迭代和增 量的方式去做;

二是,作为一个软件开发者,我意识到, 过程专家们在这个行业讨论六西格玛、 CMMI、过程改进和 ISO 使用——所有这 些都是以过程为中心语言,我意识到,除非 开始与软件开发人员和项目经理谈论他们 理解的事情,类似于面向对象的封装、多 态性和所有与软件开发相关的事情,否则 他们难以理解我们谈论的内容。

敏捷 CMMI 方法不仅需要第一个增 量和迭代的概念设计和部署,也包含了第 二个概念——通过提供给开发人员一切 他们理解和使用 UML 图表和数据流图的 一种语言,都是他们比较习惯的方式,而不是试图推他们进入到他们不想进入的流 程的世界。

我的结论是,过程对于公司不应是额 外的负担,并非让人们做一件额外的事情, 过程的另一个名词是工程。作为一个以验 证过程为核心的行业, 在过去的几十年里, 我们没有将核心概念解释清楚,其中一部 分原因就是我们的工具集和方法论有问题。

我们的敏捷 CMMI 方法帮助客户解 决了上述两个问题:将客户过程改进变回学习经验;将方法论用他们熟知的语言来 解释。我们有多名客户全心全意接受它, 有人甚至开始在其他部分业务使用它,在 它支持下我们真正成功了。


评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。