A summary of the book, "The Mythical Man-Month"

1. 1
The Mythical Man-Month
chapter 1 to 5
Ked
1. 焦油坑
 對航海的人來說，擱淺的船就是燈塔
寫程式的樂趣
 創造的趣味
 創造的東西竟然對別人有用
 打造精巧機制時，類似推理、解謎的過程
 持續學習的樂趣
 異於操控的介質
寫程式的苦難
 必須表現得完美----作者覺得最難的部分
 由別人設定目標、供給資源
 必須依賴別人才能成事
 debug
 必須承擔落伍的可能性
2. 人月神話
 好菜都得多花些時間準備，為了能讓你享受到
更美味、更可口的佳餚，請你務必耐心稍待

2. 2
專案進行不順利的原因
 過於樂觀
 把工作量和專案進度混為一談
 缺乏遠景
 缺乏堅持
 惡性循環
過於樂觀
把工作量和專案進度混為一談 缺乏遠景
缺乏堅持 惡性循環

3. 3
3. 外科手術團隊
 研究顯示，高手與一般人的表現有著極大的差
異，而且往往是一個數量級的差異
 並非每個成員都親自下去拿手術刀解決問題，
取而代之的，是只由一個人操刀，而其他人則
扮演支援性的腳色，增進操刀者的效率與生產
力
4. 專制、民主、與系統設計
 這個大教堂是個無與倫比的藝術結晶，一點也
不會讓人有乏味和混亂的感覺
約束對藝術而言是件好事
5. 第二系統效應
 加一點點，加一點點，最後變成一大坨

4. 4
第二個系統是最危險的系統

5. 1
The Mythical Man-Month
chapter 6 to 10
Ked
6. 意念的傳達
 他將會坐在這兒，說”做這個！做那個！”
然後什麼事都不會發生。
開會將獲得豐碩的成果
1. 這是同一個小組持續地會議
2. 沒有”顧問” ，而是必須做出承諾
3. 有問題時，將由不同的觀點尋求解決方案
4. 正式的書面提案使問題得到重視
5. 使延宕得以避免
7. 巴別塔為什麼失敗
 於是，主就把他們從那裡分散到各地方，他們
就不能再建造那城了。

6. 2
缺少溝通
盡可能運用所有的方法進行溝通!! 階層分工
8. 預估
 練習就是最好的教練
“預估”有多重要
 它是每一本軟體專案開發書籍強調的重點

7. 3
費力程度 = 常數 x 指令數量1.5
 寫一個獨立小程式所花的時間不能拿來作為預
估整個軟體系統產品的開發時程之用
 線性外推這種天真的做法是沒有意義的，你用
跑一百公尺的速度拿去外推，將得到跑一公里
不用二分鐘的結論
9. 地盡其力，物盡其用
 創作者應該盯著諾亞，並且….學學人家是怎
麼將一大票的東西塞進一個小方舟上的
要快？ 要小？
 在規定某個模組的大小之前，你得先精確定義
出這個模組該做的事
10. 文件假說
 假說：在成堆的書面資料中，有一小部份關鍵
性文件紀錄著任何專案管理的核心工作，而這
些文件是身為管理者最重要的工具
為什麼要有文件
 把決策寫下來是最起碼的事情
 只有把事情真正寫下來，遺漏和矛盾之處才會顯露
出來
 文件有傳達決策給他人的功用

8. 1
The Mythical Man-Month
chapter 11 to 16
Ked
11. 失敗為成功之母
 你得以平常心看待失敗，詴詴這個，如果行不
通，就老老實實接受行不通的事實，再詴詴那
個。總之，要成功，就得去詴一詴。
改變
 軟體產品是無形的，加上它易於操控的特性，
使得開發人員必須面臨需求上無窮無盡的改變。
 無論如何，把必然的一次失敗納入正式計畫之
中。
面對改變
 計畫：
 定義出一個底限是必須的，而隨著專案進行，這項
限制應該要越來越嚴格。
 系統：
 模組間明確而完整的介面及文件
 表格驅動技術
 組織：
 管理和技術人員，應該保持兩種不同角色的職位互
