軟體開發中的交流問題-Adams Wang

Brooks在“貴族專制、民主政治和系統設計（Aristocracy, Democracy, and System Design）”一章中，一針見血地指出了成功軟體具有高度的概念一致性。“結構師難道不是新貴？……至於貴族專制統治的問題，必須回答 “是”或者“否”。就必須只能存在少數的結構師而言，答案是肯定的……”，《人月》中的體繫結構更加類似於現在的需求概念，而非現在所意義的體繫結構。不過，在具體的實踐中，需求和體繫結構依然應該由少數的人來承擔。這樣的觀點可能會引起爭議，但就個人觀點而言，軟體行業實際上是“精英行業”。高素質、具有豐富經驗的需求分析人員、結構師往往是軟體企業的核心骨幹人員，相應的一般編程人員相對的流動性會大一些。

從個人發展的角度，安安靜靜地作為一個螺絲釘彷彿不是這個時代精神。這個問題同企業與人之間的關係一樣，很難一言以蔽之。就具體的項目操作，理想情況是程式員較少地參加前期分析工作，由有經驗的同仁來負責，給出具有架構代碼程度的需求和架構產物。

在較早的項目中，有的一般編程人員不安於編碼實現，過早接觸於一些PM性質工作，以及項目壓力等其他因素，造成了代碼品質不高，使得架構的重用程度降低。而在另外公司的一個項目中，由於企業的文化，同事們嚴格按照分工進行開發，提高了品質。後者看似少了機會，但從長遠的角度看，大家對設計的瞭解更加透徹，對流程的理解更加深刻，為以後的發展打下了基礎。

同樣在這一章節中，Brooks提出了“在等待時，實現人員應該做什嗎？”的問題。他認為“首先，必須設定良好定義的時間和空間目標，……同時，在物理實現的層級，也有很多可以著手的工作。”實際項目中，早期的投入往往人員較少，一般15人月左右的項目，初期就2～3人，這其中包括了需求分析、設計人員，以及主程式員。主程式員會對系統有初步的瞭解，對系統開發採用的技術、工具、開發技巧進行研究，同時同PM一同負責搭建軟體工程環境和軟體開發的環境。這樣的安排，出現的一個問題是編程人員與分析設計人員的溝通。它需要大家通暢、自由的交流，經可能對開發達成共識，減少資訊的丟失。

項目交流的方法，Brooks就OS360開發經驗，在“貫徹執行（Passing the Word）”一章中，進行了具體的講解。如，會議與大會、多重實現、電話日誌等。就小型項目而言，如果不考慮異地開發的情況，較正式的組內會議可以安排在一周一次，即周例會的形式。另外，在裡程碑之處安排評審會議，以對開發的進展、對需求的實現以及專案計劃進行調整和修正。而對於異地開發，或者使用者不在本地的情形，則建議採用電話會議等形式，效果雖然不如本地開發好，不過有聊勝於無。 “為什麼巴比倫塔會失敗？（Why Did the Tower of Babel Fail?）”又對軟體開發中的交流問題進行了強調，指出了文檔是溝通的一種重要方式。後續的 “提綱挈領（The Documentary Hypothesis）”則用類比的方式闡述了如何定義軟體項目的文檔集合，“另外一面（The other face）”討論了程式文檔的一些形式。這些觀點對實際工作也具有指導意義，相應的Rational Suite中Requisite Pro工具使用參考中，推薦了軟體項目的參考文檔集合。在C++和Domino若干項目的實踐中，發現最小的文檔集合包括需求文檔（Software Requirement Specification）、專案計劃（Software Development Plan）、架構設計、設計項目說明。其中，專案計劃不僅僅是進度，而是從軟體的組態管理、生命週期、資源分派、風險分析、培訓等方面進行描述，這部分的內容往往不局限於單個項目，而是在同一種類型的項目中具有共性。因此，可以在不同項目中共用。

總而言之，Brooks對文檔的建議是“專案經理聰明的做法都是：立刻正式產生若干文檔作為自己的資料基礎，哪怕這些迷你文檔非常簡單。接著，……”以及“如果一開始就認識到它們的普遍性和重要性，那麼就可以將文檔作為工具友好地利用起來，而不會讓它成為令人厭煩的繁重任務。通過遵循文檔開展工作，專案經理能更清晰和快速地設定自己的方向。”

http://www.mmmbook.com/review/pratice.htm