[原创] CMM已经落伍了，敏捷才是王道

qinyuling.happy

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

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

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

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

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

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

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

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

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

ddqhf

对你的观点一一进行解释，欢迎大家拍砖！

首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于CMM的那些文档感觉有些浪费。
【ddqhf: CMM/CMMI和有没有文档也一点关系都没有，从来都只需要output，所谓的“那些文档”都是公司要求的（要么根据自身实际要求、要么照搬他人经验）。】

看看那些文档，看看那些流程。想想那些伟大的软件作品，哪个是用CMM开发出来的？
【ddqhf：也没有谁是用敏捷开发出来的，只有用某种语言才能开发得出软件作品】

作为测试工程师，程序员的你在CMM流程管理下，是不是觉得不爽？你喜欢写那一堆又一堆的文档吗？你喜欢看那一堆又一堆文档吗？你喜欢你的老板整天指手画脚其实完全没有帮助？你喜欢看到需求不停变更但是计划永远不变，结果就是压缩测试时间，或者发布延期？答案当然是否定的，没有人喜欢。
【ddqhf：CMM/CMMI没有要求一定要什么文档；能做自己喜欢做的事情是所有人的梦想，但现实很残酷；CMM/CMMI可没有教老板做一些完全没有帮助的指手画脚；CMM/CMMI要求的是需求变更一定配套有相应的计划变更，计划不变不是CMM/CMMI的错，请找准责任人，找准根本原因。】

软件开发是一个创造的过程。工程师是人不是机器。符合人类天性的开发模式才是好的开发模式。
【ddqhf：CMM/CMMI是流程框架，不是开发模式，敏捷、瀑布、迭代才是开发模式，CMM/CMMI没有指定你必须使用哪一种开发模式。】

软件开发的核心问题:沟通障碍，需求变化，产品质量等等。在CMM模式中都没有被很好的解决。敏捷提供了一种全新的思维方式。敏捷的核心思想就是以人为本，持续改进。
【ddqhf：CMM/CMMI是流程框架，不是模式；CMM/CMMI是通过流程来解决的是管理上的问题；作为一种开发模式，敏捷为解决沟通障碍提出了一系列解决方案，但现如今国内市场，真正能够按照敏捷的思想来处理好沟通障碍的公司，可谓凤毛棱角。最后，CMM/CMMI与敏捷不是同类，不可比较。】

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

文档的作用是用来沟通，交流和传递信息。但是文字本身并不是一个完美的载体。语言永远比文字更能够清晰的表达思想。所以在敏捷开发中，类似于测试计划，方案，任务分配，简报之类的都可以省略。我能够花三分钟说明白的事情，为什么要花十分钟去写，而且还要接收者再花十分钟去阅读。这不是白白浪费了十七分钟。
【ddqhf：提醒一下：敏捷这种开发模式，只是给大家提供了一种提升项目成功率的方法和思想，但是作为一共公司的发展，需要考虑的事情不仅仅局限于某个项目。所以，即使你花三分钟能说明白的事情，在公司层面看来，依然需要你花十分钟去写。而这，跟任何流程模型、开发模式并无因果关系，这是公司发展所需。】

当你加入一个新团队的时候，你希望看到一大堆产品说明，还是喜欢有个人手把手的指导你？我想多数人喜欢后者吧。
【ddqhf：我还更喜欢一进项目就能按照我的想法来做事呢，都不需要人指导。所以，还是那句话：能做自己喜欢做的事情是所有人的梦想，但现实很残酷。】

敏捷团队中，所有的知识都是共享的。所以完全不需要担心，由于某个成员的缺失而造成知识断层。同样的，由于这种担忧而产生的文档也可以省略掉。顺便提一句，虽然我不知道为什么，但是敏捷团队的人员流动率非常低。我公司里面的测试人员在实施敏捷之后的若干年里面，一个离职的都没有。
【ddqhf：并非敏捷团队中，所有的知识才是共享的，只不过是敏捷提倡了这种意识而已。共享与否在于公司高层是否有那个意识。至于流动率非常低，这更不是敏捷带来的了。如果敏捷真那么牛逼，那公司是不是可以给大家不加薪甚至减薪？】


【ddqhf：总之，在看到某种好处的时候，大家一定注意分析这种好处产生的根本原因，这样才能让我们更好的结合实际来运用各种方法、流程框架等。再加一句：尽信书不如无书！】

luoyear

标题党啊。CMMI像是一个大的Best Practice词典，这个里面的一个个Best Practice还不是很具体，需要大家如果参考的时候自行还要进一步百老师谷老师查一下。还有就是它提出的一套评估能力的Goal，也对我们很有参考意义。

敏捷相当于CMMI里面某几个方面的Best Practice的实例化的东西。由于它高度实例化，所以我们可以全程照搬。

但敏捷现在也走上教条了。很多人谈敏捷就必谈Scrum，谈Scrum就必遵循所有Scrum的实践。个人不敢苟同。比如故事点，比如Velocity，比如扑克牌估算，真的是最有效最贴合你团队所用的吗？

绿茶子的阳光

