51Testing软件测试论坛

标题: 浅谈敏捷与CMMI [打印本页]

作者: ddqhf 时间: 2013-2-24 20:21
标题: 浅谈敏捷与CMMI
本帖最后由 ddqhf 于 2013-2-27 14:20 编辑

今天有幸看到一篇名为【CMM已经落伍了，敏捷才是王道】的帖子，本来想就在帖子上面直接回复的，后来担心那样的受众有限，所以选择了新开一篇帖子，来谈谈我认识的敏捷与CMMI，希望能够对大家有所裨益。当然，也欢迎大家与我共同来讨论！

首先，可能还会有人质疑敏捷是什么，CMMI是什么。不过这已经不是我想说的重点，所以对于他们的定义，大家就自己找度娘和谷娘吧！

开篇，我给大家一个私人的总结。大家可以试着去找找各自所在公司的项目，其根本的问题出在哪里？是不是主要集中在管理方面和人员沟通方面？而技术欠缺，其实只是占了一小部分。于是，我们的前辈们通过不断的摸索，便总结出了这两个东西（为什么不是方法？？）。
1. 敏捷是做什么的？敏捷其实是为了解决沟通的问题而生的。
2. CMMI又是做什么的呢？CMMI是为了解决管理的问题而生的。

说到沟通，这里势必要明确一下。对于一个项目而言，沟通无非这三方面的沟通：1）项目团队内部的沟通；2）项目团队与公司内部人员的沟通；3）项目团队与客户的沟通。

好了，先弄清楚两者的目的，然后我们再来仔细分析。

为什么说敏捷是为了解决沟通的问题呢？
首先，很多人都知道敏捷提倡以人为本对吧？为什么以人为本？因为项目是人在做，方案是人在提出。而以人为本则是体现在敏捷的最佳实践的方方面面：团队成员素质、团队稳定性、团队规模限制、和客户坐在一起、结对编程、快速迭代和快速交付、每日例会、（团队）坐在一起、自发组织、职能交叉等（凭经验随想随写，可能不够全面，欢迎补充）。

