《人月神話》個人整理 Part 2

延續前一篇，這一篇就由書中的第五章繼續開始了。

第五章 第二系統效應

這邊所謂的「第二系統效應」，是指一個人在設計系統的時候，第二個設計出來的系統，是最危險的一個。這是因為在第一個系統的時候，由於自知不夠熟系，所以會比較節制、也會比較簡單清爽；但是設計第二個系統的時候，卻很容易把在做第一個系統時的所有構想，都加掛到這個自認已經熟系的第二個系統上，所以第二個系統很容易有過度設計的問題。再之後的系統（第三個及以後），由於會和之前的經驗做對比、相互印證，所以也就比較不會有問題了～

而要避免這個問題，以設計師來說，主要就是要靠「自律」了～同時，也要了解這個第二系統效應的原因，並提醒自己避免設計出不相關的功能、或是做出違反原先架設與目的的功能。而以專案經理來說，則就是要採用至少兩個以上系統設計經驗的架構設計老手了。

另外，在這章作者也列出了架構設計師若要成功影響實作方式的原則，其列舉如下：

• 記住實作人員有發會創意完成實作的任務，所以架構設計師只能建議。
• 在建議時，永遠只提出一個能夠符合規格的實作方法，同時也接受其他能夠達到目標的方案。
• 默默地，私底下提出建議。
• 準備為提出的建議付出喪失信任的代價。
• 傾聽實作人員所提出來的修改架構建議。

第六章 意念的傳達

這一章主要的主題，是著重於整個意思的傳達，以及精確的描述；因為唯有在所有參與專案的人都能夠明確無誤地了解整個架構、規範、介面等等必須要溝通的東西時，才有可能真正完全按照計畫來進行。而針對了這個主題，作者也在本章內提出了許多建議：

• 書面規則／手冊
  • 不僅要描述使用者將會看到的所有細節，也要避免描述使用者看不到的東西。
  • 手冊的風格應該要準確、完整、詳細，各項定義與要點必須要保持一致；而為了做到這點，所以書面化的工作應該要由一到兩個個人來主筆。
  • 那些有規範、那些沒有規範，都要定義清楚。
• 正式定義
  • 採用「正式標記法」（formal notation）。
  • 為了精確，使用「正式定義」（formal definition），而為了易懂，也需要「散文式定義」（prose definition）；而這兩者之中，要有一個是主要標準，另一個則根據這個標準改寫而來。
  • 實作也可以當作正式定義，例如用模擬器來當作定義。這樣的好處是只要實際測試一下，就知道他應該有什麼結果；但是相對的，也有可能因此會因為這個實作，而導致定義的過度描述，而影響到之後實作的彈性。
• 將定義融入實作
• 開會
  • 有兩種會議很有幫助，一個是固定每周召開的會議，另一個是年度檢討大會。
  • 前者由首席系統架構設計師擔任主席、時間較短（半天），任何與會人員都可以提出問題和異動提案（但是要先提交書面資料）， 重點在於激發創意；而在提案後由架構設計師整理成為較精細的提案報告。會議決策權在首席系統架構設計師上，最後的結果要正式、即時、全面地公告。如此可以使各項決策迅速敲定、讓工作得以順利進行。
  • 後者時間較長（兩周），用來處理細瑣事務、公開討論，讓大家發洩不滿。
• 多重實作
  • 一開始就開發兩個以上的實作產品，可以避免根據錯誤的實作去修改規格，將有助於維持架構定義的純淨與嚴謹。
• 電話紀錄
  • 允許實作人員直接詢問架構設計師（電話、或者電子郵件），而不要自行解釋。而這些詢問都應該被記錄下來、彙整後分發給所有實作人員和使用者。
• 產品測試
  • 獨立的產品測試小組是必須的。

 

第七章 巴別塔為什麼失敗

巴別塔失敗的原因是什麼？作者認為是「溝通」，以及隨之而來的「組織」；而這也是一般大型專案會遭遇到的問題，像是時程落後、功能誤解等等問題，也多是由於溝通不良所造成的。

