​​人月神話：軟體專案管理之道（20週年紀念版）
  • ​​英文書名: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition
  • ​​第一版是 1975年出的

​​章節

  1. ​​焦油坑
  1. ​​前言, 一開始講大型軟體系統像是掉到焦油坑一樣
  1. ​​軟體是什麼, 樂趣, 苦難
  1. ​​程式 → 軟體系統(整合)/軟體產品 (測試/文件等) → 軟體系統產品. 
  1. ​​變成產品的代價是三倍, 系統化也是三倍，若是系統產品則是九倍以上。
  1. ​​樂趣:
  1. ​​創造
  1. ​​創造出來的東西對別人很實用
  1. ​​解迷的過程
  1. ​​持續學習的樂趣
  1. ​​能在如此易於操控的介質上工作的快樂
  1. ​​苦難
  1. ​​人月神話
  1. ​​專案不順利 → 通常是缺乏良好的時程規劃
  1. ​​預估技術不準
  1. ​​工作量 ↔ 專案進度混為一談 (跟下面的人月 section 有關)
  1. ​​專案經理通常缺乏委婉的堅持
  1. ​​時程缺乏堅控 (之後在探討)
  1. ​​delay 時自然而然增加人手 (火上加油)
  1. ​​錯誤的想法
  1. ​​樂觀 (都會很順利，沒有 bug，沒有抓 buffer)
  1. ​​人月 (有圖表)
  1. ​​溝通有成本
  1. ​​訓練/上手
  1. ​​交流
  1. ​​debug 跟開發無法切成兩個人的時間. 有時會有連續性的本質
  1. ​​系統測試 ＋ debug
  1. ​​1/3 規劃, 1/6 寫程式，1/4 組件測試，1/4 測試
  1. ​​delay 常有 secondary cost
  1. ​​要有勇氣堅持自己的預估
  1. ​​同時也盡量可以用較好的生產力資料/預估時程的法則來說服
  1. ​​惡性循環的時程災難 (有圖表 example)
  1. ​​估計錯誤, 訓練跟溝通成本
  1. ​​在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後
  1. ​​除了訓練跟交流成本，還會有工作重新切分本身造成的混亂與額外工作量
  1. ​​外科手術團隊
  1. ​​程式設計師最好:最壞 = 10:1
  1. ​​一個人管理 : 不超過 10人
  1. ​​如何同時兼顧工作效率(很難只用少數厲害的做事)與概念整體性 conceptual integrity (←大型專案)
  1. ​​良好的分工
  1. ​​概念整體性 → 由系統架構師掌控
  1. ​​專制, 民主與系統設計
  1. ​​與接下來的兩章，探討幾個系統設計時的問題