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

oscarli

找到公司合适的模型才是王道，如我们公司一个测试人同时跟踪几个项目，如果没有文档，根本无法工作。如果有测试人员与开发人员1：1，那样道是可以省不少文档。

woza

敏捷并不仅仅是几个实践模型。更重要的在于它的思想。敏捷提供了一个全新的思路。敏捷的核心在于人。所以并不需要依赖太多客观条件。在瀑布模式下也可以局部实施敏捷。只要能有持续改进的恒心就好。说到底，模型都素浮云。

nijp2004

凡事比较的帖子总是容易变成水帖，讨论了这么久，我想个人起码可以明确几点
1、大多数观点是适合的就是好的，但对于实践，不能今天采取A方案，明天采取B方案，所以，重要的是分析目前还有哪些需要改进，哪些优先级最高，然后再考虑哪种改进方法比较好，当然，什么都没有规范下来的组织可以更多的来选择学习对象，学习成熟的案例。企业过程改进不是找试验田，当然，内部找个team试验是可以的。

2、CMM2、3甚至ISO都是管理基础，起码有些扫盲工作可以做，比如配置管理的概念，很多小公司如果连这个意识也没有的话，那就不用考虑敏捷了。容易被误导的，这就和不管哪种运动，都要确保身体基础没有问题，有病先治病，然后再健身。

3、无论CMM或者敏捷，知识的转移和传承都是很重要的，团队在一起工作是为了沟通，即使在不同国家看起来也可以通过网络沟通，但越分散沟通质量会降低，还是需要文字做为媒介，因此，用Wiki或blog或者doc，本质都是一样的，当然，从技术上方面来说，wiki完全是颠覆了doc的概念。可以这么说，WiKi是王道，文档落伍了。

傲然

棉结 国内有几个真正做到的？？？还不是畸形的吗

nijp2004

LS，不好这样问的，起码就我就知道一个。绝对不知名的公司，项目周期不紧张，资源也比较多，总之不差钱。
集团公司，主营业务和软件无关。所以研发老总自我发挥的余地很大。产品目标是集团自己管理用的，如果做的好，可以卖给同行。最终结果如何，我不得而知。因为前同事离职了。
这个真的是敏捷模式的。

[ 本帖最后由 nijp2004 于 2009-7-2 16:55 编辑 ]

kuailederen

别讨论了，我发现无论怎么样的模式，不如找个有能力的领导，一句话就搞定模式搞不定的问题

woza

我们公司就是用敏捷的。感觉还不错。效率，质量提高了很多。

simp

敏捷对人的要求太高了，国内有多少人能做起敏捷来？
现在n多冲着敏捷去的，就是冲着不需要写文档，不需要有思考过程去的。往往结果都很悲惨。往往是眼高手低。

kiddy

个人体会敏捷应该是在cmm下进行精简，去掉糟粕留下精华。
cmm有太强的通用性，各个公司应该根据自己实际情况进行调整，找到最适合的方式方法。
说实话，感觉了大中小三种公司，其实国内很多做软件的前期调查定位不足（主要是产品经理方向及要点把握不好）导致中后期太多小调整，小变动，周期不确定性严重扰乱了cmm的流程减低了其实际效果，所以才凸显了敏捷的优点，小周期迭代！这样快速处理快速跟进更能发挥作用~就此同意楼上部分同学的看法“国内还是敏捷好！”
但如果架构一个大型的，周期长，功能结构复杂系统，cmm才能发挥作用！
这就是“一寸长一寸强” 与“短小精悍”的区别！

movestar

有的时候真的不知道什么是适合的，怎么判断是不是适合呢？

woza

如果需求变更非常少，那用什么模式开发都一样。用瀑布也可以做的很好。之所以大家觉得瀑布有不足，就是因为需求不变的开发项目几乎不存在。

既然现实无法改变，那自然只能改变自己。所以敏捷出现了。我不明白为什么大型软件不能使用敏捷模式。事实上，我觉得目前来说，敏捷的不足仅仅在于没有一张类似CMM之类的证书。对于客户来说，开始的时候不那么容易判断软件企业是否能够提供高质量的软件。一点客户和敏捷团队合作过之后，就会发现他们应对需求变化的能力绝对不是传统模式的团队能够比拟的。

回 51#：
很多时候确实很难判断哪种模式更适合自己。最好的办法是，都试一下。如果做不到，那就选实验成本低的先试一下。

ydz123456

有道理

sk_svenska

CMMI是一个庞大的系统，她存在的意义是不可否认的，对于任何试图尝试她的组织来说都要花费不少的气力可是真的有必要教条似的照搬么？抓住要义然后结合实际应用来取舍岂不 敏捷 哉！

woza

CMMI就象一张大学文凭。企业有这个文凭，找项目容易一些。但是并不是说拿到一张文凭就万事大吉了。这个东西只能证明你接受了某种程度的教育，但是无法证明你有多么高的水平。况且国内（包括国外也一样）掏钱买文凭的居多，认真学习的较少。所以这个文凭的水份不是一般的多。

fluter

敏捷是武术师，请不要让他们打大规模战争。
CMM是军队，请不要拿去单挑。

aliceella

敏捷开发是指的快速的进入开发吧，省去一些文档或者最后再补文档！

天空下下雨

这个世界没有银弹。可以去javaeye的敏捷频道看看。

kf_rainbow

所谓敏捷,起码要在CMMI达到一定程度才能做的!
光敏捷,什么知识都留不下来,凭什么说队伍就一定稳定??
技术骨干走了,光敏捷,怎么进行之后的产品研发?

yiding_he

原帖由 kf_rainbow 于 2009-8-6 14:37 发表
所谓敏捷,起码要在CMMI达到一定程度才能做的!
光敏捷,什么知识都留不下来,凭什么说队伍就一定稳定??
技术骨干走了,光敏捷,怎么进行之后的产品研发?

第一句话我不认同，但是后面两句话说到点子上了。CMMI 的核心价值观，就是将人看成是最大的风险，CMMI 所有的一切都是为了应对这个风险。人的风险越低，说明企业越 “成熟”。

woza

那么为什么人会有风险呢？如果搞了CMMI，大家干活不happy，流动率高，当然就有风险了。而敏捷提倡enjoy，事实证明，我们公司流动率超级低。

即使人员流动无法避免，那么依靠文档是最好的经验传递方法吗？人才是传递经验的最好载体。在敏捷团队中，知识经验能够快速分享，即使走掉个把人也没什么。再说，敏捷团队是自适应团队。不是依靠某个人，而是依靠团队合作。如果缺乏某种技术，那么团队会自己去找另外一种替代技术。

如果真的发生了一夜之间所有核心人员都走了，那就是这个公司出问题了。公司都垮了，你有再多的文档还有啥用。

最后，产品维护这种概念敏捷是不存在的。敏捷通常使用重构，但这并非是维护。所以不要把维护拿来说事。