人月神話【筆記】

來自專欄 ZyBlog

編程的最困難部分，是將做事的方式往追求完美的方向調整

缺乏的時間進度是造成項目滯後的最主要原因：

* 我們對估算技術缺乏有效的研究

* 我們採用的估算技術隱含地假設人和月可以互換

* 由於對自己的估算缺乏信心，軟體經理通常不會有耐心地持續地進行估算這項工作

* 對進度缺少跟蹤和監督

* 當意識到進度的偏移時，下意識（以及傳統）的反應是增加人力

系統編程的進度安排背後的假設：

* 一切都將動作良好，每一項任務僅花費它所「應該」花費的時間

* 用人月作為衡量一項工作的規模是一個危險和帶有欺騙性的神話，它暗示著人員數量和時間是可以相互替換的

* 由於我們的樂觀主義，通常實際出現的缺陷數量比預料的要多得多。因此，系統測試進度的安排常常是編程中最不合理的部分

* 為了滿足顧客期望的日期而造成的不合理進度安排，在軟體領域中比其他的工程領域要普遍的多

軟體任務的進度安排：

* 1/3計劃

* 1/6編碼

* 1/4構件測試和早期系統測試

* 1/4系統測試，所有的構件已完成

Brooks法則：向進度落後的項目中增加人手，只會使進度更加落後

項目的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。從這兩個數值可以推算出進度時間表，該表安排的人員較少，花費的時間較長（唯一的風險是產品可能會過時）。相反，分派較多的人手，計劃較短的時間，將無法得到可行的進度表

需要協作溝通的人員的數量影響著開發成本，因為成本的主要組成部分是相互的溝通和交流，以及更正溝通不當所引起的不良結果（系統調試）。系統應該由儘可能少的人員來開發

Mills建議大型項目的每一個部分由一個團隊解決，該隊伍以類似外科手術的方式組建：

* 外科醫生：首席程度員，天分、經驗、能力

* 副手：外科醫生的後備，較少的經驗

* 管理員：控制財務、人員、工作地點安排和機器的專業管理人員

* 編輯：分析重組開發文檔

* 兩個秘書：管理員和編輯每人需要一個秘書

* 程序職員：維護編程產品庫中所有團隊的技術記錄

* 工具維護人員：保證所有基本服務的可靠性，以及承擔團隊成員所需要的特殊工具的構建、維護和升級責任

* 測試人員：大量合適的測試用例，搭建測試平台

* 語言專家：尋找合適的編程語言

進度壓力要求很多人員來開發系統，有兩種方法解決這種矛盾：

* 仔細地區分設計方法和具體實現

* 一種新的組建編輯開發團隊的方法

對於非常大型的項目，將設計方法、體系結構方面的工作與具體實現相分離是獲得概念完整性的強有力方法

系統的結構師，是運用專業技術知識來支持用戶的真正利益，而不是維護銷售人員所鼓吹的利益，體系結構陳述的是發生了什麼，而實現描述的是如何實現

整個創造性活動包括了三個獨立的階段：體系結構、設計實現、物理實現，在實際情況中，它們往往可以同時開始和並發地進行

儘早交流和持續溝通能使結構師有較好的成本意識，以及使開發人員獲得對設計的信心，並且不會混淆各自的責任分工

想要成功，結構師必須：

* 牢記是開發人員承擔創造性和發明性的實現責任，所以結構師只能建議，而不能支配

* 時刻準備著為所指定的說明建議一種實現的方法，同樣準備接受其他任何能達到目標的方法

* 對上述的建議保持低調和平靜

* 準備放棄堅持所作的改進建議

項目經理如何避免畫蛇添足？他必須堅持至少擁有兩個系統以上開發經驗結構師的決定 ，同時，保持對特殊誘惑的警覺，他可以不斷提出正確的問題，確保原則上的概念和目標在詳細設計中得到完整的體現

手冊、或者書面規格說明，是一個非常必要的工具，儘管光有文檔是不夠的。手冊是產品的外部規格說明，它描述和規定了用戶所見的每一個細節。不但要描述包括所有界面在內的用戶可見的一切，它同時還要避免描述用戶看不見的事物。後者是編程實現人員的工作範疇

思路是大約十個人的想法，但如果想保持文字和產品之間的一致性，則必須由一個或兩個人來完成將其結論轉換成書面規格說明的工作。對於在整個設計中，保證這些看似瑣碎的問題處理原則上的一致性，決不是一件無關緊要的事情

「決不要攜帶兩個時鐘出海，帶一個或三個」

設立測試小組是使設計決策得以貫徹執行的必要手段，同樣也是需要儘早著手，與設計同時實施的重要環節

巴比倫塔的失敗原因：交流、組織。交流和交流的結果—組織，是成功的關鍵。交流和組織的技能需要管理者仔細考慮，相關經驗的積累和能力的提高同軟體技術本身一樣重要

團隊如何進行交流：

* 非正式途徑

* 會議

* 工作手冊

