人月神話【筆記】

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

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

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

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

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

* 對進度缺少跟蹤和監督

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

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

* 一切都将動作良好，每一項任務僅花費它所“應該”花費的時間

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

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

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

軟體任務的進度安排：

* 1/3計劃

* 1/6編碼

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

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

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

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

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

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

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

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

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

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

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

* 程式職員：維護程式設計産品庫中所有團隊的技術記錄

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

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

* 語言專家：尋找合适的程式設計語言

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

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

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

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

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

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

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

想要成功，結構師必須：

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

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

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

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

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

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

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

“決不要攜帶兩個時鐘出海，帶一個或三個”

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

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

團隊如何進行交流：

* 非正式途徑

* 會議

* 工作手冊

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

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

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

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

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

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

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

兩個關于工作量的結論：

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

* 使用适當的進階語言，程式設計的生産率可以提高5倍

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

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

規模控制：

* 應該制訂總體規模的預算，應該制訂背景存儲通路的預算

* 在指明子產品有多大的同時，确切定義子產品的功能

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

資料的表現形式是程式設計的根本

計算機産品的文檔：

* 目标

* 技術說明

* 進度、時間表

* 預算

* 組織機構圖

* 工作空間的配置設定

* 報價、預測、價格

大學科系的文檔：

* 目标

* 課程概述

* 學位要求

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

* 課程表和課程的安排

* 預算

* 教室配置設定

* 教師的研究所學生助手的配置設定

軟體項目的文檔：

* 做什麼：目标

* 做什麼：産品技術說明

* 時間：進度表

* 資金：預算表

* 地點：工作空間配置設定

* 人員：組織圖

為什麼要有正式的文檔：

* 書面記錄決策是必要的

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

* 項目經理的文檔可以作為資料基礎和檢查清單

變化是與生俱來的，不是不合時宜和令人生厭的異常情況。開發人員将會的是使用者滿意程度，而不僅僅是實際的産品。使用者的實際需要和使用者感覺會随着程式的建構、測試和使用而變化

為變更計劃系統：細緻的子產品化、可擴充的函數、精确完整的子產品間接口設計、完備的文檔，調用隊列和表驅動，使用進階語言和自文檔技術，數字版本号

為變更計劃組織架構：

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

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

* 管理人員需要參與技術課程，進階技術人才需要進行管理教育訓練

程式維護中的一個基本問題是——缺陷修複總會以（20-50）%的機率引入新的bug。設計實作的人員越少、接口越少，産生的錯誤也就越少

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

“關鍵的工作是産品定義。許許多多的失敗完全源于那些産品未精确定義的地方”

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

系統內建調試：

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

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

* 控制變更

* 一次添加一個構件

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