简史

如果你过去 15 年生活在另外一个行星，我们为你提供的过程改进方法演进的编年史如
下：

  • 1984 年：美国国防部(DoD)在卡内基·梅隆大学成立了软件工程研究所(SEI)，授权它为软件工程制定优秀标准。
  • 1987 年：SEI 发布评估“软件成熟度”的第一个五种等级标准。
  • 1988 年：1988 年 3 月 IEEE Software 杂志上了发表的瓦特·汉弗莱（Watt Humphrey）的有帮助性的论文《描述软件过程的特征：一个成熟度的框架》。随后进行了第一次软件评估并将结果予以公布，使公众第一次了解能力成熟度模型 SM（CMM）。
  • 1989 年：过程小组和第一批过程支撑的公司形成。发布了汉弗莱的《管理软件过程》（Managing the Software Process）。
  • 20 世纪 90 年代：CMM 在美国国防部内不断推广，甚至超出美国国防部范围。如果说不是在绝大多数大型软件公司里，那也是在其中的许多家公司建立了 CMM 目
    标等级。

过程改进计划的谬论

要理解用制度的方法来达到过程改进这一问题，当过程等级正在提升时，你得将目光从做完的项目上移开，而将注意力集中到还未做完的项目上。

这是有关利润的问题，傻瓜

证明 CMM 合理的最强有力理由是因为它提高了质量和生产力而减少了风险：

SEI 的能力成熟度模型 -- 搜索查看

一个新的室内/室外世界纪录

  提高水平意味着风险会增加。你越熟练，应对的风险就越多。你会执迷于不去这样做。

  你越改进你着手工作的方式，工作就会越难。发生这种情况基于两个原因：第一个原因，改进我们的方法，我们典型地把相当平凡的工作交给机器（例如，软件现在产生了结构化查
询语言基本指令；人们过去常常做那种工作），或从整个项目中移出来（例如，电子制表软件的发明把一大堆工作从软件开发组剥离到业务领域）。剩余的工作更加是智力密集的；做
这种工作需要更多的技能和经验。如果我们要在过程改进方面取得真正的进步，我们需要更有能力和更有经验的人去做工作。

  第二个原因是改进了的方法允许你接受更困难的挑战。而且你会接受它们……除非你已
经被转黑暗面了。

过程改进：它正把我们转向黑暗面吗？

  每个地方的公司都有攀登更 CMM 等级的压力。明天他们会执著地追求现行等级向更高级别的跃进，或别的什么。这就是黑暗面，因为它会诱导低风险的一味保平安的行为，所以这些项目是低利润的。

过程改进的最大矛盾

如果你已经是一个达到 CMM 二级标准的公司或者更高一级的公司，请记住这句话：

最值得做的项目是那些在程序规模上可能使你整整下降一个等级的项目。

或许这些是唯一一些你有能力去做的项目。