CMM已经落伍了，敏捷才是王道

woza

首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于CMM的那些文档感觉有些浪费。

看看那些文档，看看那些流程。想想那些伟大的软件作品，哪个是用CMM开发出来的？

作为测试工程师，程序员的你在CMM流程管理下，是不是觉得不爽？你喜欢写那一堆又一堆的文档吗？你喜欢看那一堆又一堆文档吗？你喜欢你的老板整天指手画脚其实完全没有帮助？你喜欢看到需求不停变更但是计划永远不变，结果就是压缩测试时间，或者发布延期？答案当然是否定的，没有人喜欢。

软件开发是一个创造的过程。工程师是人不是机器。符合人类天性的开发模式才是好的开发模式。

软件开发的核心问题:沟通障碍，需求变化，产品质量等等。在CMM模式中都没有被很好的解决。敏捷提供了一种全新的思维方式。敏捷的核心思想就是以人为本，持续改进。

回帖的童鞋们似乎对于文档的问题很感兴趣，那我就说说敏捷对于文档的态度。
首先，敏捷并不是没有文档。敏捷只是省略掉了不必要的文档。
其次，一个商业软件发布时应该有的文档，敏捷开发全部都有。比如说，release note, Help等等。

文档的作用是用来沟通，交流和传递信息。但是文字本身并不是一个完美的载体。语言永远比文字更能够清晰的表达思想。所以在敏捷开发中，类似于测试计划，方案，任务分配，简报之类的都可以省略。我能够花三分钟说明白的事情，为什么要花十分钟去写，而且还要接收者再花十分钟去阅读。这不是白白浪费了十七分钟。

当你加入一个新团队的时候，你希望看到一大堆产品说明，还是喜欢有个人手把手的指导你？我想多数人喜欢后者吧。

敏捷团队中，所有的知识都是共享的。所以完全不需要担心，由于某个成员的缺失而造成知识断层。同样的，由于这种担忧而产生的文档也可以省略掉。顺便提一句，虽然我不知道为什么，但是敏捷团队的人员流动率非常低。我公司里面的测试人员在实施敏捷之后的若干年里面，一个离职的都没有。

[ 本帖最后由 woza 于 2009-6-24 12:24 编辑 ]

愚人

不是所有行业都适合敏捷开发的吧~~~

对于一些做产品的公司，CMMI更有用些！！！

liufeng

你可以说敏捷才是王道，但说CMM已经落伍了有点不合适！
赞同2楼所说

woza

做产品的公司当然可以用敏捷。你说丰田，诺基亚，IBM，Google，暴雪是不是做产品的？
敏捷是一种思维方式，几乎所有类型的公司都可以用敏捷。这个和是不是软件公司，是不是做产品的一点关系没有。
CMM自有它可取之处。我不否认使用CMM也能做出成功的软件。但是，达到同样的目的，CMM花费的代价比敏捷要高出许多倍。中国的软件企业本来底子就薄，敏捷比CMM更加适合现状。

drdrtracy

我觉得适合才是王道吧,不管是CMM还是敏捷,用适合的,用好了才是王道

chengxq

这个才是正解，我遇到一个公司，什么叫敏捷，敏捷的定义就是非CMMI，就是CMMI要求的我都不做了，
既然是敏捷，那就是快，什么都没有了，他们的理解就是什么管理文档都不要做，只根据进度表走进度
很敏捷！！！

woza

楼上讲的那个公司有些步入歧途了。

敏捷并不是完全不要文档。敏捷也不是一味的求快。如果做出来的产品质量有问题，速度再快也没有用。

而且敏捷和CMM并不是完全对立的。CMM设立这么多文档的目的，在于避免由于沟通障碍而造成的损失。敏捷的思路是如果这些文档很好的解决了沟通问题，那就继续写文档；如果没有解决沟通问题，或者文档本身就造成了沟通障碍，那自然就要寻找更好的解决方案。

不要看到敏捷，就以为它和文档是对立关系。敏捷关注的是整个项目过程中，所有造成浪费的环节。发现浪费，就要处理；发现有节约的好方法，就要做到极致。不停的反思和总结。

