軟體專案管理的聖經–人月神話(中)

第6章貫徹執行
6.1 即使是大型的設計團隊，設計結果也必須由一個或兩個人來完成，以確保這些決定是一致的。
6.2 必須明確定義體繫結構中與先前定義不同的地方，重新定義的詳細程度應該與原先的說明一致。
6.3 出於精確性的考慮，我們需要形式化的設計定義，同樣，我們需要記敘性定義來加深理解。
6.4 必須採用形式化定義和記敘性定義中的一種作為標準，另一種作為輔助措施；它們都可以作為表達的標準。
6.5 設計實現，包括類比模擬，可以充當一種形式化定義的方法；這種方法有一些嚴重的缺點。
6.6 直接整合是一種強制推行軟體的結構性標準的方法。[硬體上也是如此——考慮內建在ROM中的Mac WIMP介面。]
6.7 “如果起初至少有兩種以上的實現，那麼（體繫結構）定義會更加整潔，會更加規範。”
6.8 允許體繫結構師對實現人員的詢問做出自動答錄服務解釋是非常重要的，並且必須進行日誌記錄和整理髮布。[電子郵件是一種可選的介質。]
6.9 “專案經理最好的朋友就是他每天要面對的敵人——獨立的產品測試機構/小組。”

第7章為什麼巴比倫塔會失敗？
7.1 巴比倫塔項目的失敗是因為缺乏交流，以及交流的結果——組織。
交流
7.2 “因為左手不知道右手在做什麼，從而進度災難、功能的不合理和系統缺陷紛紛出現。”由於對其他人的各種假設，團隊成員之間的理解開始出現偏差。
7.3 團隊應該以儘可能多的方式進行相互之間的交流：非正式、常規項目會議，會上進行簡要的技術陳述、共用的正式項目工作手冊。[以及電子郵件。]
項目工作手冊
7.4 項目工作手冊“不是獨立的一篇文檔，它是對項目必須產生的一系列文檔進行組織的一種結構。”
7.5 “項目所有的文檔都必須是該（工作手冊）結構的一部分。”
7.6 需要儘早和仔細地設計工作手冊結構。
7.7 事先制訂了良好結構的工作手冊“可以將後來書寫的文字放置在合適的章節中”，並且可以提高產品手冊的品質。
7.8 “每一個團隊成員應該瞭解所有的材料（工作手冊）。”[我想說的是，每個團隊成員應該能夠看到所有材料，網頁即可滿足要求。]
7.9 即時更新是至關重要的。
7.10 工作手冊的使用者應該將注意力集中在上次閱讀後的變更，以及關於這些變更重要性的評述。

7.11 OS/360項目工作手冊開始採用的是紙介質，後來換成了微縮膠片。
7.12 今天[即使在1975年]，共用的電子手冊是能更好達到所有這些目標、更加低廉、更加簡單的機制。
7.13 仍然需要用變更條和修訂日期[或具備同等功能的方法]來標記文字；仍然需要後進先出（LIFO）的電子化變更小結。
7.14 Parnas強烈地認為使每個人看到每件事的目標是完全錯誤的；各個部分應該被封裝，從而沒有人需要或者允許看到其他部分的內部結構，只需要瞭解介面。
7.15 Parnas的建議的確是災難的處方。[Parnas讓我認可了該觀點，使我徹底地改變了想法。]
組織架構
7.16 團隊組織的目標是為了減少必要的交流和協作量。
7.17 為了減少交流，組織圖包括了人力劃分（division of labor）和限定職責範圍（specialization of function）。
7.18 傳統的樹狀組織圖反映了權力的結構原理——不允許雙重領導。
7.19 組織中的交流是網狀，而不是樹狀結構，因而所有的特殊組織機制（往往體現成組織圖中的虛線部分）都是為了進行調整，以克服樹狀組織圖中交流缺乏的困難。
7.20 每個子項目具有兩個領導角色——產品負責人、技術主管或結構師。這兩個角色的職能有著很大的區別，需要不同的技能。
7.21 兩種角色中的任意組合可以是非常有效：