這學期修了「專案管理」及「軟體工程」兩門課，兩門課不約而同的都推薦「人月神話」這本書，於是便以看雜誌的心情訂購了他但是擺了幾個星期，只翻了「序」.......
直到今天晚上，很仔細的看完前三章讓我感到異常驚訝!!!(這是武功秘笈吧!!為何到現在才看到這本書....)，書中很到位的描述了這十年來工作經驗的經驗體驗心得。彷彿是一本預言古書(因為他是30幾年前的書，到現在還很暢銷)，在那麼久以前就準確說出軟體開發的過程的種種問題。
但書是老了，但對於軟體開發過程中對於人、時間、資源的描述仍然和現在一樣，沒有太多的改變。底下是他的目錄，由於是 1975 年出版的書作者有在1995年時修訂過一次增加 18,19章。底下是他的目錄索引，我打算寫個心得摘要記錄......
人月神話
- 第 1 章 焦油坑（The Tar Pit）
- 第 2 章 人月神話（The Mythical Man-Month）
- 第 3 章 外科手術團隊（The Surgical Team）
- 第 4 章 專制、民主與系統設計（Aristocracy, Democracy, and System Design）
- 第 5 章 第二系統效應（The Second-System Effect）
- 第 6 章 意念的傳達（Passing the Word）
- 第 7 章 巴別塔為什麼失敗？（Why Did the Tower of Babel Fail?）
- 第 8 章 預估（Calling the shot）
- 第 9 章 地盡其利，物盡其用（Ten Pounds in a Five-Pound Sack）
- 第 10 章 文件假說（The Document Hypothesis）
- 第 11 章 失敗為成功之母（Plan to Throw One Away）
- 第 12 章 神兵利器（Sharp Tools）
- 第 13 章 化整為零（The Whole and the Parts）
- 第 14 章 釀成大災難（Hatching a Catastrophe）
- 第 15 章 一體兩面（The Other Face）
- 第 16 章 沒有銀彈：軟件工程的本質性與附屬性工作（No Silver Bullet – Essence and Accident in Software Engineering）
- 第 17 章 再論「沒有銀彈」（"No Silver Bullet" Refired）
- 第 18 章 《人月神話》的主張：是真是假？（Propositions of The Mythical Man-Month: True or False?）
- 第 19 章 《人月神話》二十年（The Mythical Man-Month after 20 Years）
第一章介紹焦油坑(La Brea)
位於美國洛杉磯，數千萬年前成千上萬的大型動物誤入而沉沒於焦油之中，最後成為化石。形容大型專案的開發，早晚會掉入焦油坑內只是早晚的問題。也難怪微軟一直砍掉重練作業系統。
寫程式很有趣，但是當程式要變成產品就不是那樣的快樂且通常會花比寫程式還多更多的時間。除錯過程佔了一半的時間，且不會有收斂的捷徑。另外產品完成後，新的產品技術會出現，但不會立即產生成品實作出來。所以仍是需要時間實作的，現成的紙老虎永遠比想像中的真老虎強大。
第二章人月神話
專案不順利通常肇因於時程規劃：
1.時程預估技術不成熟，但是通常會樂觀面對。
2.工作量和專案進度混為一談，以為人力和工時可以轉換。
3.對於自己做的預估沒有信心。
4.時程進行缺乏監控。
5.時程延宕增加人手，這只是火上加油。
軟體開發是一種創作過程，構想、實作、互動是必須的過程，通常要到互動時候才會發現前面的問題。所以樂觀的認為是常見的初期行為....
人月是衡量軟體工作的單位，適合用於可以切分的工作，但對於連續性或是需要創作協調的工作無法以人月天來計算完成。
作者經驗法則中的軟體專案的時程安排：
1/3 規劃 -- 佔比想像多的時間
1/6 寫程式
1/4 組件測試和早期系統測試
1/4 系統測試完成所有的組件
沒寫錯比例，就是這樣沒錯。
對於專案有堅持自己的預估勇氣，畢竟牛排加上大火烹調只會燒焦然後變成失敗的作品。
增加人力的時程安排，需要更加仔細的考量，因為加了人力後新手會有額外的成本，在短時間內不會增加效率，反而是火上加油。
第三章 外科手術團隊
一個 10 人的團隊和 200 人的團隊的軟體開發是不一樣的工作方式。
程式設計師工作效率上的差異可以到 10 : 1 的差距。
Harlan Mills 提出一個十人的團隊，由不同的人組成在加上外科醫師決策主導這樣的效率最佳。
手術團隊的運作方式不允許不同的喜好，完全由外科醫生做決策，且不切割問題、主從關係使得這個團隊是同心一致的。且因為這團隊有專業分工，所以溝通上變得簡單。
Scaling up(擴大規模)到 200 人的過程是否可以成功，決定在系統個片段的概念整體性是否可以加強，如果 20 人的專案領導成員可以合作的話..... 合作必然有工作切分的問題，為了讓工作易於掌控必須在架構上面及實作上面做出區分，讓兩個角色分別被專注。
手術團隊的運作方式不允許不同的喜好，完全由外科醫生做決策，且不切割問題、主從關係使得這個團隊是同心一致的。且因為這團隊有專業分工，所以溝通上變得簡單。
Scaling up(擴大規模)到 200 人的過程是否可以成功，決定在系統個片段的概念整體性是否可以加強，如果 20 人的專案領導成員可以合作的話..... 合作必然有工作切分的問題，為了讓工作易於掌控必須在架構上面及實作上面做出區分，讓兩個角色分別被專注。
第四章 專制、民主與系統設計
系統設計時保有整體概念性是最重要的原則，所以需要一個系統架構設計師。
1. 架構設計師與實作人員的爭議要注意？
2. 防止架構設計師訂出不合理的規格？
3. 確保架構的細節能與實作人員溝通
當功能增強所節省的時間超過學習、記憶與翻閱手冊所耗費的時間，電腦的便利性才會提昇。所以目標為使用便利性，所以功能概念複雜度比(ratio of function to conceptual complexity )，才是系統設計的最終標準。
要達成整體概念性，最好出自同一人隻手。但很難，所以分成架構與實作兩部分小心工作。
架構：做什麼？
實作：如何做。
架構就是限制框架，讓實作者可以不用做超出規格或不必要的功能。在有限的架構內，發會最大的實作創意，如果給太多的資源，做出來的實作通常是悲劇。
在架構還沒出來前，不要給實作人員去主導開發，那會造成災難。
架構是由少數人組成的時候，會有些盲點：
系統設計時保有整體概念性是最重要的原則，所以需要一個系統架構設計師。
1. 架構設計師與實作人員的爭議要注意？
2. 防止架構設計師訂出不合理的規格？
3. 確保架構的細節能與實作人員溝通
當功能增強所節省的時間超過學習、記憶與翻閱手冊所耗費的時間，電腦的便利性才會提昇。所以目標為使用便利性，所以功能概念複雜度比(ratio of function to conceptual complexity )，才是系統設計的最終標準。
要達成整體概念性，最好出自同一人隻手。但很難，所以分成架構與實作兩部分小心工作。
架構：做什麼？
實作：如何做。
架構就是限制框架，讓實作者可以不用做超出規格或不必要的功能。在有限的架構內，發會最大的實作創意，如果給太多的資源，做出來的實作通常是悲劇。
在架構還沒出來前，不要給實作人員去主導開發，那會造成災難。
架構是由少數人組成的時候，會有些盲點：
沒有留言:
張貼留言