公司实施CMM的一些困惑

这几天，公司准备评CMM级别了，请了专家过来做咨询，一轮差距分析过后，就开始培训理论。围绕这一主题，开始了一系列动作：项目经理培训(内部)，英语培训(KaiEn),人日统计(和money直接挂钩的哦)等等。

先讲最恼火的一件事情是：20个人日的软件维护也作为一个项目来开展，1个QA,1个测试员，我是解决问题的技术员吧。已经3天了，我今天才看了一眼代码。其他时间做什么呢？做文档，开会，分配人日，和技术支持沟通。明天技术支持才会把客户那里的环境在开发内部重现出来，而明天我还要去参加CMM学习班。我觉得这样下去，实在看不到一点点光明。

最近一系列变革，加上我以前的工作经历和感受，促使我不得不自己翻一下项目开发方面的书，以前我是不关注这方面的。我发现几种不同的呼声(希望谈了之后,大家不要鄙视)：

1，CMM 的范围最大，包括对公司的改进，对个人的改进，对各个项目的积累等等。重点关注过程改进，就是说，你能在那些级别里，对各个关键过程域都实行的很好的话，你的项目风险就回很小，成功率就很大。通俗一点，就是说，过程决定一切。

2，人件，比较关注人的一方面，注重人的重要性，告诉项目经理，你如何把人的潜力发掘出来，创建什么样的团队，什么样的环境，什么样的团体合作等等，显然，这代表着一种思想就是，人员和团队发挥了他们的积极主动性，发挥出他们的真正水平，就能推动团队和公司的生产力，这样项目的成功性就很大。人件这本书，写的很幽默，而且多看法是很有独特见解的，但大多数东西好象太理想化了。

3，敏捷开发，这个范围就比较小了，针对项目来说的，如何成功实现一个系统，为客户创造他们的价值。敏捷思想就很务实，所有的工作目标就是实现所要的系统。我目前最想在公司实现的就是：TDD和自动化测试。我们公司内部现在的开发模式基本是，瀑布+一点迭代思想，测试模式，基本是手工去点，个人觉得很粗糙。尤其测试，老是找需求人员和设计人员的麻烦，因为他们现在测试的依据就是--需求，其他文挡一概不看，他们不找需求分析员和系统设计员才怪，个人觉得这种纯粹在瞎扯。当然也不能全部否定，经过折腾之后，总归能发现一些bug的，还会有一份测试报告。我在开发过程中，最头疼的是，客户永远有变更不完的需求，结果虽然大部分已经满足了，结果导致：1，项目成本增加；2，项目体系和代码臃肿不堪，后面就会出现维护上的各种难题。

我目前的角色是：系统分析员。本来和我一样的还有两个，但他们这半年，都忍受不了了，所以都走掉了。我做的工作是：调研(如果项目有需求分析员的话，我就不去调研客户了)，写文档，找解决方案(前面有个项目，就把SpringSide和AppFuse融合了一下，搞了一个架子，大家开发)，培训新程序员(无论什么时候，应届毕业生总是要占到一半)，分配人日(公司的一个软件用的让我吐血了，非常不灵活，涉及到各人的经济利益，所以不的不忍着)，解决技术难题(尤其新程序员和懒程序员那里问题最多)，参加其他项目的评审会，有时可户那里出了什么问题，项目经理也会找过来。

几乎每天都忙忙碌碌，而且有时项目紧的时候，还狂加班，但总是充满挫折感，技术不成，业务不就，英语也比较头疼，所以严重信心不足。到底是这个世界变化太快？还是我的适应能力退化了呢？

回到重点,项目到底应该怎么做呢？

有共鸣的同行们, 经历,想法, 随便谈

你在敏捷开发的大本营发CMM的牢骚，
你以为有人会同情你么？
CMM在这里早就没有什么可讨论的了，
死路一条而已，你还是早点换个公司吧。

CMM也不是一无是处，学习其好的一方面。
我很佩服你的忍耐力...不是贬义，我在面试的时候就知道我缺这个，技术再强，人家也不一定用你，担心你会跑掉。

这都是大公司搞出来的东西，本来就复杂无比。举一个不恰当的例子，就像ERP，实施成功的例子很少，“上ERP找死，不上ERP等死”。

但是把这些理论性的东西研究一遍，还是会很有收获的。只是不要奉为教条就好。

“技术再强，人家也不一定用你，担心你会跑掉”楼上的说得有道理。很多时候招聘人员是需要综合考虑的，不一定是水平最高的，而是能胜任工作并且稳定地干下去的。换一个人的成本可是很高的。

水平越高耐力越重要
CMM要的不是一个强人。。。。
要的一群水平很平常的人。。。
明白这点就明白为什么会有这样哪样的文档之类的东西

主要还是要让程序员把自己写的东西搞清楚
PS：很多程序员不明白自己写的程序是干什么的。。。

一点也不错。理论性的东西其实还是很有意义的，但是条件是有一定的实践经验，这样看见这些理论的时候，就容易联系到实际情况。
最讨厌那种项目经理，一点实际概念没有，说起项目来满嘴的任务时间资源，设计一个烂烂的东西出来，工时数算的差一倍，然后号召大家加班熬夜。

我们这里，QA的测试用例是根据需求来写的，需求要变的话，测试也得跟着变，尽管会抱怨需求人员的麻烦，但客户最大嘛

管理项目很重要的一点是业务的参与，公司自己要提出清晰的业务目标，并且要有核心的团队主导和参与实施。这里面很关键的就是核心团队，他们要有相当的主导权，比如他们能否明确的告诉顾问，在这个环节上我想达到什么样的目标，如果你这样做我的人力、成本吃不消，那么你必须跟我们的业务骨干一起讨论出一个方案，让我达成管理和开发的平衡。

顾问能做的是一些现状分析和流程诊断，应该相信他们的职业素质，但是改善策略和步骤，这些工作不能完全靠顾问，这点我想大家在做项目的时候能够感受到，把自己当做项目里面的业务人员，CMM顾问当做项目开发实施人员，换个位置思考一下就明白。

“上ERP找死，不上ERP等死”应该这样说“不知道要解决什么问题的上ERP找死”，没有目标的上CMM也是如此。

如果公司的现状是上了CMM，与其发牢骚，还不如好好找出问题，跟公司一起改善流程。觉得自己是其中的一个螺丝钉，没有价值体现，这跟上不上CMM没有关系，每个人都是公司的工具，就看你自己怎么看了。

不同的测试，依据的东西是不一样的。用黑盒法的系统功能测试，肯定是以需求为依据的。XP要求由现场客户写Acceptance Test，现场客户是不可能去看分析和设计文档的。这种测试，只有要往数据库里填测试数据的时候才需要看设计文档。

楼主的抱怨是不是表达得有些不清楚？

以上各位分析的各有各的道理，我比较赞同：

现在能做的也就是两个字--顶住.