這些研究表明，效率高和效率低的實施者之間個體差異非常大，經常能夠達到數量級的水平。

—— Sackman,Erikson和Grant^[1]

These studies revealed large individual differences between high and low performers, often by an order of magnitude.

SACKMAN, ERIKSON, AND GRANT¹

在計算機領域的會議中，常常聽到年輕的軟件經理聲稱，他們喜歡由一流人才組成的小型、精干的隊伍，而不是那些幾百人的大型團隊，這里的“人”當然暗指平庸的程序員。其實我們也經常有相同的看法。

但這種幼稚的觀點回避了一個很困難的問題—— 如何在有意義的進度安排內創(chuàng)建大型的系統(tǒng)？那么就讓我們現在來仔細討論一下這個問題的各個方面。

問題

軟件經理很早就認識到優(yōu)秀程序員和較差程序員之間生產率的差異，但實際測量出的差異還是令我們所有的人吃驚。 在他們的一個研究中，Sackman、Erikson和Grant曾對一組具有經驗的程序人員進行測量。在該小組中，最好的和最差的表現在生產率上平均為 10∶1；在編程速度和空間上具有5∶1的驚人差異！簡言之，20 000美元/年的程序員的生產率可能是10 000美元/年的程序員的10倍。反之亦然。數據顯示，經驗和實際的表現沒有相互聯系(我懷疑這種現象是否普遍成立)。

我常常重復這樣的一個觀點，需要協作溝通的人員數量影響著開發(fā)成本，因為成本的主要組成部分是相互的溝通和交 流，以及更正溝通不當所引起的不良結果(系統(tǒng)調試)。這一點，也暗示系統(tǒng)應該由盡可能少的人員來開發(fā)。實際上，絕大多數大型編程系統(tǒng)的經驗顯示出，一擁而 上的開發(fā)方法是高成本的、速度緩慢的、低效的，開發(fā)出的是無法在概念上進行集成的產品。OS/360、Exec 8、Scope 6600、Multics、TSS、SAGE等等—— 這個列表可以不斷地繼續(xù)下去。

得出的結論很簡單：如果在一個200人的項目中，有25個最能干和最有開發(fā)經驗的項目經理，那么開除剩下的175名程序員，讓項目經理來編程開發(fā)。

現在我們來驗證一下這個解決方案。一方面，這個開發(fā)隊伍不是通常所說的不超過10個人的、理想的小型精干的隊伍，該團隊的規(guī)模如此之大，以至于至少需要兩個層級的管理，或者大約5名管理人員。另外，它需要額外的財務、人員、空間、文秘和機器操作方面的支持。

另一方面，如果采用一擁而上的開發(fā)方法，那么原有的200人的隊伍仍然不足以開發(fā)真正的大型系統(tǒng)。例如，在 OS/360項中，當項目進行到頂峰時，有超過1?000人在為它工作—— 程序員、文檔編制人員、操作人員、職員、秘書、管理人員、支持小組等等。從1963年到1966年，設計、編碼和文檔工作花費了大約5 000個人年。如果人月可以等量置換的話，我們所假設的200人隊伍需要25年的時間，才能使產品達到現有的水平。

這就是小型、精干隊伍概念上的問題：對于真正意義上的大型系統(tǒng)，它太慢了。設想OS/360的工作由一個小 型、精干的團隊來解決，譬如一個10人團隊。作為一個尺度，假設他們都非常能干，比一般的編程人員在編程和文檔方面的生產率高7倍。 同時假設OS/360原有開發(fā)人員是一些平庸的編程人員(這與實際情況相差很遠)。同樣作為一個尺度，假設另一個生產率的改進因子提高了7倍，因為較小的 隊伍所需的溝通和交流較少。同時假設同樣的隊伍完成的是同樣的工作。那么，5 000/(10×7×7)= 10，他們需要10年來完成5 000人年的工作。一個產品在最初設計的10年后才出現，還有人會對它感興趣嗎？或者它是否會隨著軟件開發(fā)技術的快速進步，而顯得過時呢？

這種進退兩難的境地是非常殘酷的。對于效率和概念的完整性來說，最好由少數干練的人員來設計和開發(fā)，而對于大型系統(tǒng)，則需要大量的人手，以使產品能在時間上滿足要求。如何調和這兩方面的矛盾呢？

Mills的建議

