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 首发于51Testing软件测试论坛[软件质量管理]版块。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。