1. 团队成员素质的要求，是保证良好沟通的一个前提条件，这就像中国的一句古话：秀才遇到兵，有理说不清。
2. 团队稳定性，是保障沟通无遗漏或少遗漏的一个要素。如果团队成员一直相对稳定，那么彼此沟通会越来越畅通，且不会有或者少有工作交接的情况。为什么这样说，大家看看我们自己身边工作交接的效果如何就知道稳定性的重要性了。（但对于短期公司、短期项目而言，这一块是可以弱化的）
3. 团队规模限制，敏捷的各类方法，都会有成员规模的限制，一般是从4~9人不等。为什么这样限制？道理很简单，人少了，彼此互相提升少，且一旦人员变动，其相对变动比例高，工作交接这块的成本高；人多了，则增加了沟通对象，从而加大的沟通负担，增加沟通难度。
4. 和客户在一起，很多人忽略了这一点，这一点其实是敏捷之所以成功的至关重要的一点，怎么说？敏捷里面的需求怎么来的？是不是一条一条的backlog（有的地方时一条一条的feature的描述）？但这样的信息通常都是不够的（为什么这样说？试想，如果这样的信息都已经足够开发、测试了，那把这样的信息拼凑起来就已经是我们完整的需求文档了，大家说对不？），信息不够的话怎么办？把客户拉来和我们坐在一起就尤为必要了。对于信息里面有任何的疑问都可以随时从客户那里得到解答，这样我们的开发速度是不是大大加快了？当然，这只是“和客户在一起”的其中一个要点，另一要点是，“和客户在一起”，客户可以极大程度的便利的提出他的变更，同时项目团队也能快速的理解变更，然后快速的与客户沟通变更的影响并达成一致，进而才是快速的响应变更。敏捷的拥抱变化便是这样来的。试想，如果你仅仅只是客户有变更我们就做，根本不去理解变更，并且将变更的影响反馈给客户，你是打算找死还是你有耗不完的资源？
5. 结对编程，这是解决什么的呢？我们先看看传统的开发里面，是不是有代码评审这个环节（如果你觉得不需要，那可以不用继续看下去了）？很多急功近利的项目经理，会完全忽视代码评审这个环节，认为代码评审太耗时间，并且收效不大。诚然，很多项目的代码评审，其结果确实会是花了很多时间，但收效不大，为什么呢？很多人没有仔细去想想。你的代码评审是怎么评审的？是一个团队的人坐在一起一行一行的过？还是一对一的去看？（这里我不说方法论，因为没有绝对好的方法）不管什么方式，你有去找过自己没做好的原因吗？好了，这时候，敏捷给大家指了一条明路——结对编程。让开发人员在编程中就学习了，同时让我们的代码在编程中就得到了修正，而及早的修正了代码中的问题，可给后续工作带来的好处，相信不用我说大家都懂。
6. 快速迭代和快速交付。这又怎么与沟通联系起来呢？相信大家都明白，如果项目做完了，产品交给客户，客户这时候验收不过关，我们再来返工，成本可谓巨大，影响可以致命。而如果短周期交付客户，那么客户可以及早发现问题，我们也可以及早的进行修正，避免后续的连锁反应。而这期间，客户能（相比传统工作方式）提前与我们反馈问题，这就是一种沟通程序上面的优化。同时结合第4点，这样的快速交付成本也比传统的交付成本要低很多。
7. 每日例会，这个就太容易理解了，它不仅仅只是汇报的一种方式，更是团队内部固定沟通的一种方式。这里可能会有人质疑，因为每日例会通常要求不超过15分钟，汇报内容无非就那么三条，怎么沟通呢？我想说的是，大家不要把沟通想得那么狭隘。每日例会的真正目的也不是汇报工作，而是向团队介绍你的工作，当你弄明白怎么向他人介绍自己的工作，你才能开好每日例会。而既然每日例会是向他人介绍自己的工作，那么其他人在例会上需要做什么呢？显而易见，每个人都应该仔细倾听他人工作的介绍，并不断思考。为什么要这样做？目的在于，当某一时段出现必不可免的人员缺失时，其他成员可以迅速补上，这样说出来，相信大家就明白了，为什么每日例会同样中心在人员沟通。
8. （团队）坐在一起，说这个话题前，先问大家一个问题。各位对于以下几种沟通方式的效果排序有差到好是怎么排序的？
a) 文字交流（如QQ、短信、邮件等）
b) 语音交流（如QQ语音、微信语音、电话等）
c) 视频交流（如QQ视频、视频电话等）
d) 面对面交流
当你排好序之后，再来看我们这个“（团队）坐在一起”，后面的话应该都不用我说了。
9. 自发组织，这个要和沟通联系起来，可能会有点抽象，但是大家想想，你通常和爱说话的人关系更好，还是和沉闷的人关系更好（记住，是通常情况，千万别跟我说特例）？一个人，必须要有主动（自发）意识，才能更好的把自己展现给他人，才能更好的让他人走进（不是走近）自己，如此一来，彼此的沟通才会更顺畅。除此之外，自发组织还有个暗含的要求，即项目不受外部人员的干扰，而外部人员也不得干扰项目的运行。这一点，则是为了减少项目与外部（非客户）之间的利害关系，以此来弱化这两者之间沟通的影响。
10. 职能交叉，说到这一点，我又要说这是敏捷里面非常关键同时极易被大家忽视的一点。职能交叉，直白来说就是开发和测试是同一个人，亦即同一个人既做开发又做测试，这样的好处是什么呢？减少了人员沟通的环节！如果敏捷的项目里，开发和测试是分开的，必然需求需要开发理解一次、测试理解一次，而如果两者合二为一，则只需要理解一次即可（注：这里的理解包含有与客户确认需求的过程）。可能又有人会为，这样做岂不是自己验证自己？可以说是，也可以说不是。是，是因为他必然需要对自己的模块做单元测试；不是，则是因为我们传统的系统测试，其用例执行可由大家“自发组织”去选择，即你自己可以决定你应该去做哪个模块的系统测试。如果大家都选择自己做自己的系统测试，我只能说，其结果比较令人担心。

在以上分析的10条中，第1、2、3、5、7、8、9、10主要是在解决团队内部沟通的问题；第9则是在解决团队与公司其他人员的沟通问题；第4、6则是解决项目组与外部（客户）之间的沟通问题。而敏捷，则是通过这一系列的措施，来保障人员之间沟通的有效性，以此达到降低项目失败风险，提高项目效率（沟通成本降低，效率自然提高）及成功率。

说了敏捷，再来说CMMI。了解CMMI历史的人都知道，CMMI本身就是因管理而生的。没有管理的混乱无序，就没有CMMI的出生并成长。我们先来看看CMMI的22个PA：RD, TS, PI, VER,VAL, IPM, PP, SAM, RSKM, PMC, REQM, QPM, CM, PPQA, MA, DAR, CAR, OPF, OPD, OT, OPP, OPM（v1.3的叫法）。其中有5个是针对组织的体系建设的PA，5个针对工程（项目实施）的PA，7个管理类的PA（v1.3将REQM列入了管理类），5个辅助的PA。然而除了7个管理类的PA以外，5个辅助的PA可谓是完全为了更好的管理项目而服务的，5个工程的PA则只是简单的指出了项目实施过程中必须的活动，5个组织级的PA，其实是对组织的管理做出了要求。由此可见管理在CMMI当中的分量。（注：如果想要详细了解各PA，请大家自行官网吧，有问题倒是可以到这里来讨论- -）

