[討論]人月神話--外科手術式團隊

看板Programming作者ggg12345 (ggg)時間18年前 (2007/06/09 23:30)推噓2(2推 0噓 1→)

留言3則, 2人參與討論串1/1

各位覺得人月神話作者 Brooks 提出的開發團隊組成與運作是可行的嗎 ? 台灣有那家公司採用類似的作法 ? 作者非常強調客戶需求, 架構規劃者, 編程設計者能適時維持概念的一體性 (conceptual integrity), 因此需要有效的溝通與裁決. ========================================================================== 外科手術隊伍（The Surgical Team）這些研究表明，效率高和效率低的實施者之間具體差別非常大，經常達到了數量級的水平。 - SACKMAN, ERIKSON和GRANT1 These studies revealed large individual differences between high and low performers, often by an order of magnitude. - SACKMAN, ERIKSON, AND GRANT1 在計算機領域的會議中，常常聽到年輕的軟件經理聲稱他們喜歡由頭等人才組成的小型、精幹的隊伍，而不是那些幾百人的大型團隊，這裏的"人"當然暗指平庸的程序員。其實我們也經常有相同的看法。但這種幼稚的觀點回避了一個很困難的問題--如何在有意義的時間進度內創建大型的系統？那麼就讓我們現在來仔細討論一下這個問題的每一個方面。問題軟件經理很早就認識到優秀程序員和較差的程序員之間生產率的差異，但實際測量出的差異還是令我們所有的人吃驚。在他們的一個研究中，Sackman、Erikson和Grand 曾對一組具有經驗的程序人員進行測量。在該小組中，最好的和最差的表現在生產率上平均為10:1；在運行速度和空間上具有5:1的驚人差異！簡言之，$20,000/年的程序員的生產率可能是$10,000/年程序員的10倍。數據顯示經驗和實際的表現沒有相互聯繫（我懷疑這種現象是否普遍成立。）我常常重複這樣的一個觀點，需要協作溝通的人員的數量影響著開發成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果（系統調試）。這一點，也暗示系統應該由盡可能少的人員來開發。實際上，絕大多數大型編程系統的經驗顯示出，一擁而上的開發方法是高成本的、速度緩慢的、不充分的，開發出的是無法在概念上進行集成的產品。OS/360、Exec 8、Scope 6600、Multics、 TSS、SAFE等等--這個列表可以不斷地繼續下去。得出的結論很簡單：如果一個200人的項目中，有25個最能幹和最有開發經驗的項目經理，那麼開除剩下的175名程序員，讓項目經理來編程開發。現在我們來驗證一下這個解決方案。一方面，原有的開發隊伍不是理想的小型強有力的團隊，因為通常的共識是不超過10個人，而該團隊規模如此之大，以至於至少需要兩層的管理，或者說大約5名管理人員。另外，它需要額外的財務、人員、空間、文秘和機器操作方面的支持。另一方面，如果採用一擁而上的開發方法，那麼原有200人的隊伍仍然不足以開發真正的大型系統。例如，考慮OS/360項目。在頂峰時，有超過1000人在為它工作--程序員、文檔編制人員、操作人員、職員、秘書、管理人員、支持小組等等。從1963年到1966 年，設計、編碼和文檔工作花費了大約5000人年。如果人月可以等量置換的話，我們所假設的200人隊伍需要25年的時間，才能使產品達到現有的水平。這就是小型、精幹隊伍概念上的問題：對於真正意義上的大型系統，它太慢了。設想 OS/360的工作由一個小型、精幹的團隊來解決。譬如10人隊伍。作為一個尺度，假設他們都非常厲害，比一般的編程人員在編程和文檔方面的生產率高7倍。假定OS/360原有開發人員是一些平庸的編程人員（這與實際的情況相差很遠）。同樣，假設另一個生產率的改進因子提高了7倍，因為較小的隊伍所需較少的溝通和交流。那麼，5000/（10 X 7 X 7）= 10，他們需要10年來完成5000人年的工作。一個產品在最初設計的10年後才出現，還有人會對它感興趣嗎？或者它是否會隨著軟件開發技術的快速進步，而顯得過時呢？這種進退兩難的境地是非常殘酷的。對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發，而對於大型系統，則需要大量的人手，以使產品能在時間上滿足要求。如何調和這兩方面的矛盾呢？ Mills的建議 Harlan Mills的提議提供了一個嶄新的、創造性的解決方案(2，3)。Mills建議大型項目的每一個部分由一個團隊解決，但是該隊伍以類似外科手術的方式組建，而並非一擁而上。也就是說，同每個成員截取問題某個部分的做法相反，由一個人來進行問題的分解，其他人給予他所需要的支持，以提高效率和生產力。簡單考慮一下，如果上述概念能夠實施，似乎它可以滿足迫切性的需要。很少的人員被包含在設計和開發中，其他許多人來進行工作的支持。它是否可行呢？誰是編程隊伍中的麻醉醫生和護士，工作如何劃分？讓我們繼續使用醫生的比喻：如果考慮所有可能想到的工作，這樣的隊伍應該如何運作。外科醫生。 Mills稱之為首席程序員。他親自定義功能和性能技術說明書，設計程序，編制源代碼，測試以及書寫技術文檔。他使用例如PL/I的結構化編程語言，擁有對計算機系統的訪問能力；該計算機系統不僅僅能進行測試，還存儲程序的各種版本，以允許簡單的文件更新，並對他的文檔提供文本編輯能力。首席程序員需要極高的天分、十年的經驗和應用數學、業務數據處理或其他方面的大量系統和應用知識。副手。他是外科醫生的後備，能完成任何一部分工作，但是相對具有較少的經驗。他的主要作用是作為設計的思考者、討論者和評估人員。外科醫生試圖和他溝通設計，但不受到他建議的限制。副手經常在與其他團隊的功能和接口討論中代表自己的小組。他需要詳細瞭解所有的代碼，研究設計策略的備選方案。顯然，他充當外科醫生的保險機制。他甚至可能編制代碼，但針對代碼的任何部分，不承擔具體的開發職責。管理員。(Administrator) 外科醫生是老闆，他必須在人員、加薪等方面具有決定權，但他決不能在這些事務上浪費任何時間。因而，他需要一個控制財務、人員、工作地點安排和機器的專業管理人員，該管理員充當與組織中其他管理機構的接口。Baker建議僅在項目具有法律、合同、報表和財務方面的需求時，管理員才具有全職責任。否則，一個管理員可以為兩個團隊服務。編輯。外科醫生負責產生文檔--出於最大清晰度的考慮，他必須書寫文檔。對內部描述和外部描述都是如此。而編輯根據外科醫生的草稿或者口述的手稿，進行分析和重新組織，提供各種參考信息和書目，對多個版本進行維護以及監督文檔生成的機制。兩個秘書。管理員和編輯每個人需要一個秘書。管理員的秘書負責項目的協作一致和非產品文件。程序職員。他負責維護編程產品庫中所有團隊的技術記錄。該職員接受秘書性質的培訓，承擔機器碼文件和可讀文件的相關管理責任。所有的計算機輸入彙集到這個職員處。如果需要，他會對它們進行記錄或者標識。輸出列表會提交給程序職員，由他進行歸檔和編制索引。另外，他負責將任何模型的最新運行情況記錄在狀態日誌中，而所有以前的結果則按時間順序進行歸檔保存。 Mills概念的真正關鍵是"從個人藝術到公共實踐"的編程觀念轉換。它向所有的團隊成員展現了所有計算機的運作和產物，並將所有的程序和數據看作是團隊的所有物，而非私人財產。程序職員的專業化分工，使程序員從書記的雜事中解放出來，同時還可以對那些雜事進行系統整理，確保了它們的質量，並強化了團隊最有價值的財富--工作產品。上述概念顯然考慮的是批處理程序。當使用交互式終端，特別是在沒有紙張輸出的情況下，程序職員的職責並未消失，只是有所更改。他會記錄小組程序和私有工作拷貝之間的更新，依然控制所有程序的運行，並使用自己的交互式工具來控制產品逐步增長的完整性和有效性。工具維護人員。現在已經有很多文件編輯、文本編輯和交互式調試等工具，因此團隊很少再需要自己的機器和機器操作人員。但是這些工具使用起來必須毫無疑問地令人滿意，而且需要具備較高的可靠性。外科醫生則是這些工具、服務可用性的唯一評判人員。他需要一個工具維護人員，保證所有基本服務的可靠性，以及承擔團隊成員所需要的特殊工具（特別是交互式計算機服務）的構建、維護和升級責任。即使已經擁有非常卓越的、可靠的集中式服務，每個團隊仍然要有自己的工具人員。因為他的工作是檢查他的外科醫生所需要的工具。工具維護人員常常要開發一些實用程序、編制具有目錄的過程庫以及宏庫。測試人員。外科醫生需要大量合適的測試用例，用來對他所編寫的工作片段，以及對整個工作進行測試。因此，測試人員既是為他的各個功能設計系統測試用例的對頭，同時也是為他的日常調試設計測試數據的助手。他還負責計劃測試的步驟和為測試搭建測試平臺。語言專家。隨著Algol語言的出現，人們開始認識到大多數計算機項目中，總有一兩個樂於掌握複雜編程語言的人。這些專家非常有幫助，很快大家會向他咨詢。這些天才不同于外科醫生，外科醫生主要是系統設計者以及考慮系統的整體表現。而語言專家則尋找一種簡潔、有效的使用語言的方法來解決複雜、晦澀或者棘手的問題。他通常需要對技術進行一些研究（兩到三天）。通常一個語言專家可以為兩個到三個外科醫生服務。以上就是如何參照外科手術隊伍，以及如何對10人的編程隊伍進行專業化的角色分工。如何運作文中定義的開發團隊在很多方面滿足了迫切性的需要。十個人，其中七個專業人士在解決問題，而系統是一個人或者最多兩個人思考的產物，因此客觀上達到了概念的一致性。要特別注意傳統的兩人隊伍與外科醫生--副手隊伍架構之間的區別。首先，傳統的團隊將工作進行劃分，每人負責一部分工作的設計和實現。在外科手術團隊中，外科醫生和副手都瞭解所有的設計和全部的代碼。這節省了空間分配、磁盤訪問等的勞動量，同時也確保了工作概念上的完整性。第二，在傳統的隊伍中大家是平等的，出現觀點的差異時，不可避免地需要討論和進行相互的妥協和讓步。由於工作和資源的分解，不同的意見會造成策略和接口上的不一致，例如誰的空間會被用作緩衝區，然而最終它們必須整合在一起。而在外科手術團隊中，不存在利益的差別，觀點的不一致由外科醫生單方面來統一。這兩種團隊組建上的差異--對問題不進行分解和上下級的關係--使外科手術隊伍可以達到客觀的一致性。另外，團隊中剩餘人員職能的專業化分工是高效的關鍵，它使成員之間採用非常簡單的交流模式成為可能。外科醫生 | | \__ 副手 | | | 管理員-- | |--程序職員秘書 | | | |--工具維護人員 | | | |--測試人員 | | | |--語言專家編輯------- 秘書圖3.1：10人程序開發隊伍的溝通模式 Baker的文章(3)提出了專一的、小規模的測試隊伍。在那種情況下，它能按照所預期的進行運作，並具有良好的效果。團隊的擴建就目前情況而言，還不錯。然而，現在所面臨的問題是如何完成5000人年的項目，而不是20或30人年規模的系統。如果整個工作能控制在範圍之內，10人的團隊無論如何組織，總是比較高效的。但是，當我們需要面對幾百人參與的大型任務時，如何應用外科手術團隊的概念呢？擴建過程的成功依賴於這樣一個事實，即每個部分的概念完整性得到了徹底的提高--決定設計的人員是原來的七分之一或更少。所以，可以讓200人去解決問題，而僅僅需要協調20個人，即那些"外科醫生"的思路。對於協調的問題，還是需要使用分解的技術，這在後續的章節中會繼續進行討論。在這裏，可以認為整個系統必須具備概念上的完整性，要有一個系統結構師從上至下地進行所有的設計。要使工作易於管理，必須清晰地劃分體系結構設計和實現之間的界線，系統結構師必須一絲不苟地專注於體系結構。總的說來，上述的角色分工和技術是可行的，在實際工作中，具有非常高的效率。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.1.146