Harlan Mills的提議提供了一個嶄新的、創(chuàng)造性的解決方案^{[2, 3]}。Mills建議大型項目的每一個部分由一個團隊解決，但是該隊伍以類似外科手術的方式組建，而并非一擁而上。也就是說，同每個成員截取問題某個部分的做法相反，由一個人來完成問題的分解，其他人給予他所需要的支持，以提高效率和生產力。

簡單考慮一下，如果上述概念能夠實施，似乎它可以滿足迫切性的需要。很少的人員被包含在設計和開發(fā)中，其他許 多人來進行工作的支持。它是否可行呢？誰是編程隊伍中的麻醉醫(yī)生和護士，工作如何劃分？讓我們繼續(xù)使用醫(yī)生的比喻：如果考慮所有可能想到的工作，這樣的隊 伍應該如何運作？

外科醫(yī)生。Mills稱之為首席程序員。他親自定義功能和性能技術說明書，設計程序，編制源代碼，測試以及書 寫技術文檔。他使用例如PL/I的結構化編程語言，擁有對計算機系統(tǒng)的訪問能力；該計算機系統(tǒng)不僅能進行測試，還存儲程序的各種版本，以允許簡單的文件更 新，并對他的文檔提供文本編輯能力。首席程序員需要極高的天分、十年的經驗和應用數學、業(yè)務數據處理或其他方面的大量系統(tǒng)知識和應用知識。

副手。他是外科醫(yī)生的后備，能完成任何一部分工作，但是相對具有的經驗較少。他的主要作用是作為設計的思考 者、討論者和評估人員。外科醫(yī)生試圖和他溝通設計，但不受到他建議的限制。副手經常在與其他團隊討論有關功能和接口問題時代表自己的小組。他需要詳細了解 所有的代碼，研究設計策略的備選方案。顯然，他充當外科醫(yī)生的保險機制。他甚至可能編制代碼，但對代碼的任何部分，不承擔具體的開發(fā)職責。

管理員。外科醫(yī)生是老板，他必須在人員、薪酬、辦公空間等方面具有決定權，但他決不能在這些事務上浪費任何時 間。因而，他需要一個控制財務、人員、工作地點和辦公設備的專業(yè)管理人員，該管理員充當與組織中其他管理機構的接口。Baker建議僅在項目具有法律、合 同、報表和財務方面的需求時，管理員才具有全職責任。否則，一個管理員可以為兩個團隊服務。

編輯。外科醫(yī)生負責文檔的生成—— 出于最大透明度的考慮，他必須創(chuàng)建各種文檔。無論是對內部描述還是外部描述。而編輯根據外科醫(yī)生的草稿或者口述，進行分析和重新組織，提供各種參考信息和書目，對多個版本進行維護，并監(jiān)督文檔生成的機制。

兩個文秘。管理員和編輯每個人需要一個文秘。管理員的文秘負責項目的協作一致和非產品文件。

程序職員。他負責維護編程產品庫中所有團隊的技術記錄。該職員接受文秘性質的培訓，承擔機器碼文件和可讀文件的相關管理責任。

所有的計算機輸入匯集到這個職員處。如果需要，他會對它們進行記錄或者標識。輸出列表會提交給程序職員，由他進行歸檔和編制索引。另外，他負責將任何模型的最新運行情況記錄在狀態(tài)日志中，而所有以前的結果則按時間順序進行歸檔保存。

Mills概念的真正關鍵是“從個人藝術到公共實踐”的編程觀念轉換。它向所有的團隊成員展現了所有計算機的運行和產物，并將所有的程序和數據看作是團隊的所有物，而非私人財產。

程序職員的專業(yè)化分工，使程序員從文書等雜事中解放出來，同時還可以對那些經常被忽視的雜事進行系統(tǒng)整理，確保了它們的質量，并強化了團隊最有價值的財富—— 工作產品。上述概念顯然考慮的是批處理程序。當使用交互式終端，特別是在沒有紙張輸出的情況下，程序職員的職責并未消失，只是有所更改。他會記錄小組程序和私有工作拷貝之間的更新，依然控制所有程序的運行，并使用自己的交互式工具來控制產品逐步增長的完整性和有效性。