團隊組織的目的是減少不必要交流和合作的數量，因此良好的團隊組織是解決上述交流問題的關鍵措施

減少交流的方法是人力劃分和限定職責範圍

人力劃分存在三種可能關係：

* 產品負責人和技術主管是同一個人（小型團隊）

* 產品負責人作為總指揮，技術主管充當其左右手（大型團隊）

* 技術主管作為總指揮，產品負責人充當其左右手（中小型團隊）

工作量=（常數） * （指令的數量）

兩個關於工作量的結論：

* 對常用的編程語句而言。生產率似乎是固定的。這個固定的生產率包括了編程中需要注釋，並可能存在錯誤的情況。

* 使用適當的高級語言，編程的生產率可以提高5倍

沒有人可以在自始至終提倡更緊密的軟硬體設計集成的同時，又僅僅就規模本身對軟體系統提出批評

由於規模是軟體系統產品用戶成本中如此大的一個組成部分，開發人員必須設置規模的目標，控制規模，考慮減小規模的方法，就像硬體開發人員會設立元器件數量目標，控制元器件的數量，想出一些減少零件的方法

規模控制：

* 應該制訂總體規模的預算，應該制訂後台存儲訪問的預算

* 在指明模塊有多大的同時，確切定義模塊的功能

* 保持持續的警覺，確保連貫的系統完整性

數據的表現形式是編程的根本

計算機產品的文檔：

* 目標

* 技術說明

* 進度、時間表

* 預算

* 組織機構圖

* 工作空間的分配

* 報價、預測、價格

大學科系的文檔：

* 目標

* 課程概述

* 學位要求

* 研究報告（申請基金時，還要求計劃）

* 課程表和課程的安排

* 預算

* 教室分配

* 教師的研究生助手的分配

軟體項目的文檔：

* 做什麼：目標

* 做什麼：產品技術說明

* 時間：進度表

* 資金：預算表

* 地點：工作空間分配

* 人員：組織圖

為什麼要有正式的文檔：

* 書面記錄決策是必要的

* 文檔能夠作為同其他人的溝通渠道

* 項目經理的文檔可以作為數據基礎和檢查列表

變化是與生俱來的，不是不合時宜和令人生厭的異常情況。開發人員將會的是用戶滿意程度，而不僅僅是實際的產品。用戶的實際需要和用戶感覺會隨著程序的構建、測試和使用而變化

為變更計劃系統：細緻的模塊化、可擴展的函數、精確完整的模塊間介面設計、完備的文檔，調用隊列和表驅動，使用高級語言和自文檔技術，數字版本號

為變更計劃組織框架：

* 把所有計劃、里程碑、日程安排都當作是嘗試性的，以方便進行變化

* 使管理人員和技術人才具有互換性

* 管理人員需要參與技術課程，高級技術人才需要進行管理培訓

程序維護中的一個基本問題是——缺陷修復總會以（20-50）%的機率引入新的bug。設計實現的人員越少、介面越少，產生的錯誤也就越少

系統軟體開發是減少混亂度（減少熵）的過程，所以它本身是處於亞穩態的。軟體維護是提高混亂度（增加熵）的過程，即使是最熟練的軟體維護工作，也只是放緩了系統退化到非穩態的進程

「關鍵的工作是產品定義。許許多多的失敗完全源於那些產品未精確定義的地方」

關鍵的地方和構建無bug程序的核心，是把系統的結構作為控制結構來考慮，而不是獨立的跳轉語句

系統集成調試：

* 使用經過調試的構建單元（單元測試）

* 搭建充分的測試平台（偽構件，樁、模）

* 控制變更

* 一次添加一個構件

* 階段（量子）化、定期變更

里程碑：必須是具體的、特定的、可度量的事件，能夠進行清晰的定義，有明顯邊界和沒有歧義

「我認為軟體開發中困難的部分是規格化、設計和測試這些概念上的結構，而不是對概念進行表達和對實現逼真程序進行驗證」

軟體系統的內在特性：複雜度、一致性、可變性、不可見性

針對概念上根本問題的頗具前途的方法：

* 購買和自行開發，構建軟體最可能的徹底解決方案是不開發任何軟體

* 需求精練和快速原型

* 增量開發——增長，而非搭建系統，先運行起來

* 卓越的設計人員

大多數有豐富經經驗的程序員擁有自己的私人開發庫，可以使他們使用大約30%的重用代碼來開發軟體。公司級別的重用能提供70%的重用代碼量，它需要特殊的開發庫和管理支持。公司級別的重用代碼也意味著需要對項目中的變更進行統計和度量，從而提高重用的可信程度

每一份發布的程序拷貝應該包括一些測試用例，其中一部分用於校驗輸入數據，一部分用於邊界輸入數據，另一部分用於無效的輸入數據

一個整潔、優雅的編程產品必須向它的每個用戶提供一個條理分明的概念模型，這個模型描述了應用、實現應用的方法以及用來指明操作和各種參數的用戶界面使用策略