说了这么多，也让大家看累了，还请各位恕罪！
只是归根结底，敏捷也好、CMMI也罢，其目的都是为了降低项目失败的风险，提高项目效率及成功率。只是途径一个是解决沟通的问题，另一个是解决项目管理的问题而已。
从另一个角度理解则是，二者都不是银弹，并不能保证项目一定成功，只是提高其成功的概率而已。

时间仓促，个中难免纰漏，还请大家指出。

如果还有其他问题，我们可以另开新帖进行讨论。
【完】

作者: ddqhf 时间: 2013-2-25 09:53
昨晚半天都没审核通过，于是等到今天早上来才把后面的内容补充完整。

作者: pcxty 时间: 2013-2-25 13:43
不错

1. 敏捷是做什么的？敏捷其实是为了解决沟通的问题而生的。
2. CMMI又是做什么的呢？CMMI是为了解决管理的问题而生的。

作者: 愚人 时间: 2013-2-25 14:14
很好，谢谢分享

作者: 愚人 时间: 2013-2-25 14:24
过程的目的是为了让项目做得更好，而不是把项目“框”死。

作者: 没翅膀的飞鱼 时间: 2013-2-25 17:32
学习了，一切的模型都是为了解决现实问题提出的--------

作者: eagle8625 时间: 2013-2-25 18:14
回复 1# ddqhf

CMMI是经典，强调理论上的大而全；敏捷则是强调实用，丢掉不必要的流程束缚，充分发挥人员的主动性。

作者: omg 时间: 2013-2-25 22:41
不想引起针锋相对的争吵。首先声明下没有看得非常仔细，不像review文档那种方式，说错勿怪。另外CMMI，本人接触不多，无法类比。

但单从你的结论上讲：
敏捷是解决沟通方面的问题

实在不敢苟同。

首先，我同意的业界一个观点，敏捷是一种文化，不仅仅是过程（或者这些最佳实践）。如果感兴趣可以看看http://www.agileproductdesign.co ... re_not_process.html （没有看到中文完整翻译版）。

从大的方面说，敏捷强调个人，个体，协作。敏捷衍生出来几大方法论，也都强调质量(可工作的软件)，也拥抱变化，也都是轻量级的东西。当然跟CMMI这种重量级的、几乎面面俱到的、过程多的不太一样。

简单说下小的方面，
强调客户协作
迭代初期时的需求陈清，需求优先级的确立，不能简单说其作用就是帮助沟通，这个的作用实际上是确立项目范围及具体的任务项。
客户针对迭代提交的东西尽早验收。验收-->反馈-->再调整任务。

做之前的讨论，做之后的验收实质是提高目前产品对客户的价值，尽量更早的满足客户的商业需要。

强调个人
开发做测试，是做单元测试，测试自动化，在培养质量、责任意识！
结对编程，代码Review也都是，在培养质量、责任意识！
自组织团队，也是培养大家对项目整体质量意识和自主性！什么事情差了点，需要多做？什么事情我做更擅长？自己的评估该如何有效做？
回顾会议，也是在培养持续改进的意识！

另外重要避免浪费时间，开发这里不把好关，遗漏问题出来，这些问题的成本就变大了，可能是影响到其他的人的代码；可能是测试发现了，再让开发修改了。

一个项目管理，最最基本的是进度的管理，敏捷里面的看板、燃尽图都是在做进度跟踪。

BTW，站立会议不只是沟通今天、明天的任务，还需要沟通遇到的障碍。遇到的障碍意味着什么，进度出现了问题，那应该尽早想办法处理。

状态不好，思路不清晰，貌似说得有点乱了，唉。

最后还是小结下，个人的看法，敏捷是文化，是价值观，是灵活的，不是一成不变。很多具体的项目活动（管理活动）是可以加入到敏捷过程里面去的。的确有些管理活动或者过程被弱化，或者消失，原因就是敏捷考虑重心在如何更快更有价值为客户的产品服务，具体最佳实践是为这个目的服务的。同样从敏捷活动中也看得出有对进度、质量、人员进行管理。

作者: lengyao 时间: 2013-2-27 12:45
学习了，明白了CMMI和敏捷的不同了；。

作者: ddqhf 时间: 2013-2-27 13:54

不想引起针锋相对的争吵。首先声明下没有看得非常仔细，不像review文档那种方式，说错勿怪。另外CMMI，本人 ...
omg 发表于 2013-2-25 22:41

