日常开发和工作中会经常遇到沟通不畅的问题，"communication" 不论是在学术还是实践中都是一个很重要的议题。因为低效的沟通造成的开发事故有时候是灾难性的。
沟通的问题为认为本质上就是信息不对称。下面以日常沟通及会议沟通做一些浅显的讨论，并警戒自己在以后工作生活中做到有效的沟通。
一、 日常沟通
1. 明确问题
两个人讨论问题，如果A开口就是：
"昨天那个程序又挂了，你那有备份么？"
那么B的内心一定是：
"What a fucking question it is！"
先说A，A的沟通是低效的，甚至可以说是一句废话，因为这句话中最关键的信息被遗失了。
A内心的想法可能是，"昨天不是跟你说过这个程序的事吗，所以我跟你讨论这个挂掉的程序你应该是知道我在说什么啊"。
但是B不一定知道，他从昨天到今天处理了这么多事，即使昨天跟你一起处理过这个程序他也无法一下子反应过来你说的是什么。
实际上这里的不对称就是A在表达时默认一些信息是公共的，是你我都知道的，然而大部分时候，这些被默认的信息都是重要的，且"不公共的"。
如果A的表达换成"昨天那个unix时间戳转换程序我改了一下出了bug，你那还有之前的备份么"，可能B一下子就能get到你的点了。
这里要说一下，跟别人说明问题的时候一定要言简意赅。尽量用最少的语言去表达最重要的信息：
1. What is the problem？
2. How serious the problem is ？
3. What is the effect of this problem？
大家工作每天都很忙，要在有效的时间里传递最有效的信息。
在说明问题商讨方案的时候要把问题是什么说清楚，问题的严重性说清楚，问题的影响说清楚。
尽量不要把你发现问题的过程啰里啰嗦地讲给别人，"我是因为发现了***问题，然后发现***，最后我发现这个问题是****，所以我猜测这个问题是***"。 最开始沟通的时候这些描述是多余的。
先把目前遇到的问题明确。接下来再去详细说明问题的来源和过程，说明问题不是空穴来风。
2. Feedback
沟通中的反馈是非常重要的，根据谈话者的反馈来确定沟通的内容，能帮助我们提高效率。
如果A是任务的发布者，要主动确认任务接收者的理解是否与自己的意图相同，保证信息的对称性。任何默认彼此都知道的公共信息都是危险的。尽可能的把重要的信息传递出去，不管对方知不知道。
如果A是任务的接受者，要主动反馈自己对任务的理解确保与任务的发布者对任务有相同的认识。避免造成理解偏差，做南辕北辙的事。要重视开发中的需求再确认。
Double check could be applied everywhere. 不论是在需求，开发还是测试中，反向确认都是重要的。只有弥合了信息的不对称才能确保后面的路一马平川。
二、会议沟通
国内很多公司都开始向敏捷开发的路狂奔。但是我在工作的时候发现大家只是东施效颦，没有真正的去思考敏捷开发到底敏捷在哪里，更不要说正确应用了。
我这里以每天的例会为例说一下我对例会中沟通的敏捷的理解。也就是Scrum中的Scrum Daily Meeting。