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

stjd139

各有各的好处吧。。。

yiding_he

1、“cmmi 同 cmm 一样承诺给人一个美好的前景，但是任何模式都有一个使用的方式方法和约束，cmmi 却并不告诉你有这个约束，而且他们却往往给你一个他们根本就不会被约束的假象。”

2、Tom DeMarco 对 CMM 的评价（不认识没关系，就看看他说的有没有道理）：
http://www.javaeye.com/topic/971

3、

原帖由 kf_rainbow 于 2009-8-6 14:37 发表
光敏捷,什么知识都留不下来,凭什么说队伍就一定稳定??

什么是知识？知识分为两种。一种是技术知识，就是这个人的本事；另一种是业务知识，就是当前项目中的需求、设计等等。技术知识是随着人走的，人走了，什么技术也留不下来；而业务知识是可以留下来的。业务知识保证了这个项目当中业务概念的可延续性。当然，业务知识不能保证产品质量，能够保证产品质量的个人能力是留不下来的。这就是为什么有的人薪水高有的人薪水低。

woza

原帖由 yiding_he 于 2009-8-8 18:08 发表
1、“cmmi 同 cmm 一样承诺给人一个美好的前景，但是任何模式都有一个使用的方式方法和约束，cmmi 却并不告诉你有这个约束，而且他们却往往给你一个他们根本就不会被约束的假象。”

2、Tom DeMarco 对 CMM 的评价 ...

由于缺乏应对变化的勇气，所以试图寻找一种以不变应万变的方法。这个就是CMM/CMMI的本质。敏捷则以莫大的勇气去拥抱变化，并积极去适应变化，从不以暂时的成功而停止探索的脚步。

那些外包企业之所以使用CMM，是因为他们根本不是在做软件开发。按照已有的设计去写代码，充其量是个体力活。这种事情做得越多，创造力就越少。本来中国在软件这个纯粹依靠创造力的产业上面，应该是有优势的。因为受教育的人口越多，产生新思维的概率就越大。要是推广外包产业，终有一天要沦为人家的劳动力批发市场。和先进的软件思想技术的差距只会越拉越大。

ThinkInChaos

看了大家的评论，发表一下粗浅认识：大多数了解CMMI的人不了解Agile，了解Agile的人不了解CMMI，我们应该静下来试着去了解对方，取长补短。做了2年的敏捷项目实践后，现在在CMMI5级的公司工作。我认为敏捷和CMMI的关系是：

敏捷为体，CMMI为用

CMMI的优势：很完整的框架和知识体系  致命弱点：假设世界很少变化
敏捷的优势：拥抱变化，核心是它的价值观  弱点：实施的障碍比较大，往往实施过程中重于形式，而非本质。

以敏捷的价值观为体，把CMMI的一些好的实践应用于敏捷。

[ 本帖最后由 ThinkInChaos 于 2009-8-10 16:39 编辑 ]

xiaoyaoliuyun

忽悠忽悠，
一切根据实际需要，没有什么谁落伍谁先进

yangzhi984

老外起步的比较早，我们还是踏踏实实走过每一步吧

renhuilao

我们的项目在用Agile。谈点体会吧：
1. 人与人的沟通更直接更有效。
2. 发现问题和解决问题的速度明显加快。
3.必要的文档还是需要提供（主要是最后要发布到用户那里的）

作为测试人员，在之前的模式下，我们通常会需要大量的需求文档和设计文档，但开发人员通常很难按照那一堆的标准提供我们想要的东西。由于时差和沟通的成本太大，大多数情况下会按照自己的理解来测试~~~在Agile模式下，每天（不同local至少每周一次）的scrum上可以讨论，开发、测试都把问题摆桌面上来商量，解决问题的速度快得多。

对于开发人员和测试人员不在同一个local的情况，那简直是累得要死啊~~~~~~

Agile之后，每个迭代的时间都比较短，新功能测试都有点紧张，所以regression在每个迭代当中的比例就很小了。所以在项目后期，还是会像传统那样安排一个月左右的regression和final。以保证质量

Agile对人的要求非常高。模块细化后，很可能一个scrum就是一个开发一个fvt一个gvt还有一个svt，每个人要干的工作基本上就是传统模式下leader要干的活。需要承担责任。

[ 本帖最后由 renhuilao 于 2009-8-21 16:47 编辑 ]

yiding_he

原帖由 ThinkInChaos 于 2009-8-10 13:38 发表
CMMI的优势：很完整的框架和知识体系  致命弱点：假设世界很少变化
敏捷的优势：拥抱变化，核心是它的价值观  弱点：实施的障碍比较大，往往实施过程中重于形式，而非本质。

1、怎么定义才算“实施”了？老板一声令下就算实施了？还是说必须大家都认认真真去做了才算实施了？那么敏捷和 CMMI 哪个更容易"实施"不言自明。
2、关于谁更流于形式，我重新贴一下敏捷宣言：
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作   重于 合同谈判
响应变化   重于 遵循计划
完全可以看作左边就是敏捷，右边就是 CMMI。

Oilio

支持

yiding_he