这位同学，你太激动了！
如果你这帖子是独立于我的帖子在说的，那内容来说只有两处有问题（后面解说）。如果你这帖子是针对我的帖子在说的，我不得不说你确实的没看明白我的帖子！
1. 我没有任何地方说过敏捷是一种过程，而我个人本就不赞成把敏捷认为是一种过程（反倒是你在总结的时候还把敏捷说成“过程”了，这是其中一处）。本身敏捷就只是一些原则和实践结合起来的，我们既可以把它看成方法也可以把它看成是思想，而要真正实施敏捷，必然公司需要有敏捷所倡导的那些思想所充实的企业文化，否则如何叫量体裁衣？
同时，这里帮你修正一下你对CMMI的看法。CMMI完整的来说确实是重量级的、力求面面俱到，这是由于CMMI的定位所导致的，它需要通过面面俱到来覆盖各领域、各类型的项目，所以，表面上的臃肿必不可免。但具体到公司使用时，如何使用CMMI是公司要面临的第一大难题；其二，CMMI有明确的指示消除它的臃肿，这就是“裁剪”，在公司对CMMI进行吸纳优化后，得到了适合自己公司的流程，具体项目在使用的时候，则需要通过“裁剪”，来获取适合自己项目的流程，这是第二大难点。不得不说，在国内CMMI评估（注意是“阶段式的评估”，有想弄清楚的可以找我）的要求下，确实会给一些公司、项目造成不必要的负担。但如果公司不追求所谓的等级（仅限于“阶段式的等级”），那这些不必要的负担都是可以消除的。
2. “开发做测试，是做单元测试，自动化测试”，这一观点，是我们传统的软件开发里所持有的观点，因为传统的软件开发里是明确划分了开发、测试这样的角色。而敏捷里面，是倡导不分角色，职能交叉，所以要在这里来说什么“开发做测试，是做单元测试就显得不合时宜”，具体公司在实际操作时，是怎么分配职责的则根据公司实际来考虑，但弄明白为什么敏捷要求职能交叉，则是我们需要做的。这是我前面说的两点之其二。
3. 我的帖子全篇是在分析敏捷与CMMI，希望能给予大家对两者正确的认识。所以我没有详细的去介绍敏捷和CMMI，所以希望你不要指责我里面没有说“站立会议需要沟通遇到的障碍”，我是在分析，不是面面俱到的介绍。
4. 我写这篇帖子的目的，不是向大家介绍敏捷的目的，而是向大家探讨敏捷更深层次的原因。目的很多地方都有介绍，都知道是为了提高效率、提升质量。我只是希望大家在知道这些目的的前提下，能够去深入的看到敏捷是通过解决什么根本问题来达到的这些目的。只有知道了根本，我们才知道应该如何去运用敏捷，也才能更好的运作我们的项目。希望你能明白我说的道理。

作者: ddqhf 时间: 2013-2-27 14:00

过程的目的是为了让项目做得更好，而不是把项目“框”死。
愚人发表于 2013-2-25 14:24

QA的目的应运而生！呵呵

作者: ddqhf 时间: 2013-2-27 14:01

学习了，一切的模型都是为了解决现实问题提出的--------
没翅膀的飞鱼发表于 2013-2-25 17:32

是的，有因才有果嘛

作者: ddqhf 时间: 2013-2-27 14:07

回复 ddqhf

CMMI是经典，强调理论上的大而全；敏捷则是强调实用，丢掉不必要的流程束缚，充分发挥人员 ...
eagle8625 发表于 2013-2-25 18:14

我曾经做过这样一个对比，要开发一个楼盘，开发商都知道修房子肯定是需要先挖基坑、打地基，然后浇筑称重梁，接着完善内墙外墙、各种官网、装饰等。
但不同的开发商对于一个楼盘却有不同的打算。有的开发商整块地一起开发，有的开发商会给你分成1、2、3、4期来开发，甚至每期里面也会给你分批次交房。

那么，CMMI就相当于修建房屋的基本顺序。而敏捷就相当于开发商开发楼盘的一种方式。

作者: omg 时间: 2013-2-27 14:12
呵呵，不知道是谁激动了，谁没有明白。如果我是没有明白，那我水平有限，有待提高，加强苦修。

“敏捷是解决沟通方面的问题”——你的原帖的一个结论。你的通篇都在敏捷在沟通方面的事情。

我的回复在说明敏捷不只是解决沟通问题，而同样是在解决管理问题（通过敏捷的文化，价值观，已经前人的最佳实践，方法论）。回复里面也包含我对一些实践的目的的理解。

作者: ddqhf 时间: 2013-2-27 15:05

呵呵，不知道是谁激动了，谁没有明白。如果我是没有明白，那我水平有限，有待提高，加强苦修。

“敏捷是 ...
omg 发表于 2013-2-27 14:12

我本就是在向大家解释，为什么我说敏捷是为了解决沟通的问题而生的。

至于你前面所说的内容，我说了，单看你的回复，是没什么问题，只提出了两点 “我觉得” 需要修正的地方哈。

作者: 愚人 时间: 2013-2-27 16:41
呵呵，讨论的有点激烈，欢迎继续

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