當反思失敗的項目時，大部分責任都歸于軟件項目經(jīng)理、團隊成員和利益相關者之間的無效溝通。項目經(jīng)理都知道要填平項目成員之間的溝通斷層，并提供持續(xù)有效的溝通。對這一職責的重視程度有時會導致項目經(jīng)理反應過度。他們會分不清哪些溝通是重要的、具體的，哪些溝通看似內(nèi)容充實，但是卻對項目進展有百害而無一利。
為了解決這個問題，許多軟件開發(fā)人員正試圖采用一種更靈活、更敏捷的方式。敏捷方法的關鍵之處在于及時的溝通循環(huán)，使敏捷團隊能夠有效應對未預見的變化，并且快速地重新評估和設置優(yōu)先完成的項目功能。
敏捷項目經(jīng)理們?nèi)绾巫寽贤ㄗ龅胶喢鞫笠克麄兲岢咳铡?5分鐘站立”會議。這種會議要求開發(fā)人員講述自上次會議后他們完成的任務、“今天”計劃完成的任務以及在達成目標過程中他們預見的任何障礙?！罢玖h”有一定風險，因為它完全依賴于每個開發(fā)人員自我評估的準確度。有解決辦法嗎？為了使站立會議更有效，要結合使用一個能顯示測試結果的任務管理工具。工具對于項目基本代碼的狀況不會說謊，并且測試結果對開發(fā)人員的自我評估來說也是一個有價值的補充。提交已經(jīng)通過一系列測試的某個功能的報告數(shù)據(jù)，也為這個功能的狀態(tài)提供了更準確的描述。
例如，利用一種持續(xù)集成工具來描繪出進程的客觀圖像。這可以讓“站立會議”的溝通只包含必要成分：障礙報告（希望這已經(jīng)被任務管理工具捕捉到）和因邊緣案例、集成困難以及bug（缺陷）而造成的未能預見的發(fā)展情況。通過借助于一個全球共享的訪問工具反映這些“新發(fā)現(xiàn)”，開發(fā)人員可以獲得更精確的反饋。通常，在早期就可發(fā)現(xiàn)功能和任務之間存在著某些看不見的聯(lián)系。
一個典型的誤解就是同步溝通？總是比異步溝通有效。添加開發(fā)工具和簡短的異步溝通環(huán)路可以作為面對面溝通的有效輔助。
維基系統(tǒng)依據(jù)的是更廣泛的反饋，輕易地就能讓大家認識到項目開發(fā)進程的現(xiàn)實情況。這種系統(tǒng)還能夠及時地提供信息，并為所有利益相關者提供更高層次的溝通渠道，因為這些利益相關者可能對阻礙某項功能開發(fā)進度的底層技術細節(jié)不感興趣。相比之下，軟件開發(fā)人員對項目整體的認識可能會被每天技術工作的細節(jié)淹沒而逐漸變得模糊不清。維基系統(tǒng)可以讓所有參與者保持清楚的共識。只要讓信息溝通緊湊簡短且不談廢話，軟件項目經(jīng)理就能夠幫助避免溝通失敗，而這通常又是項目失敗的原因。項目經(jīng)理的職責和挑戰(zhàn)就是簡化每一個項目層次的反饋環(huán)路，使之更高效。