静月思

CMM是个啥子？::xsjsn:::

mx2001

敏捷是以人为本不错，但是整个过程控制，对于一个项目经理来说，测试经理，以及开发经理是考验，做的不好，反倒更耗费精力。。。不要人云亦云。。。国内一直都是新技术的试验场，其实在国外，没有像我们这样天天尝鲜，风险控制也是很重要的。。。

zhongmg108

敏捷、XP、RUP、CMM/CMMI等，都不是王道，能够高效地解决组织的问题，适合公司的过程才是最重要的。如果项目的规模很小、功能也很简单，团队规模也不大而且比较稳定，而且是一锤子买卖，那就可以能省的文档都省掉。如果公司想获得可持续发展的能力，想赢得客户的长期信赖，一些文档还很有必要的。如果只是站到项目经理或成员自身角度来看，一些文档是会消耗成本而不给项目带来效益的，但是如果站在整个组织或公司的长期发展角度看，一些过程和管理文档必不可少。这里还有一个整体与局部的关系问题，公司应该建立整体与局部利益的一致性机制，这样项目组就会少一些抱怨。

愚人

诺基亚是 网络部门在搞敏捷吧，后来效益不好跟效益不好西门子的网络部门合并了

[ 本帖最后由 愚人 于 2009-6-22 19:59 编辑 ]

愚人

同意10楼的说法

nitint520

敏捷迭代开发并不代表就放弃文档
CMMI并不代表要把项目都框死在文档里面
其实我们并不需要关注 CMMI  PK 敏捷迭代的结果  这两个不是PK关系  
重要的是 如何在两者之间找到一个平衡点，怎样才适合自己的项目团队。

elong602

适合自己的就是最好的！

woza

敏捷和CMMI其实是思考问题的两种不同方式。和文档不文档没什么关系。

CMMI是管理者喜欢的模式。管理者通过流程管理，来确保开发过程的可控性。它试图避免由于人的因素造成任何不可控的事件发生。

敏捷则是以人为核心。是工程师喜欢的模式。敏捷试图以团队的进步来带动整个组织的进步。敏捷认为再好的规范也需要人去执行。与其关注规范，不如关注人。但是管理者未必喜欢这种想法。因为这意味着决定权的下放。

luoyear

严重怀疑楼主是否懂敏捷或实践过敏捷？
敏捷并未就是否需要文档，及一些具体的工程实践方面提出建设性的意见。
敏捷的意义在于通过高度透明的研发过程，充分考虑人性的因素，高度的可视性使得团队效能被最大程度调动。
当然，敏捷也提出了诸如持续集成，测试驱动等实践，但这屈指可数的实践完全可以被融入CMMI相应的过程域中。

[ 本帖最后由 luoyear 于 2009-6-23 21:57 编辑 ]

woza

敏捷能否被融入CMM，我个人表示怀疑。

CMM能够让工程师自己制定开发计划吗？CMM能够允许每个团队使用不同的流程，不同的标准吗？CMM能够允许工程师们自我管理吗？CMM能够取消那些评审活动吗？

愚人

据说某些专家开始研究敏捷和CMMI的融合了，能不能成功就不知道了
可以google一下

liuchunyanli

本人觉得“敏捷”在国内不太靠谱。“敏捷”强调以人为本，而国内软件企业人员流动性很强，国内企业只看重效益，不太注重人文和质量。
不能以偏盖全，至少大部分企业是不重视的。
玩一些概念，本人觉得挺没意思的，主要是到底能不能真正地去做，能不能将事业做好。概念只有理论参考意义，不是要做事情的全部。

对了，我们公司给我们做“敏捷”培训的同事已经离职了。

[ 本帖最后由 liuchunyanli 于 2009-6-24 15:54 编辑 ]

bensen

像你说的那种高忠诚度的员工又有几个呢？！CMMI没用的话人家老外也不会花那么长时间、那么多精力去研究了。凡事都有利弊，不可一刀切嘛。