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

woza

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

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

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

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

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

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

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

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

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

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

woza

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

woza

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

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

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

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

woza

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

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

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

woza

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

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

woza

我不否定CMM的价值，就像我认为瀑布模型是非常伟大的模型。但是世界是不断发展的，以前适合的东西，不等于现在也一定适合。说不定以后哪一天，敏捷也会落伍。

我们公司的工程师和其他公司的没任何区别。他们也会抱怨工资不高，公司有时候不够重视他们的等等。但是绝大多数人没有离开，因为公司里有吸引他们的地方。我想很大程度上是因为我们实施了敏捷。他们至少在很多时候有做决定的权利。他们在多数时间是自我管理的。我相信任何一家公司，都肯定有一些工程师希望能够有足够的发挥空间。这个并不是做不到。

有兴趣的童鞋可以去我的博客看看，即使在传统模式下，敏捷也是有生存空间的。

woza

ls说的有道理。我从来没见过国内哪个公司实施CMM的时候，公司内所有的团队都是按照CMM的流程规范实施。不要告诉我谁谁是几级，我在CMM4的美资公司工作过，很多东西说的和做的完全不同。当然，我也可能孤陋寡闻了。

我现在工作的公司，所有的团队都是实施敏捷的。因为很多规矩是工程师自己定的，所以没道理不能遵守。而且规矩定了也不是不能改，只要团队意见一致就可以。所以我相信敏捷在国内是可以行得通的。而且效果非常明显。门槛也比CMM要低得多。

但是实施敏捷的关键在于，管理层肯不肯放权。我相信多少工程师都会喜欢敏捷。但是多数经理不会喜欢。因为他们能够控制的东西变少了。

woza

敏捷是以人来控制规则。传统开发模式是以规则来控制人。如果CMM能够让工程师来制定规则，自我管理，那也可以很敏捷。

woza

ls说的不错。ＣＭＭ本身也在不断改进中。说不定将来也会是一个很好的实践。
只不过敏捷的低成本优势，恐怕ＣＭＭ很难比得上。

woza

首先，敏捷并不是以放弃质量的代价来加快开发速度。相反，敏捷最优先考虑的是质量。敏捷通过减少浪费，缩短迭代周期，来做的快速提交客户可用的软件。注意：是可用的软件，而不是完整的软件。

其次，敏捷适合开发大多数商业软件。人员变更大，人数较多，维护时间长，开发周期长等等正是传统开发模式的弊病。敏捷就是为了解决传统模式的不足才诞生的。

人员分散对于所有的开发模式都是一个问题。我觉得敏捷在这方面做的比传统模式要好一些。

我不明白为什么公益项目不能使用敏捷。敏捷的成本优势如此明显，公益性项目应该使用敏捷才对。

虽然我不觉得敏捷和特种部队有什么关系。但是君不见如今的世界，特种部队的使用远远比重装部队要多吗？特种部队灵活，低成本，快速反应的优势太明显了。现在都是不到万不得已，不会使用重装部队。

woza

谢谢31#提醒。因为我觉得CMM和CMMI一脉相承，所以我一直用CMM代替两者。

我发这个贴，主要目的是把敏捷带入大家视野。敏捷是各种传统模式以外一个新的选择。我个人认为是更好的选择。

敏捷实施的条件非常简单，不需要增加任何成本。非常适合国内的情况。

woza

CMM不是不好，更不是坏，只是过时了。CMM不是信仰，敏捷也不是。我只是看到CMM没法很好的处理需求快速变更等问题。而现实情况是，需求变化越来越快。所以说CMM过时了。

需求变更1，2个，还是50，60个，对于敏捷来说都是一样的。敏捷本来就欢迎变化。

按照ls说的，CMM要到5级才有裁剪需求。那么1-4级的时候，就不能运行团队的不同流程，那要来何用。

CMMI其实还是和CMM同源。当然改进了很多。所以比CMM相对来说灵活一些。希望哪位给我一个国内CMMI实践的比较好的例子。

敏捷有daily stand up，没有听说过周例会。每天的那个会，我非常肯定不是用来评审的。

woza

就目前情况来看，敏捷实施起来确实需要一些时间，但是仍然比CMM要容易很多。

项目以外的干扰是无法避免的。但是这些干扰是可以纳入管理的。比如说，团队收到一个项目计划外地任务，那只要Product Owner给这个任务制定了优先级，加入团队的任务列表中就可以。团队始终是按照优先级来完成任务列表。只要PO知道，加入一个新任务，必然导致某个计划内的任务可能无法完成。对于团队来说，就没有问题。

woza

敏捷和文档不文档完全没有关系。敏捷只是减少浪费。不管这个浪费是文档，沟通，管理还是技术。

成本的问题么，减少了浪费，自然成本就下来了。

LS可以去我的博客看看，或者翻翻我其他的贴，或许能回答你的疑问。

woza

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

woza

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

woza

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

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

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

woza

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

woza

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

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

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

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

woza

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

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

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

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