1

The Mythical Man-Month

chapter 1 to 5

Ked

1. 焦油坑

對航海的人來說，擱淺的船就是燈塔

寫程式的樂趣

創造的趣味

創造的東西竟然對別人有用

打造精巧機制時，類似推理、解謎的過程

持續學習的樂趣

異於操控的介質

寫程式的苦難

必須表現得完美----作者覺得最難的部分

由別人設定目標、供給資源

必須依賴別人才能成事

debug

必須承擔落伍的可能性

2. 人月神話

好菜都得多花些時間準備，為了能讓你享受到更美味、更可口的佳餚，請你務必耐心稍待

2

專案進行不順利的原因

過於樂觀

把工作量和專案進度混為一談

缺乏遠景

缺乏堅持

惡性循環

過於樂觀

把工作量和專案進度混為一談 缺乏遠景

缺乏堅持 惡性循環

3

3. 外科手術團隊

研究顯示，高手與一般人的表現有著極大的差異，而且往往是一個數量級的差異

並非每個成員都親自下去拿手術刀解決問題，取而代之的，是只由一個人操刀，而其他人則扮演支援性的腳色，增進操刀者的效率與生產力

4. 專制、民主、與系統設計

這個大教堂是個無與倫比的藝術結晶，一點也不會讓人有乏味和混亂的感覺

約束對藝術而言是件好事

5. 第二系統效應

加一點點，加一點點，最後變成一大坨

4

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

1

The Mythical Man-Month

chapter 6 to 10

Ked

6. 意念的傳達

他將會坐在這兒，說”做這個！做那個！”

然後什麼事都不會發生。

開會將獲得豐碩的成果

1. 這是同一個小組持續地會議

2. 沒有”顧問” ，而是必須做出承諾

3. 有問題時，將由不同的觀點尋求解決方案

4. 正式的書面提案使問題得到重視

5. 使延宕得以避免

7. 巴別塔為什麼失敗

於是，主就把他們從那裡分散到各地方，他們就不能再建造那城了。

2

缺少溝通

盡可能運用所有的方法進行溝通!! 階層分工

8. 預估

練習就是最好的教練

“預估”有多重要

它是每一本軟體專案開發書籍強調的重點

3

費力程度 = 常數 x 指令數量1.5

寫一個獨立小程式所花的時間不能拿來作為預估整個軟體系統產品的開發時程之用

線性外推這種天真的做法是沒有意義的，你用跑一百公尺的速度拿去外推，將得到跑一公里不用二分鐘的結論

9. 地盡其力，物盡其用

創作者應該盯著諾亞，並且….學學人家是怎麼將一大票的東西塞進一個小方舟上的

要快？ 要小？

在規定某個模組的大小之前，你得先精確定義出這個模組該做的事

10. 文件假說

假說：在成堆的書面資料中，有一小部份關鍵性文件紀錄著任何專案管理的核心工作，而這些文件是身為管理者最重要的工具

為什麼要有文件

把決策寫下來是最起碼的事情

只有把事情真正寫下來，遺漏和矛盾之處才會顯露出來

文件有傳達決策給他人的功用

1

The Mythical Man-Month

chapter 11 to 16

Ked

11. 失敗為成功之母

你得以平常心看待失敗，詴詴這個，如果行不通，就老老實實接受行不通的事實，再詴詴那個。總之，要成功，就得去詴一詴。

改變

軟體產品是無形的，加上它易於操控的特性，使得開發人員必須面臨需求上無窮無盡的改變。

無論如何，把必然的一次失敗納入正式計畫之中。

面對改變

計畫：

定義出一個底限是必須的，而隨著專案進行，這項限制應該要越來越嚴格。

系統：

模組間明確而完整的介面及文件

表格驅動技術

組織：

管理和技術人員，應該保持兩種不同角色的職位互換。

軟體維護

付出的代價相當於開發成本的40%，或更高

局部的錯誤可能牽涉很廣

修改的人不是原作者

加入新程式而產生更多的問題

軟體維護是複雜化且逐漸趨於混亂的過程

即使有很好的技巧，頂多也只能減緩這種趨勢，軟體終究會走到落伍、再也無法修改的一天。

12. 神兵利器

巧匠以他所使用的工具而聞名。

2

系統除錯通常像觀察天文一樣，是個夜晚的工作。

版本控制器

將程式的一份副本歸管理者擁有，只有他有權認可這份程式的異動。

將程式的整合與交付，從局部自由區域裡予以正式區隔出來，並演進。

13. 化整為零

我可以召換地底的幽魂。

啊！這我也會，什麼人都會；可是當你召換它們的時候，它們就真的會來嗎？

當你寫了程式，程式就真的會正常運作了嗎

避免錯誤發生的設計方式

1) 做好定義以防止誤解

2) 由上而下的設計方式

3) 結構化程式設計

做好定義以防止誤解

“把產品定義清楚是非常關鍵的工作，有太多太多的失敗都源自於自始至終都搞不清楚要做的是什麼東西。”

3

由上而下的設計方式

一個持續細分的步驟

更容易描述出精確的需求和模組功能。

藉由分割並明確定義出獨立模組的過程，可以避免系統錯誤。

隱藏細節將使結構中的薛縣更容易被突顯出來。

每一次細分精製的步驟，都可以對該步驟的設計成果進行測詴。

系統除錯

如果除錯的結果不好好整理，下一次的上機也會變得毫無頭緒，不會有什麼進展。

使用除錯完的組件

建立充分的測詴鷹架

控制改變

一次只整合一個組件 必須假設一定會有許多錯誤存在，才會好好規劃出能歹出

錯誤的程序。

固定改版的時機

9. 釀成大災難

為什麼專案會落一年？

….因為每次落後一天

里程碑

里程碑必須是具體、明確、可量測的事件，有沒有達成應該是一翻兩瞪眼的事。

15. 一體兩面

我們無法主宰我們不了解的東西

4

由老手展現如何賣收銀機，事後證明，這是一個很好的經驗傳承方式。

惱人的流程圖

流程圖是最被過度強調的文件，許多程式一點都不需要流程圖，也很少程式需要一頁以上的流程圖。

“我從未看過一個程式老手在開始寫程式之前會乖乖畫出詳細的流程圖，也許組織會制定標準並規定一定要畫流程圖，但實際上這多半會流於形式。”

自我說明程式

合併文件，把書面說明整合到程式碼裡頭，這麼做將大幅改善維護工作，而且保正程式使用者可以隨時便利地參考文件，這種做法稱為程式的自我說明。

16. 沒有銀彈

再未來的十年之內，無論是在技術上或管理上，都不會有任何單一的重大突破，能保證在生產力、可靠度或簡潔性上獲得改善，甚至，連一個數量級的改善都不會有。

作者建議

多加利用大眾市場，避免開發現成就買得到的東西。

再制定軟體需求十，採用多次反覆的方式，並把快速型製作，納入所規劃的每個反覆之中。

讓軟體像生物一樣地發育成長，在系統持續被執行、被使用、被測詴的過程中，逐步擴充功能。

持續尋覓並培養年輕一大偉大的概念設計人員。

有志者事竟成

人類能克服疾病的第一步，就是以細菌說淘汰了惡魔說和體液說，正是這一步，帶給了人類希望，粉碎了所有奇蹟式的冀望，告訴人們進步是要靠按部就班、不辭辛苦而來，得在清潔衛生方面持續不斷地投入新血，養成良好的習慣，才是正道。如今，我們面對軟體工程也是一樣。

5

特別一提—偉大的設計師

“關於如何提升軟體技藝這個核心問題，一如既往，其關鍵在人。”