日常開發和工作中會經常遇到溝通不暢的問題，"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。
Scrum Daily Meetings are strictly time-boxed to 15 minutes. There are three questions that each team members need to answer:
1. What did you do yesterday?
2. What will you do today?
3. What is blocking progress?
關於daily meeting，所有的教課書都強調兩點，15分鍾時限的嚴格控制，三個問題的回答。
敏捷開發是一種源於經驗的科學理論，對日常會議作出時限的要求也是大量實踐的結果（當然也是結合團隊規模的結果）。如果一個團隊7個人的話，則平均每人個人說話兩分鍾。加上團隊成員間的交流互動，促成這15分鍾。但是現實中的日常會議經常演變成以下兩種：
1. 流水賬
有的同學喜歡把這一天細枝末節的事情都羅列的說一遍，諸如審核了誰誰的代碼，開發了啥啥功能，補充了什么什么文檔。這些內容冗長而乏味，既不能體現出項目的進度，也不能使其他隊員參與到討論當中，更別說回答三個問題了。這樣的報告基本上就是在浪費時間，更別說敏捷了。
2. 技術及方案的討論
經常在日常會議的時候有的同學喜歡把今天寫了一個什么算法，用了什么技術拿出來討論一下，幾番討論就變成了爭論不休，而且這樣的討論，在這種會議中即無法給出合理的方案（會議時間短，討論者之間對問題和進度的理解不同，無法達成一致），也說不清楚目前問題的所以然，如果別得同事與這個問題無關，就變成了團隊中某幾個人的秀場，其他人無聊且不耐煩的等待了。
私以為，daily meeting 是以貫徹項目進度為導向的，團隊成員聚在一起討論是明確項目的進展如何，有哪些不可抗力的阻撓（eg：時間規划，硬件設備，資金，人手等等），需要團隊提供幫助的，以及一些分工合作上的交流。
實際上，敏捷團隊中有一個重要的角色是Scrum Master，這個角色有一個重要的職責就是控制會議時間，使會議變的高效。
在團隊成員的日常總結空泛時，應該主動詢問，今天重要的進展是什么，困難是什么，其他人如何配合你完成工作，接下來的計划和方案是什么。
如果團隊中個別成員陷入了與會議主題無關的討論時，應及時終止爭論，切回項目進展的正題，對於具體的方案，諸如算法，開發細節的討論應該會后安排時間討論。
敏捷開發中的日常會議可以提供給團隊更加清晰的項目進展，幫助團隊合理的分配和優化資源（時間，人手，硬件設備等等），以此來提高團隊的效率。
其實，在工作中我發現，Daily Meeting 中團隊成員間的討論和互動也可以很好的培養團隊凝聚力的，以及成員之間的工作默契等等。
我在這里反思一下：
我最近工作中處理一些數據，但是機器不夠用，開會的時候缺沒有把自己的困難說出來，以至於一直進度緩慢，問題和困難也沒有得到及時解決。沒有機器怎么辦？借呀！