CMMI跟敏捷能混为一谈？敏捷只是项目的一种开发模型，像早期的瀑布开发模型一样。而CMMI是评估一个企业的能力成熟度，CMMI相对应成熟度下，你可以采用敏捷模式开发项目，也可以采用瀑布模式开发项目，这就根据你项目的规模及人员能力情况了。敏捷开发对团队人员要求比较高，国内很多项目还是不能做到真正的敏捷开发，只能说是用到了敏捷开发中的部分优秀实践。

xuelian877

所以在敏捷开发中，类似于测试计划，方案，任务分配，简报之类的都可以省略

这段文字，个人不是很赞同哦，人的记忆力是有限的，再敏捷开发该有的文档也要有，我支持简明扼要地写~ （只讨论问题，不针对个人哈）

Miss_love

流动性低和敏捷测试有关啊？

litianzhi

我想知道你是怎么敏捷管理的？

弎盛

有点跟不上，我到现在还没有见识敏捷测试。。。。

annkingup

看项目规模有多大

haohaoaini520

感觉有点不符合实际！

xuelian877

所以在敏捷开发中，类似于测试计划，方案，任务分配，简报之类的都可以省略

这段文字，个人不是很赞同哦，人的记忆力是有限的，再敏捷开发该有的文档也要有，我支持简明扼要地写~ （只讨论问题，不针对个人哈）

grant1

敏捷互动比较强 在国内 交流本来就对立的 敏捷施行比较困难  而且梳理流程也过多  你要做敏捷的试试星云测试的免费平台 交互性很强 有可能会对你有帮助

luoyear

现在确实有人把敏捷和CMMI的经都念歪了。
1. 拿CMMI来说，企业实施过程平添了那么多的流程文件和项目产出文档。流程和项目组真实做法两张皮，一些质量管理体系要求的文档，对于项目组实际开发管理工作指导作用有限。
但这不是CMMI这个模型的本意。CMMI通俗一点来说，把软件项目管理和研发活动划分为若干领域，然后按照大家的研发管理水平把这些领域划分为几个阶梯。也就是管理水平到了中游的企业，你重点要改进哪些领域，最顶层的企业，你重点关注的是啥。然后对每个领域提出不同的目标要求，对于具体怎么做，也列出了一系列的具有参考意义 但不太详细的Best Practice。注意，这些Best Practice只是具有参考意义，而不是模型本身强制要求你这样那样。模型本身来说，只要你达到它要求的管理目标（效果），就OK了。就拿设计和需求来说，现在大家真实的干项目，大部分情况下都是UI设计，Usecase画出来之后，DB设计出来，然后就可以干代码了。所以，最简化的情况下，你的需求就可以只需UI设计以及必要的数据约束和Usecase图。你的设计就可以只有DB设计，已经API设计。因为你这样的最小集加上频繁的需求和设计讨论，持续集成和代码评审，和客户的演示，一样达到CMMI里面需求和设计方面的所有管理要求。

2. 敏捷也有人把经念歪了。谈敏捷必谈Scrum，谈Scrum就必谈Scrum的所有套路。Scrum和CMMI不一样，CMMI相当于是一个字典，Scrum则是一个高度实例化的项目管理方法。这也是很多敏捷的人攻击CMMI教条的原因。这不是CMMI的错，也不是大家的直观印象的错，是对CMMI理解的偏差。不是每个人都是过程专家，都有心去研究词典一般的CMMI。这就需要过程专家活学活用，如何落地。悲哀的是，现在很多过程专家，自己研发一天都没干过，只知道符合性的检查，不明白为什么要这个那个，不尝试去理解为什么项目组会那样做，还理直气壮说自己管的好好的，而事实人家也确实管的好好的。同样的矛头我一样可以拿来和Scrum说事：多少人会去用故事点？多少人会去用Velocity？真正你们敏捷估算会议的时候会去打扑克牌吗?敏捷估算只是打扑克牌吗，它的关键作用是啥（在我看来他的关键作用除了群策群力的估算外，还有识别需求理解偏差，从而考虑到需求实现的细节）？进度压力情况下，与团队自主计划之间矛盾怎么办？敏捷怎么测试？所以我在项目团队实施敏捷的时候也把Scrum的套路改的面目全非，加入了自己的实践。但我没否认Scrum原有的套路，每个项目或团队都有当前的限制，外部的依赖，商业环境的不同，不可一概视之。

123456fjm

ddqhf 发表于 2015-12-21 16:57
对你的观点一一进行解释，欢迎大家拍砖！

首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于CM ...

来个联系方式！！！

菜鸟gg

感觉没有实际有用的东西，只是一味的追捧

BBY

为红色回复点赞

huigor

为红色回复点赞

suian001

ddqhf 发表于 2015-12-21 16:57
对你的观点一一进行解释，欢迎大家拍砖！

首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于CM ...

有联系方式吗？请教几个问题

piaolingxue423

为红色回复点赞

nixey

初步接触敏捷，一直有个问题困扰：
贵公司是否有大篇幅的墙体粘贴PB？还是用传统的需求设计文档？