在當今快節奏的工作環境中，軟件開發人員正面臨著一種痛苦的兩難境地：他們需要應付加速軟件開發進程的持續壓力，這種對速度的要求會導致溝通失敗；同時還要面對由此帶來的項目和系統開發的困難。由于業務需求不會在短期內改變，所以快速開發項目經理必須加倍努力地進行有效和高效的溝通。
在某些情況下，快速開發表示一系列的特殊軟件工程實踐，其目的在于正確選擇采用縮小范圍和增加資源以減少開發時間的方法，此類方法包括極限編程（XP），應用程序快速開發（RAD）和快速原型法等。在另外的情況下，快速開發是用來推銷縮短軟件開發周期的工具、新方法或研討會的流行用語。無論你認同哪種定義，當項目團隊走捷徑并且試圖決定何處讓步以期完成緊張的計劃時，進度壓力會導致災難發生。
“當我聽到快速開發的時候，我立即想到，開發團隊希望通過忽略掉關鍵步驟的方法來簡化項目法則。”戴夫·弗格森如是說，他是美國加州El Dorado Hills地區的DST Output公司電子產品開發及實施部門的副總裁。他們公司的開發工作著重強調于軟件工程和項目管理。
在被問及分享一些快速開發的名言時，丹麥獨立項目管理咨詢師本特·埃澤森引用了羅馬皇帝奧古斯塔斯的話：“Festina lente”。此句拉丁文的意思是“從容趕急”。關鍵是避免恐慌和由此引起的混亂。這需要在項目開始時花時間建立健康的習慣。
緊張的時間限制會遏制溝通。英國倫敦Sapient Corp公司的技術總監格雷厄姆·奧克斯建議：“快速開發的溝通問題與其他方法一樣存在，但是犯錯誤的空間更少，而且有很大的機會使事情在一個星期內失去控制。”
奧克斯指出，項目團隊受到壓力時會不合時宜地犧牲流程和交付物來換取速度。他說：“按需要適當地調整流程，但不要因為時間原因而單純拋棄評審和其他質量保證流程。因為缺陷同樣浪費時間。”
謹慎地交接
在用戶、獲取需求的分析師、設計師和解釋實現需求的開發人員之間的交接過程中，信息會頻繁地丟失。“獲取需求時要全面，并且要保證用戶參與到設計評審里。”馬代爾·霍爾說，他是美國加州薩克拉門托市Catalysis集團公司的咨詢項目經理。
專業的開發流程受益于客戶與開發人員之間的良好溝通。美國北卡來羅納州達拉漠市Pugh-Killeen Associates公司的軟件顧問肯·皮尤指出：“要使用極限編程法的話，客戶必須在開發現場，這樣在需要的時候，客戶會解釋需求的細節。如果技術問題與實現一個特殊需求相關，客戶和開發人員會一起權衡以找到一個解決方案。”
很不幸的是，許多項目發起人并不理解這項規則和成功執行這些過程所需的資源許諾。使用極限編程來構建系統代價不菲，但如果執行得當，它可以縮短開發時間。邀請一些知識淵博的客戶成為開發團隊的組成部分以促進溝通的做法會使大部分項目預算超支，但結果是可以預測的。
美國科羅拉多州恩格爾伍德市govONE Solutions公司的產品交付部門總監雷恩·湯普森認為：“許多快速開發方法通過隔離開發團隊來提高速度。但問題在于“成功”的定義。如果成功是指在規定的時間內交付系統產品，那許多團隊或許是成功的。如果成功是指交付一個可用的系統產品，那些成功可能變成多是瑕瑜互現。”
湯普森建議，在團隊上下建立公共的視角是異常重要的。“在長期的項目里，有必要保持成員的士氣高昂。在快速項目里，這有兩個目的：其一，當團隊在惡劣環境下長時間工作時維持他們的士氣；其二，有效地確保團隊向著公認的項目結尾前進。團隊認識到這些視角有助于他們理解他們的角色和分歧所在。”
應用程序快速開發法在需求不明確時被廣泛應用，在此情況下，客戶的參與也非常關鍵。皮尤認為：“使用應用程序快速開發法時，通常沒有足夠的時間或知識來創建一份詳細需求說明書。終產品可能基于在開發過程中學習到的東西。既然需求不確定，那么開發人員和客戶必須一起工作來開發產品。”
湯普森認為快速開發法本身很少能導致工作更快地完成。相反，產生大價值的那部分系統的開發工作會更加高效。他說：“我想，當人們把快速開發作為一項技術實踐來對待時，他們誤會了關鍵問題。如果你揭開快速開發背后的故事，開發的重點在于將工作的耗時固定，然后控制范圍以適應固定的時間。通過理解整體規劃和自己的工作如何融入整體，上述說法可以實現，此外，還要進行經常性地溝通，當威脅到時間的事務發生時，設定期望值亦為必要。”
快速開發的成功可以部分地歸功于開發團隊的小型化，開發人員和客戶在同一地點工作并關注于手頭的事情，這樣會自然而然地將溝通的挑戰減至小。
謹慎但不乏靈活地規劃和開發
像需求規范、架構規范和詳細設計等工作成果用來記錄復雜的思想，這樣它們可以經過評審以確保明確一致，然后會被提上議案討論。當進度的高壓導致工作內容不明確時，誤解會蜂擁而至。
為了避免返工，開發人員應頂住壓力以完成那些相對簡單的部分直到整體規劃得以清晰定義。羅伯特·盧如是說，他是薩克拉門托市的加州政府的一名程序開發經理。盧描述了近的一個開端困難的項目，此項目目的是通過互聯網提交客戶數據，他解釋道：“我們獲得的重要的經驗是盡早的開始著手開發架構規范，這樣，此后劃分系統時，人們會清楚各部分之間的相互關聯。”
這需要訓練，很重要的問題是，在開始時花時間記錄那些在開發流程和交付物的質量標準上達成的共識，并且在質量標準被準確無誤的達成之前抵制住宣稱“完成”交付物的誘惑。
Sapient公司的格雷厄姆·奧克斯領導了成功的快速開發項目的同時，對溝通和計劃做出了正確的決定。為了取得成功，他給出如下建議：
結構化的計劃。只有當一份完善的計劃存在時，每日的進展匯報才會有比對的標準。狀態周報需要有完整定義的結構，這樣可以迅速的完成周報而不致遺漏要點。
高透明度。Sapient采用了項目作戰室來確保所有計劃的高透明度和可獲得性，包括高層計劃、中層計劃、每日計劃、風險列表、項目總目標、標注了負責人和時限的待完成事項列表和進度度量標準。
頻繁但簡短的溝通。Sapient每天會有站立進行的進展會議，這種會議不會超過15分鐘，每位與會成員針對每日計劃來匯報進展。
清晰、公認的目標。人們在不工作時會做出很多決定，但他們必須知道他們自己的項目難題如何影響整體目標。
一項有挑戰性的溝通問題是創建和維持關鍵干系人和項目發起人對開發流程的共識。在開發過程中提供可見的和易理解的里程碑是個關鍵，這樣發起人和干系人會對進展有所了解。這些方法有助于管理他們的期望并有利于事務和進展的溝通。
團隊如是說
以下提及的是有助于促進溝通的團隊組織和管理的一些基本指導：
保持團隊小型化。針對完善定義的子系統工作的四到五名成員的規模能夠促進溝通。
迅速處理問題型員工。那些不能或不愿成為團隊一部分的成員會迅速地造成比他們本身價值浪費多很多的士氣問題。
避免使用兼職人員。與其他項目共享人員會使成員同時兼顧太多的工作，而兩個項目都會遇到問題。嘗試獲取項目所需要的全職員工。
避免通過添加開發人員來解決進度問題。如果項目落后于進度目標，不要試圖向現有團隊加人。團隊重新定位和吸收新成員的代價很少會帶來短期的進度跟進。
安排團隊的座位。開發團隊要設置在同一座建筑物、同一層、同一區域來促進評審和詢問。為團隊準備的一間小會議室的確是一個有利的條件。
作者簡介：Payson Hall是美國加州薩克拉門托市Catalysis集團公司的顧問系統工程師和項目管理顧問。Hall在北美和歐洲的公共和私營部門里的軟硬件系統集成項目中有20年的從業經驗。
