锁定老帖子 主题:CMM到底给我们带来了什么?
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2004-12-10
嘿嘿,我们部门的SEPG给我没有留下一点好感。只是一群没什么经验的人在一起纸上谈兵而已。而且自己往往都搞不清楚是怎么回事就出来让别人跑他们的流程了。
最可恶的是今天说的明天就可能换一种说法,郁闷。 |
|
返回顶楼 | |
发表时间:2004-12-10
RUP也许有用,应该说很有可能有用。可是如果没有人可以来指导我们的实做,实施起来应该是蛮难的吧。而且,由于经验的不足或者这样那样的原因,很容易就把RUP跑成了一个四不象。正如我们现在的情况。
还有,RUP给我的印象是亲和力不如敏捷方法,现有的资料很多都是通过理论来说明他的好处,优点。而真正通过实例来说明的很少。 现在面临的最主要的问题就是如何使RUP来适应我们这种小型团队的开发,我想这是我们的当务之急。大家有社么好的建议么? |
|
返回顶楼 | |
发表时间:2004-12-10
lucifer 写道 现在面临的最主要的问题就是如何使RUP来适应我们这种小型团队的开发,我想这是我们的当务之急。
一个建议,规模非常小的开发团队(5 人以内)最好不要在软件工程、过程改进方面浪费太多的精力。精力应该更多的花在如何更好地满足用户的需求和如何提高自己的技术实力上面。对于用户的需求充分理解了(当然也不是用户说什么就是什么),技术实力也提高了,自然可以找到最适合自己的开发方式。有了自己行之有效的套路,然后再去做过程改进也不迟。 Scott Ambler 以前在 CSDN 聊天室中也承认 XP 的完全实施需要至少 6 个开发人员。对于你们这种小型团队,开发工作往往是非常紧张的,很难想象还会有一些人捧着书本夸夸其谈。说的不客气一些就是 xx 里面摔跤——离死不远了。 |
|
返回顶楼 | |
发表时间:2004-12-10
dlee 写道 lucifer 写道 现在面临的最主要的问题就是如何使RUP来适应我们这种小型团队的开发,我想这是我们的当务之急。
一个建议,规模非常小的开发团队(5 人以内)最好不要在软件工程、过程改进方面浪费太多的精力。精力应该更多的花在如何更好地满足用户的需求和如何提高自己的技术实力上面。对于用户的需求充分理解了(当然也不是用户说什么就是什么),技术实力也提高了,自然可以找到最适合自己的开发方式。有了自己行之有效的套路,然后再去做过程改进也不迟。 Scott Ambler 以前在 CSDN 聊天室中也承认 XP 的完全实施需要至少 6 个开发人员。对于你们这种小型团队,开发工作往往是非常紧张的,很难想象还会有一些人捧着书本夸夸其谈。说的不客气一些就是 xx 里面摔跤——离死不远了。 完全赞同,如果人少的话,就以培养个人的敏捷编程习惯为主,如创建自动化的单元测试啊,代码规范啊,构建持续集成的环境啊等具体可操作的事情上,而结对也应该自由的尝试一下,至少做到测试没通过就睡不好觉 。这样经过一段时间大家就会习惯用敏捷的方式来工作了,今后管理上的工作也好开展些。 |
|
返回顶楼 | |
发表时间:2004-12-10
to Archie:
我上面不是反对 XP 啊。相反,我认为 XP 中的最佳实践对于达到我上面说的第二个目标(提高开发人员的技术实力)在现在所有的开发过程中是最有效的。这些最佳实践即使人少也可以看情况适当采用起来,可能只有结对编程对于人数的多少有一些要求。 采用什么样的开发过程确实和开发团队人数的多少(实际上是沟通量的大小)有很大的关系。Cockburn 搞了一个无所不包的水晶方法体系。XP、RUP、CMM 都有其适用的场合,分别属于不同颜色的水晶。但是可以完全肯定的是 CMM 对于小型开发团队是丝毫没有帮助的。 |
|
返回顶楼 | |
发表时间:2004-12-10
过程成熟是需要时间和一定的前提条件的,比如业务模型的基本稳定。同时过程改进也是有它的策略;在CMM中并没有规定一定要采用什么SDLC,RUP是一种,我用Waterfall能解决问题又有什么不可以?关键是要接合组织的实际情况。
而且CMM是面向组织的过程体系,这点也应该注意。 |
|
返回顶楼 | |
发表时间:2004-12-10
jiwenke 写道 同时过程改进也是有它的策略;在CMM中并没有规定一定要采用什么SDLC,RUP是一种,我用Waterfall能解决问题又有什么不可以?
为什么一定需要 CMM,为什么一定需要一种放之四海皆准的“大方法论”?这一点仍然是很值得怀疑的。况且达到与 CMM 相同的目标是否一定要去参加评级?还有没有其它的方法?这是不是“一考定终身”的思维惯性? CMM 如果是仅供参考,还是不错的。但是将其作为软件企业一个宪法性质的东西,对于企业的发展未必能达到预期的效果。 |
|
返回顶楼 | |
发表时间:2004-12-10
不评级SEI和各种CONSULTANT吃什么啊?
原来CMM就是为了给提高软件组织的成熟度是过程改进的方法提供参考,当然是有些大而全。当然,为了做BENCHMARK,一些评审是必要的。 CMMI比CMM有所改进,模型好不好取决于用的好不好。 |
|
返回顶楼 | |
发表时间:2004-12-10
敏捷方法借鉴CMM系统唯一的一点就是,他们那样干不行,不要去搞那些过场化的东西。而实际上如果年纪大一些的人,就可以发现其实根本就没有什么Agile——实际的情况是OO社区的一些人用了一个比较别致的名字,把原来基于相同思想意识的人团结在了一起,在一次强调了增量开发。仅仅就是如此而已,Agile说穿了就是短迭代,就是不断地提交可以运行的版本。其他的一切都是以此为中心进行的。这个算本质特征。当然这是我的独家观点,有机会我会去comp.object和他们探讨这个事情。
实际上RUP也好,MSF也罢,都是至少隐含要求你去迭代,去增量的。所以你看agile从2001年才开始出现(但是方法实践是从上个世纪80年度末就开始了),马上就是一片叫好,根本就没有什么人出来谈论agile是不是正确,而更多的谈论的是Agile是不是能够被好好实施以及如何好好的实施,就是CMM的头把Watts Humphrey都很大程度上对xp有相当的好感。 说白了Agile就是上个世纪方法论大战的直接结果,是面向对象社区对方法论大战的战果的总结。所以Agile一出现那些本来就是一个战壕的人,就迫不及待的出来用各种的方式进行吹捧。不然Agile也不会这么快的成为主流开发思想。而CMM基于的都是70年代和80年代早期的IBM这样的大型软件企业的实践,根本就没有考虑到软件的开发以及成为一种非常普遍的社会生活。而又由于CMM方面没有几个真正的方法学家压阵,基本上考虑问题也是从管理角度出发,所以针对实践性非常强的软件开发,显得根本就没有什么前途。 |
|
返回顶楼 | |
发表时间:2004-12-10
SEI会活得很好,而各个CONSULTANT只要有真的是想做CONSULTANT也会活得很好。SEI是一家政府拨款的研究机构,不能像中国那样搞多种经营。而CONSULTANT可以去看看敏捷签名的17人,你会发现这些人几乎都是CONSULTANT。他们活得都很好,为什么做CMM评级的那些人就不能获得自己的前景呢?说白了还是一个道德素质的问题,使一个诚实度的问题。
|
|
返回顶楼 | |