為了要避免這樣的問題，每個小組應該要盡可能運用各種方式來做溝通，不管是非正式的方法（電話、電子郵件），或是會議、專案工作手冊，都可以用來幫助溝通。

其中，「專案工作手冊」算是一份其他文件的組織結構，規範了專案進行過程中即將產生的文件，並可以用來保存技術方面的說明；而為了讓工作手冊可以真正有用，他需要被盡早、小心地設計出來。此外，工作手冊也是確保需要資訊的人都能夠在適當的地方取得資訊的方法，每一個團隊的成員都應該要可以看到工作手冊的全部文件內容；同時也要確保文件的內容有被持續地更新，並且保有改版的紀錄，讓看的人知道版本間的修改狀況。在以往這點可能很難做到，但是現在網路、電子化文件都很發達了，要做到基本上問題並不大。

而作者在之後的章節（第十八章）也有強調，他目前認同 Parnas 的主張，認為沒有必要所有人都要看完所有的東西，部分的細節應該要被封裝（encapsulated）起來，不屬於自己的東西，就不必、也不被允許去看裡面的細節，只需要看到介面就夠了。

另外，「組織」的目的，則是要透過人力配置和專業分工，來減少溝通量。傳統的樹狀結構組織主要是源自於權力的責任結構，但是以溝通結構來說，則是會是網狀的，這樣才可以避免溝通不良的問題。

作者也認為，每個子專案都應該要有兩種領導腳色，也就是「管理者」（producer）和「技術總監」（technical director）或「架構設計師」。前者負責著急小組、分派工作、規劃時程、爭取掌握資源，以及和別的小組溝通，並且對時程負責；後者則是構思、分割系統，切割系統的外觀和內構，維持整個設計的和諧與整體性。

而作者認為，這兩種腳色的搭配方法有三種：

• 管理者兼任技術總監

  主要適合於小型團隊，不是用於大型團隊。

• 管理者是老闆、技術總監是副手

  這種搭配的困難在於如何賦予技術總監下達技術決策的權力，避免在管理的命令體系中浪費太多時間。很明顯地，管理者必須公開將技術上的決策授權給技術總監，並予以支持。

• 技術總監是老闆、管理者是副手

  由管理者來協助技術總監，讓技術總監著重於技術層面。

第八章 預估

本章的是在討論要如何預估一個專案所需的時間；在文中，作者提出了一些其他人的研究成果，來作為時間預估的參考。而在開始前，作者也先提出了警告：

• 寫一個獨立小程式所花的時間，不能拿來做為預估整個軟體系統產品開發時程之用；規劃、寫文件、測試、系統整合以及訓練的時間，都是必須加以考量的，線性外推種天真的做法是沒有意義的。
• 即使只考慮個人創作，不含任何和別人溝通的代價，寫程式的費力程度仍然跟程式的大小呈現出指數倍數的關係（某些研究指出指數值是 1.5 左右）。

而作者引用的一些研究資料，則大概條列如下：

• Charles Portman 在國際電腦的經驗是，在上班時間大概只有 50% 的時間是真正在寫程式或除錯，其他的雜物會佔去大概一半的時間。
• Joel Aron 在 IBM 的經驗，在一個大型系統（25 個程式設計師、30,000 行程式）裡的子系統，根據溝通量的不同，生產力在每人年 1,500 – 10,000 個指令不等；基本上溝通量越多、生產力越少。
• 以 John Harr 在貝爾實驗室以及 Brooks 自己在 IBM 的經驗，作業系統／控制程式這類的程式生產力大約是每人年 600 – 800 個指令，編譯器這類的程式則大約是每人年 2,000 – 3,000 個指令。（這兩者都是組合語言）
• Corbató 在麻省理工 Multics 專案的數據顯示，使用 PL/I（某古老的高階程式語言、維基百科）開發介於作業系統和編譯器之間的混和程式，其生產力大約是每人年 1,200 行程式（每行約可抵三到五個字）。
• 結論是：生產力若以行來算，似乎是個固定值；而如果採用了合適的高階語言，軟體開發的生產力也許可以提升到五倍。