传统的软件开发沟通过程中，沟通都是阶段式的。需求结束之后，进行需求的宣讲和评审。设计，开发也一样。因为接受新东西需要一个过程，如果在一个点上沟通，沟通的频率得不到保障。对需求的理解很难达到理想的程度。

其实敏捷软件开发早就提出了解决方案，坐在一起，强调个体和交流。信息辐射器 ，Big Visible Chart 等等。我们需要增加沟通的频率，不一定要等产物完全确定下来再进行沟通，而是部分确定下来就可以沟通。好软件是重构出来的，好文章是改出来的，好的沟通效率是通过多次沟通，渐进实现的。这个和人对新事物的认识过程有关，通过不断的反馈，逐渐构建人脑对事物的认知地图。

还有一个需要注意的是开发人员的宣讲。一般情况下，需求和设计的宣讲都是有的，开发人员都是参加的。但是，开发人员虽然参加了会议，但是不能保证他真的对会议内容，要开发的东西有了比较清楚的了解。解决办法就是，让每个开发人员讲解自己的东西，能给别人讲明白的，肯定自己也是理解的比较透彻的。同时，开发人员也锻炼了自己的演讲能力，我一直认为，作为一个技术人员，演讲能力非常重要。关于沟通模式，可以参考我的另外一篇文章沟通模式和节奏 。

一次有效的沟通要实现有一个节奏，就是需要不断的反馈。比如“乒乓乒乒乓乒乓乒乒乓乒乓”，而不是“乒乒乒乒乒乒乒乒乒乒乒乒乓”，只是一方在讲，另一方没有任何反馈，这不叫沟通，叫填鸭。讲出你自己的理解和需要是你职责的一部分，否则就是不负责任的表现。哈哈，有点上纲上线了，just relax。渐进式沟通如下图：