換。
軟體維護
 付出的代價相當於開發成本的40%，或更高
 局部的錯誤可能牽涉很廣
 修改的人不是原作者
 加入新程式而產生更多的問題
 軟體維護是複雜化且逐漸趨於混亂的過程
 即使有很好的技巧，頂多也只能減緩這種趨勢，軟
體終究會走到落伍、再也無法修改的一天。
12. 神兵利器
 巧匠以他所使用的工具而聞名。

9. 2
 系統除錯通常像觀察天文一樣，是個夜晚的工
作。
版本控制器
 將程式的一份副本歸管理者擁有，只有他有權
認可這份程式的異動。
 將程式的整合與交付，從局部自由區域裡予以
正式區隔出來，並演進。
13. 化整為零
 我可以召換地底的幽魂。
啊！這我也會，什麼人都會；可是當你召換它
們的時候，它們就真的會來嗎？
 當你寫了程式，程式就真的會正常運作了嗎
避免錯誤發生的設計方式
1) 做好定義以防止誤解
2) 由上而下的設計方式
3) 結構化程式設計
做好定義以防止誤解
 “把產品定義清楚是非常關鍵的工作，有太多
太多的失敗都源自於自始至終都搞不清楚要做
的是什麼東西。”

10. 3
由上而下的設計方式
 一個持續細分的步驟
 更容易描述出精確的需求和模組功能。
 藉由分割並明確定義出獨立模組的過程，可以避免
系統錯誤。
 隱藏細節將使結構中的薛縣更容易被突顯出來。
 每一次細分精製的步驟，都可以對該步驟的設計成
果進行測詴。
系統除錯
 如果除錯的結果不好好整理，下一次的上機也
會變得毫無頭緒，不會有什麼進展。
 使用除錯完的組件
 建立充分的測詴鷹架
 控制改變
 一次只整合一個組件
 必須假設一定會有許多錯誤存在，才會好好規劃出能歹出
錯誤的程序。
 固定改版的時機
9. 釀成大災難
 為什麼專案會落一年？
….因為每次落後一天
里程碑
 里程碑必須是具體、明確、可量測的事件，有
沒有達成應該是一翻兩瞪眼的事。
15. 一體兩面
 我們無法主宰我們不了解的東西

11. 4
 由老手展現如何賣收銀機，事後證明，這是一
個很好的經驗傳承方式。
惱人的流程圖
 流程圖是最被過度強調的文件，許多程式一點
都不需要流程圖，也很少程式需要一頁以上的
流程圖。
 “我從未看過一個程式老手在開始寫程式之前
會乖乖畫出詳細的流程圖，也許組織會制定標
準並規定一定要畫流程圖，但實際上這多半會
流於形式。”
自我說明程式
 合併文件，把書面說明整合到程式碼裡頭，這
麼做將大幅改善維護工作，而且保正程式使用
者可以隨時便利地參考文件，這種做法稱為程
式的自我說明。
16. 沒有銀彈
 再未來的十年之內，無論是在技術上或管理上，
都不會有任何單一的重大突破，能保證在生產
力、可靠度或簡潔性上獲得改善，甚至，連一
個數量級的改善都不會有。
作者建議
 多加利用大眾市場，避免開發現成就買得到的
東西。
 再制定軟體需求十，採用多次反覆的方式，並
把快速型製作，納入所規劃的每個反覆之中。
 讓軟體像生物一樣地發育成長，在系統持續被
執行、被使用、被測詴的過程中，逐步擴充功
能。
 持續尋覓並培養年輕一大偉大的概念設計人員。
有志者事竟成
 人類能克服疾病的第一步，就是以細菌說淘汰
了惡魔說和體液說，正是這一步，帶給了人類
希望，粉碎了所有奇蹟式的冀望，告訴人們進
步是要靠按部就班、不辭辛苦而來，得在清潔
衛生方面持續不斷地投入新血，養成良好的習
慣，才是正道。如今，我們面對軟體工程也是
一樣。

12. 5
特別一提—偉大的設計師
 “關於如何提升軟體技藝這個核心問題，一如
既往，其關鍵在人。”