決，而并非一擁而上。由一個人來進行問題的分解，其他人給予他所需要的支持，以提高效率和生產力。
2.1協作成本
需要協作溝通的人員的數量影響著開發(fā)成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果。所以并不是人越多越好，系統應該由盡可能少的人員來開發(fā)。
2.2成員差異
程序員最好的和最差的表現在生產率上平均為10：1;在運行速度和空間上具有5：1的驚人差異。
2.3團隊組織關系
一個項目中的兩種角色安排的三種可能的關系，他們是：
1）產品負責人和技術主管是同一個人。這種方式非常容易應用在很小型的隊伍中，可能是三個或六個開發(fā)人員。在大型的項目中則不容易得到應用。原因有兩個：
第一，同時具有管理技能和技術技能的人很難找到。思考者很少，實干家更少，思考者-實干家太少了。
第二，大型項目中，每個角色都必須全職工作，甚至還要加班。對負責人來說，很難在承擔全部管理責任的同時，還能抽出時間進行技術工作。對技術主管來說，很難在保證設計的概念完整性，沒有任何妥協的前提下，擔任管理工作。
2）產品負責人作為總指揮，技術主管充當其左右手。這種方法有一些困難。很難在技術主管不參與任何管理工作的同時，建立在技術決策上的權威。顯然，產品負責人必須預先聲明技術主管的技術權威，在即將出現的絕大部分測試用例中，他必須支持后者的技術決定。要達到這一點，產品責任人和技術主管必須在基本的技術理論上具有相似觀點;他們必須在主要的技術問題出現之前，私下討論它們;產品責任人必須對技術主管的技術才能表現出尊重。
3）技術主管作為總指揮，產品負責人充當其左右手。這種組合可以使工作很有效。不幸的是它很少被應用。不過，它至少有一個好處，即項目經理可以使用并不很擅長管理的技術天才來完成工作。
2.4團隊組成
在一個大型項目中，軟件項目經理必須為成員良好的分工，組成有層次的結構。
1）系統結構師，從上至下地進行所有的設計。要使工作易于管理，必須清晰地劃分體系結構設計和實現之間的界線，系統結構師必須一絲不茍地專注于體系結構。
2）首席程序員。他親自定義功能和性能技術說明書，設計程序，編制源代碼，測試以及書寫技術文檔。
3）程序職員。他負責維護編程產品庫中所有團隊的技術記錄。
4）編輯、秘書。首席程序員負責產生文檔。而編輯進行分析和重新組織，提供各種參考信息和書目，對文檔多個版本進行維護以及監(jiān)督文檔生成的機制。
5）工具維護人員。測試人員。
3.團隊交流
3.1手冊、或者書面規(guī)格說明
手冊是產品的外部規(guī)格說明，它描述和規(guī)定了用戶所見的每一個細節(jié);同樣的，它也是結構師主要的工作產物。隨著用戶和實現人員反饋的增加，規(guī)格說明中難以使用和難以構建實現的地方不斷被指出，規(guī)格說明也不斷地被重復準備和修改。然而對實現人員而言，修改的階段化是很重要的——在進度表上應該有帶日期的版本信息。
手冊不但要描述包括所有界面在內的用戶可見的一切，它同時還要避免描述用戶看不見的事物。后者是編程實現人員的工作范疇，而實現人員的設計和創(chuàng)造是不應該被限制的。體系結構設計人員必須為自己描述的任何特性準備一種實現方法，但是他不應該試圖支配具體的實現過程。規(guī)格說明的風格必須清晰、完整和準確。用戶常常會單獨提到某個定義