工具維護人員。現在已經有很多文件編輯、文本編輯和交互式調試等工具，因此團隊很少再需要自己的機器和機器操 作人員。但是這些工具使用起來必須毫無疑問地具備令人滿意的反應和可靠性。外科醫(yī)生則是對這些工具的服務是否充分可用的唯一評判人員。他需要一個工具維護 人員，保證所有基本服務的可靠性，以及承擔團隊成員所需要的特殊工具(特別是交互式計算機服務)的構建、維護和升級責任。即使已經擁有非常卓越的、可靠的 集中式服務，每個團隊仍然要有自己的工具維護人員。因為他的工作是檢查他的外科醫(yī)生所需要的工具，而不是其他團隊的需要。工具維護人員常常要開發(fā)一些實用 程序、編制具有目錄的函數庫以及宏庫。

測試人員。外科醫(yī)生需要大量合適的測試用例，用來對他所編寫的工作片段，以及對整個工作進行測試。因此，測試人員既是為他的各個功能設計系統(tǒng)測試用例的對手，同時也是為他的日常調試設計測試數據的助手。他還負責計劃測試的步驟和為單元測試搭建測試平臺。

語言專家。隨著Algol語言的出現，人們開始認識到，在大多數計算機項目中，總有一兩個樂于掌握復雜編程語 言的人。這些專家非常有幫助，很快大家會向他咨詢。這些天才不同于外科醫(yī)生，外科醫(yī)生主要是系統(tǒng)設計者以及考慮系統(tǒng)的整體表現。而語言專家則尋找一種簡 潔、有效的使用語言的方法來解決復雜、晦澀或者棘手的問題。他通常需要對技術進行一些研究(2~3天)。通常一個語言專家可以為兩個到三個外科醫(yī)生服務。

以上就是如何參照外科手術隊伍對10人的編程團隊進行專業(yè)化的角色分工。

如何運作

文中定義的開發(fā)團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業(yè)人士在解決問題，而系統(tǒng)是一個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。

要特別注意傳統(tǒng)的兩人隊伍與外科醫(yī)生-副手團隊架構之間的區(qū)別。首先，傳統(tǒng)的隊伍將工作進行劃分，每人負責一部分工作的設計和實現。在外科手術團隊中，外科醫(yī)生和副手都了解所有的設計和全部的代碼。這節(jié)省了空間分配、磁盤訪問等的勞動量，同時也確保了工作概念上的完整性。

第二，在傳統(tǒng)的隊伍中大家是平等的，出現觀點的差異時，不可避免地需要討論和進行相互的妥協和讓步。由于工作 和資源的分解，不同的意見會造成策略和接口上的不一致，例如誰的空間會被用作緩沖區(qū)，而事實上最終它們必須整合在一起。而在外科手術團隊中，不存在利益的 差別，觀點的不一致之處可以由外科醫(yī)生單方面來統(tǒng)一。這兩種團隊組建上的差異—— 對問題不進行分解和上下級的關系—— 使外科手術隊伍可以達到客觀的一致性。

另外，團隊中剩余人員職能的專業(yè)化分工是高效的關鍵，它使成員之間采用非常簡單的交流模式成為可能，如圖3-1所示。

Baker的文章^[3]提出了專一的、小規(guī)模的測試隊伍。在那種情況下，它能按照所預期的進行運作，并具有良好的效果。

圖3-1  10人程序開發(fā)隊伍的溝通模式

團隊的擴建

就目前情況而言，還不錯。然而，現在所面臨的問題是如何完成5?000個人年的項目，而不是20或30個人年 規(guī)模的系統(tǒng)。如果整個工作能控制在范圍之內，10人的團隊無論如何組織，總是比較高效的。但是，當我們需要面對幾百人參與的大型任務時，如何應用外科手術 團隊的概念呢？

擴建過程的成功依賴于這樣一個事實，即每個部分的概念完整性得到了徹底的提高—— 決定設計的人員是原來的1/7或更少。所以，可以讓200人去解決問題，而僅僅需要協調20個人，即那些“外科醫(yī)生”的思路。

對于協調的問題，還是需要使用分解的技術，這在后續(xù)的章節(jié)中會繼續(xù)進行討論。在這里，可以認為整個系統(tǒng)必須具 備概念上的完整性，要有一個系統(tǒng)結構師從上至下地進行所有的設計。要使工作易于管理，必須清晰地劃分體系結構設計和實現之間的界線，系統(tǒng)結構師必須一絲不 茍地專注于體系結構。總的說來，上述的角色分工和技術是可行的，在實際工作中，具有非常高的效率。