51Testing软件测试论坛

标题: [原创] CMM已经落伍了，敏捷才是王道 [打印本页]

作者: qinyuling.happy 时间: 2014-10-24 14:52
标题: [原创] CMM已经落伍了，敏捷才是王道
首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于CMM的那些文档感觉有些浪费。

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

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

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

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

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

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

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

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

作者: Miss_love 时间: 2014-10-24 15:47
流动性低和敏捷测试有关啊？

作者: litianzhi 时间: 2014-10-28 15:50
我想知道你是怎么敏捷管理的？

作者: 弎盛 时间: 2014-10-30 10:09
有点跟不上，我到现在还没有见识敏捷测试。。。。

作者: annkingup 时间: 2014-12-10 13:56
看项目规模有多大

作者: haohaoaini520 时间: 2015-1-15 15:44
感觉有点不符合实际！

作者: xuelian877 时间: 2015-4-2 15:26

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

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

作者: xuelian877 时间: 2015-4-2 15:26

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

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

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

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

作者: ddqhf 时间: 2015-12-21 16:57
本帖最后由 ddqhf 于 2015-12-21 17:05 编辑

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

首先强调一下，敏捷和有没有文档一点关系都没有。我只是对于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 时间: 2015-12-22 00:43
标题党啊。CMMI像是一个大的Best Practice词典，这个里面的一个个Best Practice还不是很具体，需要大家如果参考的时候自行还要进一步百老师谷老师查一下。还有就是它提出的一套评估能力的Goal，也对我们很有参考意义。

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

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

作者: luoyear 时间: 2015-12-22 08:44
现在确实有人把敏捷和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 时间: 2016-3-28 10:01

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

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

来个联系方式！！！

作者: 菜鸟gg 时间: 2016-8-30 17:24
感觉没有实际有用的东西，只是一味的追捧

作者: BBY 时间: 2016-10-19 14:40
为红色回复点赞

作者: huigor 时间: 2017-2-24 16:03
为红色回复点赞

作者: suian001 时间: 2017-2-28 10:42

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

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

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

作者: piaolingxue423 时间: 2017-3-30 16:20

为红色回复点赞

作者: nixey 时间: 2017-7-12 11:36
初步接触敏捷，一直有个问题困扰：
贵公司是否有大篇幅的墙体粘贴PB？还是用传统的需求设计文档？

作者: Gertie 时间: 2017-7-18 11:11
为红色回复点赞

作者: yanhui_smile 时间: 2018-2-28 11:29
红色回复，看问题很全面，赞“尽信书不如无书”

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)