浅谈敏捷与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也罢，其目的都是为了降低项目失败的风险，提高项目效率及成功率。只是途径一个是解决沟通的问题，另一个是解决项目管理的问题而已。
从另一个角度理解则是，二者都不是银弹，并不能保证项目一定成功，只是提高其成功的概率而已。