CMMI on line

国内有这样的现象，搞过程改进的人项目经验不多，却制定了一套复杂的过程让项目经理们执行。而项目经理们本来对CMMI有美好的愿望的，但几经折腾下已经对CMMI失去信心，有人把CMMI与重型项目管理等同，有人认为CMMI就是增加了项目的负担和成本。如果持续这样发展下去，SEI肯定吐血了！应用CMMI原理的主角是工程类人员，是项目经理们，而中国长期对过程改进不合适的做法，造就了对CMMI的各种误解！

我从事了多年的软件开发、项目管理与过程改进工作，在我看来，CMMI所包含的项目管理知识非常博大精深，而且要比PMBOK里面的内容更加升入和全面。很多项目管理的理论包括PMP的考试，对项目管理的思考层次，大部分停留在项目本身，而CMMI把项目管理上升到可持续改进并且在组织内共享成果的层次，更厉害的层次会达到用六西格玛来管理项目。

本网站列举了大量的CMMI知识，同时也会和大家一起就项目管理的问题进行讨论，大家会发现项目管理的很多理论其实在CMMI中基本上都可以找得到，把CMMI的知识掌握好，将对大家提高项目管理水平带来质的提高！

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

由于项目管理、软件工程，都是实践性非常强的学科。每个项目都是独特的,每个项目组对于项目管理实践都有自已的理解和看法,甚至说每个行业的项目管理特色都不同,因此很多时候进行过程改进或者管理改进,想找到一个包治百病的神药是没有的．但是一些管理的基本原则而构成的模型来指导人们结合自已的实际情况进行管理改进却是必须的，ＣＭＭＩ就是这样一个模型，它是结合软件工程的特色而建立起的模型．


以下对比ＣＭＭＩ与ＰＭＢＯＫ的异同

1、 CMMI模型是综合了项目管理与软件工程的模型。

PMI的PMBOK是当前最具影响力的项目管理模型和指南，得到了广泛的应用。但PMBOK是一个通用的模型指南，并未吸纳特定行业的项目管理特点。

软件项目管理有其重要特性，其特性就是在：软件项目可以用标准的项目管理要素如进度、质量、成本来管理，同时，软件项目也是一系列软件工程工作的集合：需求分析、软件设计、质量控制、软件测试，等等。

因此，对于软件项目管理来说，标准项目管理与软件工程，是一个硬币的两面，是必须紧密结合才能够取得成效的。

而通用项目管理理论，是不包含软件工程，如需求管理、配置管理、测试管理的内容的。因此，在将项目管理过程与配置、测试管理的结合上，遇到盲点。

而CMMI是针对软件项目过程的模型，在CMMI中，既包含了项目管理的内容，又包含了软件工程内容，同时还包括组织能力等很多的方面，并且最重要的是，CMMI将这几个部分融合成一个体系，从而在软件行业获得了巨大的成功。

CMMI模型包括4个“过程组”。第一个是工程，包括需求管理、需求开发等。第二个是项目管理，包括项目监督与控制、项目计划。第三个是过程管理，定义了很多组织级的过程（在PMI最新的PMBOK里面，吸收了这个思想，成为“组织过程资产”）。第四个是支持过程，包括配置管理、质量保证、度量分析等。

谢谢你的发表，让我学到了不少东西！

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

刚通过了PMP认证，自己也把PMBOK2004认真学了两遍，感觉与2000版相比，PMI其实也在自我改进。
新版的PMBOK里面提到了PMO，并着重强调了组织过程资产的作用以及事业环境因素的依赖。
在新版中PMI只是提出了PMO的基本职责，但未对各职责进行展开说明，估计在下一版会对这块内容进行细化。
PMI在2004版可以说是非常推崇组织过程资产，而且强调项目收尾是在每个阶段都要进行的活动，经验教训和历史数据一定要归档成组织过程资产。项目估算、计划等工作都推荐先在组织过程资产里查找。
这些方面反应出PMI已经从单个项目的维度去思考项目管理改进到从项目集群管理的维度去描述项目管理。看来PMI也在持续改进啊，呵呵。

我也正在从事品质管理的工作，研究和学习CMMI V1.2中，还无法具体将两者进行对比。这方面还需要跟zhangcb多多请教。

恭喜你通过了PMP认证！也很高兴PMI已经推崇组织过程资产了，正在持续改进中！

PMBOK是项目经理的经典宝典，CMMI列出的只是标准，实践指导方面比较弱，PMBOK和CMMI都精通将会非常了不起，有空请你多多发表一些项目管理的方面心得，这样将让我们将受益非浅。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

确实是这样，我们公司项目经理一看到那些文档，就说很繁琐，还有项目计划的制定，感觉好乱，因为在他们看来只要做好自己的事情就OK了，至于制定这些文档，感觉没有多大意义。现在即使做了相应的文档，也只是为了应付，对于这种情况，QA该怎么来监控呢？应该怎么向项目经理及项目组成员来说明CMMI过程改进对软件开发的作用呢？

他们觉得公司弄这么一大堆的文档及流程就是在加重他们的负担，他们只管好编程就好。

---

爱拼才会赢！

写文档的目的是什么？是为了写文档？还是让项目做得更好？
如果文档少写一些，项目也能成功，那么还需要写很多文档吗？

当然不排除部分员工素质没有这么高，就喜欢编码不写任何文档，但我想作为公司的项目经理，一定是知道什么文档是需要写并且这些文档是有用的，你可以和项目经理们商量一下应该写什么文档，怎样写，然后你帮助项目经理落实。目前你们公司的过程，可能规定了很多项目经理认为不合适的东西，这可能是他们不愿意执行的原因。

另外，要问问公司高层领导，项目组有哪些文档是必须写的，按重要顺序排列，先抓前面几位的文档，不需要一开始什么都抓，项目组没有这样的能力一下子做到。按照我们公司的经验，以下内容公司高层是需要项目组提供的：
1.项目预算。
2.项目计划。
3.项目周报。

CMMI过程改进是为项目服务的，过程是来自实践的，不是“空降”的，很可能你们的过程不是让大家制定的，甚至是从某处“抄”来的，所以大家不接受。合适的做法还是一步一步来，一开始不要大而全，要让大家参与过程的制定，让他们总结工作中的问题，并改进目前的做法，将这些改进的做法，制定为过程。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx