2.3團隊組織關系

一個項目中的兩種角色安排的三種可能的關系，他們是：

1 產品負責人和技術主管是同一個人。這種方式非常容易應用在很小型的隊伍中，可能是三個或六個開發(fā)人員。在大型的項目中則不容易得到應用。原因有兩個：第一，同時具有管理技能和技術技能的人很難找到。思考者很少，實干家更少，思考者－實干家太少了。第二，大型項目中，每個角色都必須全職工作，甚至還要加班。對負責人來說，很難在承擔全部管理責任的同時，還能抽出時間進行技術工作。對技術主管來說，很難在保證設計的概念完整性，沒有任何妥協(xié)的前提下，擔任管理工作。

2 產品負責人作為總指揮，技術主管充當其左右手。這種方法有一些困難。很難在技術主管不參與任何管理工作的同時，建立在技術決策上的權威。顯然，產品負責人必須預先聲明技術主管的技術權威，在即將出現(xiàn)的絕大部分測試用例中，他必須支持后者的技術決定。要達到這一點，產品責任人和技術主管必須在基本的技術理論上具有相似觀點；他們必須在主要的技術問題出現(xiàn)之前，私下討論它們；產品責任人必須對技術主管的技術才能表現(xiàn)出尊重。

3 技術主管作為總指揮，產品負責人充當其左右手。這種組合可以使工作很有效。不幸的是它很少被應用。不過，它至少有一個好處，即項目經理可以使用并不很擅長管理的技術天才來完成工作。

2.4團隊組成

在一個大型項目中，軟件項目經理必須為成員良好的分工，組成有層次的結構。

系統(tǒng)結構師，從上至下地進行所有的設計。要使工作易于管理，必須清晰地劃分體系結構設計和實現(xiàn)之間的界線，系統(tǒng)結構師必須一絲不茍地專注于體系結構。

首席程序員。他親自定義功能和性能技術說明書，設計程序，編制源代碼，測試以及書寫技術文檔。

程序職員。他負責維護編程產品庫中所有團隊的技術記錄。

編輯、秘書。首席程序員負責產生文檔。而編輯進行分析和重新組織，提供各種參考信息和書目，對文檔多個版本進行維護以及監(jiān)督文檔生成的機制。

工具維護人員。測試人員。

3. 團隊交流

3.1手冊、或者書面規(guī)格說明

手冊是產品的外部規(guī)格說明，它描述和規(guī)定了用戶所見的每一個細節(jié)；同樣的，它也是結構師主要的工作產物。

隨著用戶和實現(xiàn)人員反饋的增加，規(guī)格說明中難以使用和難以構建實現(xiàn)的地方不斷被指出，規(guī)格說明也不斷地被重復準備和修改。然而對實現(xiàn)人員而言，修改的階段化是很重要的——在進度表上應該有帶日期的版本信息。

手冊不但要描述包括所有界面在內的用戶可見的一切，它同時還要避免描述用戶看不見的事物。后者是編程實現(xiàn)人員的工作范疇，而實現(xiàn)人員的設計和創(chuàng)造是不應該被限制的。體系結構設計人員必須為自己描述的任何特性準備一種實現(xiàn)方法，但是他不應該試圖支配具體的實現(xiàn)過程。

規(guī)格說明的風格必須清晰、完整和準確。用戶常常會單獨提到某個定義，所以每條說明都必須重復所有的基本要素，所以所有文字都要相互一致。這往往使手冊讀起來枯燥乏味，但是精確比生動更加重要。

3.2周例會

周例會由所有的結構師，加上硬件和軟件實現(xiàn)人員代表和市場計劃人員參與，由首席系統(tǒng)結構師主持。

會議中，任何人可以提出問題和修改意見，但是建議書通常是以書面形式，在會議之前分發(fā)。新問題通常會被討論一些時間。重點是創(chuàng)新，而不僅僅是結論。該小組試圖發(fā)現(xiàn)解決問題的新方法，然后少數解決方案會被傳遞給一個和幾個結構師，詳細地記錄到書面的變更建議說明書中。

接著會對詳細的變更建議做出決策。這會經歷幾個反復過程，實現(xiàn)人員和用戶會仔細地進行考慮，正面和負面的意見都會被很好地描述。如果達成了共識，非常好；如果沒有，則由首席結構師來決定。這需要花費時間，終所發(fā)布的結論是正式和果斷的。

這種會議的卓有成效是由于：
　1.每周交流一次。因此，大家對項目相關的內容比較了解，不需要額外培訓。
　2.上述小組十分睿智和敏銳，深刻理解所面對的問題，每個人都要承擔義務。
　3.當問題出現(xiàn)時，在界線的內部和外部同時尋求解決方案。
　4.正式的書面建議強制了決策的制訂，避免了會議草稿紀要方式的不一致。
　5.清晰地授予首席結構師決策的權力，避免了妥協(xié)和拖延。

3.3電話日志（交流日志，BBS等記錄）

隨著實現(xiàn)的推進，無論規(guī)格說明已經多么精確，還是會出現(xiàn)無數結構理解和解釋方面的問題。顯然有很多問題需要文字澄清和解釋，還有一些僅僅是因為理解不當。討論和解決，在BBS上做出記錄。問題的答案（對問題的認識或者想法記錄下來）必須是可以告知每個人的權威性結論。

3.4質量會議

項目經理好的朋友是他每天要面對的敵人——獨立的產品測試機構/小組。該小組根據規(guī)格說明檢查機器和程序，充當麻煩的代言人，查明每一個可能的缺陷和相互矛盾的地方。每個開發(fā)機構都需要這樣一個獨立的技術監(jiān)督部門，來保證其公正性。

4. 為變化組織架構

每個人被分派的工作必須是多樣的、富有拓展性的工作，從技術角度而言，整個團隊可以靈活地安排。

當系統(tǒng)發(fā)生變化時，管理結構也需要進行調整。管理人員和技術人才的能力給予培養(yǎng)，使管理人員和技術人才具有互換性。

管理人員需要參與技術課程，高級技術人才需要進行管理培訓。項目目標、進展、管理問題必須在人員整體中得到共享。