原帖由 jimmyseraph 于 2009-8-23 15:48 发表
咋又翻出这个帖子来了，71楼的也不用把敏捷宣言贴出来，敏捷宣言说白了就是一群程序员为了忽悠别人相信敏捷而抛出来的美丽的谎言，不用太在意。
我在58楼就说过了“敏捷和CMMI都看做是信仰，相信就能做好”这句话， ...

这句话的意思就是，在你背上写个“佛”字，告诉你心诚便可刀枪不入，被砍死了就是你心不诚。CMMI 是万能的，就看你心诚不诚了。

kojywu

我觉得挺有道理的，支持一下

yiding_he

原帖由 jimmyseraph 于 2009-8-24 11:43 发表
典型的没有理解我的意思，我说了不管是CMMI还是敏捷，把它当成信仰就行了，项目做的失败了，和你的信仰的东西没有关系，而是要从你自己本身入手看问题。就像佛教和道教，你在背上写个“佛”字，告诉你心诚便可刀 ...

“明明是执行不到位造成的项目问题，偏偏去怪CMMI不好，极力推敏捷，而不去深究问题的根因是什么”
——我觉得更应该深究为什么 CMMI 总是会 “执行不到位”？为什么过了 CMMI 之后马上就丢到一边？根本原因是什么？这涉及到对软件、软件项目和软件工程本质上的理解。

“关键在于执行力”
——关键不是在于“执行力”，而是在于“执行的动力”。想想两者的区别。

[ 本帖最后由 yiding_he 于 2009-8-25 11:52 编辑 ]

yiding_he

原帖由 jimmyseraph 于 2009-8-25 12:21 发表
你是怎么得出CMMI总是执行不到位的？至少我见过不少大公司的CMMI执行都不错，项目成功率也很高。
CMMI也是经过实践检验的成功经验总结，换句话说就是符合本质的，所以要从本质上来考虑CMMI和敏捷根本就不会有结论。

只要过了 CMMI，基本上都会说自己是“成功的”。我也在 CMMI3 的公司呆过，当时过 CMMI 的时候也就是拿一两个项目做样子，疯狂的补写文档。按讲师的话就是：“大家都是这么过的”。过了 CMMI 就真的能用起来吗？CMMI 再牛也牛不过开发进度表。至于成功案例，那与项目质量无关，只要凭关系磨嘴皮让用户答应项目上线，那就是“成功”了。你说的“执行都不错”有多少水分在里面，值得怀疑。如果一定要统计数字的话，看看这里：

http://www.cnblogs.com/cmmi/archive/2008/06/12/1218204.html
“大部分的企业（近60％的企业）实施CMMI收效不甚理想，最终走向失败”

我知道你会说：他们只是把 CMMI 当成工具而不是信仰。不过我更愿意相信他们一开始对 CMMI 还是非常期望的，就像我原来所在的公司一样，老总一开始也是非常积极，直到准备实施了才发现员工们怨声载道，最后只能拿一两个项目敷衍了事。大部分企业就是差不多的这样一个过程。这时候还不去检讨 CMMI 到底出了什么问题，那这问题永远也解决不了。

[ 本帖最后由 yiding_he 于 2009-8-26 01:01 编辑 ]

狩猎者

适合的就是最好的，不适合的再好也没用

woza

79#说的不错。
我们不说CMMI应该是什么样子，那没有意义。按照CMMI实践的情况来看，这种开发模式至少不是开发者喜欢的模式。我觉得软件开发恰恰是一种喜欢（至少不讨厌）才能做好的工作。敏捷提供给喜欢做软件的人一种可以把软件做好的思路。
如果真的能够把这个脑力工作变成体力工作，比如说对日外包，那么CMMI未必不是一种好的方法。同样对于那些只把做软件当作混口饭吃的人来说，CMMI和敏捷也没啥区别。

yan_guimei

mentgmery

CMMI喧嚣之后,又见敏捷,本人更赞同吴穹博士的观点
请见http://blog.csdn.net/adwu73/archive/2008/06/23/2577810.aspx

[ 本帖最后由 mentgmery 于 2009-9-11 14:22 编辑 ]

ddzkq

1、企业文化非常凝固--所有人的工作习惯、态度都趋于一致
2、开发团队形成了很强的惯性--从最基本的代码要求到模块化，日志格式、帮助、界面、操作、接口通讯等等一直在延续一种惯性，而且在这整个团队中有默认的很强的评判者--某开发总监

yezi121808

不同的业务模型决定了不同的开发模式。思科、诺西、华为的开发模式，和快速业务定制的开发模式也不相同。电信业务比较标准，使用CMM比较合适，而有些客户需求，要求很快能与客户交流，研发能直接接触到用户的，使用敏捷就比较合适。

sinojelly

CMM:它相信，好的流程，好的生产线，就可以生产好的软件产品，典型的机器化大生产的产物。把人当生产线上的操作工。命令式的任务分配，不能调动程序员的积极性，还容易产生各种矛盾。
Agile：它认为有优秀技能的人，才能生产出好的软件。以人为本，激发人的激情，提升人员技能。敏捷还强调消除各种浪费，做最有价值的事，很明显这比无论有用没用，流程规定就去写很多文档要好很多。
CMM的文档驱动方式，来源于一个误传，它的创始人都否认了。