# 人月神話心得 ### 摘要 ### > [color=#e31cea]僅對有心得處做摘要 #### 1.焦油坑 兩個人所能做出的程式很有可能比的上一個千人團隊，為何千人團隊無法做出相對應的程式呢?程式、軟體系統、軟體商品、軟體系統商品是不同的東西。兩個人想完成軟體系統商品所耗的時間是難以估量的，團隊的時間花的少卻也需要去適應每個人對城市的想法與程式碼的撰寫方法，這也導致許多傑出的程式設計師宛如巨獸一般陷在焦油坑，空有力氣卻無法逃脫。寫程式的樂趣1.憑空創造並實現2.所做出的成品對他人有所幫助3.邏輯推演並實現的過程4.不斷學習的樂趣；寫程式的痛苦1.不是所有元素都操之在己手，也需要別人幫忙2.要去適應電腦的完美性，一個小小的bug就可能讓電腦停止運作3.花的時間不成比例，找個bug找到腦袋炸裂4.驗證麻煩，不管如何驗證總是難以符合現實中的各式狀況，很有可能設想中沒問題，卻在實現過程遇到重大挫折5.商品完成後已經趕不上最新的潮流了 #### 2.人月神話 軟體專案不順利的原因很多。1.預估時程的技術不成熟2.將工作量跟專案進度混為一談---人力跟工時不一定可以互換3.預估無法篤定4.時程缺乏有效的監控5.延誤時總會想添加人手---大錯特錯的決定。許多軟體工程師總對自己的工作過度樂觀，但bug會出現在哪邊我們無法預測。人月神話(執行時間跟工作人數有關)使用在不需彼此互相溝通或干涉的情況下是成立的，比如採收或是種田，但軟體專案就像是懷孕生小孩一樣，再多的媽媽同時生還是得懷胎九個月。系統測試很重要，1/3用在規劃、1/6用在撰寫程式、1/4組件測試和早期系統測試、1/4系統測試並完成所有組件。我們總會認為程式出來了，就離成功不遠了，但實務上的經驗告訴我，除錯跟整合才是最花時間的，最好多分配一些時間在除錯上。在一個時程已經落後的軟專案中增添人手，只會讓他更加落後。 #### 三、外科手術團隊 一個好的程式設計師做出來的程式可能比二流程式設計師的效果好上數倍，2萬美元的人的生產力跟記憶體配置可能為1萬美元的人多出4、5倍。要同時兼顧工作效率及架構整體性是兩難，從上一章可以得知越多的人不代表完成速度越快，但是人數過過少又會導致工作的速度太慢，以作者為例5000/(20*7*7)=10，若以20人團隊開發5000人年的商品需耗費十年，完成也已過時。作者提倡用外科手術團隊的形式來細分一項大型專案，外科手術團隊由一位醫生主刀，剩餘人手皆為輔助，有明確上下級關係，統一對一人負責，首席程式設計師對主程式撰寫並規劃，通常由資深程式設計師負責。可以有效將十人團隊降為一人主導，程式也不易衝突。在200人團隊中則由20位資深設計師負責，大量降低溝通及架構問題。合作時，整個系統必須具備架構整體性，而這需要一位系統架構設計師由上到下進行全部設計，為了要讓工作易於掌控，就必須在與實作之間做出明確區分。 #### 四、專制、民主與程式設計 整體性大過一切，就算有人提出的新架構更好，也不一定適合用在現有的方式架構上，最好的方式就是在另立一個產品。架構設計更多著重的點在於使用者介面，實作者則注重在功能性，這兩者有實是相對的，更詳細的設定功能性更強大，但學習成本也更多，必須在當中做取捨，架構設計則是先給定一個目標，讓實作者在這組框架下去達到最佳功能。 #### 五、第二系統效應 架構設計師在設計第一次的產品實，因為沒有相關經驗，會做的相對保守，當有了一次的成功經驗後，就會將各式奇思妙想用在第二系統---不管是不是系統所需要的。第二系統效應可能造成產品擁腫肥大，跟不上新潮流，為了實現架構設計的美學浪費大量資源，這種情況難以避免，只能在事後做出檢討，或是找尋具有豐富設計經驗架構設計師。 #### 六、意念傳達 溝通很重要，好的溝通方式包括定期開會，每周一次的會議跟每半年一次大會。每周的會議針對各技術部分的變動進行討論，確保大家有在同個方向，半年的會議則針對每周會議未達成的部分進行討論，若有人有意見或是不同想法也是好的發洩管道。技術手冊很重要，如果可以的話，讓每個技術人員人手一本，對每一項變動進行詳細的紀錄，也知道各部分的變動的原因，可以的話也是每週更新一次。 #### 九、地盡其利，物盡其用 資料的傳輸會耗費許多時間或記憶體，各單位如何去溝通使用是個重要的過程，要在時間跟成本中去做取捨。又小又快的程式幾乎都源自於策略上的突破，而非技術上的取巧。資料結構比演算法重要多了，資料呈現的方式是設計的本質。 #### 十、文件假說 在成堆的書面資料中，有一小部分關鍵性文件記錄著任何專案管理的核心工作，而這些文件是身為管理者最重要的工具。 做什麼(What):目標 做什麼(What):產品規格，操作手冊及內在性能的描述，執行速度與耗用空間為重點。 何時做(When):時程 多少錢(How much):預算 哪裡做(Where):場地配置 由誰做(Who):組織編制圖 任何管理工作所在意的都是人、地、時、物、錢。 要有正式文件的原因 1. 把事情寫下來，矛盾跟遺漏之處才會顯現出來 2. 有傳達他人之用，不是每個人都對你的規畫清楚明白 管理者只需要著重在少部分資料上就好，剩餘時間大都花在溝通上，傾聽、報告… #### 十一、失敗為成功之母 無論如何，把必然的一次失敗加入正式計畫中。不只目標會改變，軟體開發跟技術都會改變，丟掉重做的概念本身就是要你先學會竅門、然後改變設 計的事實。軟體易於更動，顧客也喜歡提出各式更改，不管如何都要有個底線，移植增加功能的話商品永遠無法完成。組織要有所彈性，管理人員應該要和資深技術人員站有同等地位，管理人員上技術課，技術人員上管理課，方便地位的改變，也了解彼此的難處，外科手術團隊可以應付這種轉變。軟體開發是個簡單且趨於穩定的過程，軟體維護則是複雜化且趨於混亂的過程。軟體會一直維護直到效益跟成本不相上下，順勢推出新產品。 #### 十四、釀成大災難 每一項瑣事都消耗個半天一天，於是進度就嚴重落後了，要訂出一個里程碑，每個里程碑都應該具有明確的目標。如果結鍋都計畫的好好的，也容易讓人失去幹勁，對於一個小延誤，我們必須即時的激起幹勁，界決問題，否則遲早釀成大災難。第一線主管傾向於獎小延遲隱瞞起來，想要自己處理，但這樣容易釀成大禍，要讓小主管願意跟老闆說明小問題的要點有二。1.降低角色衝突，只是了解問題的產生，而不過度插手問題，相信他有解決的能力，將會議明確規劃成報告執行狀況跟討論解決方案兩種會讓他們更有意願。2.揭開一切順利的假象每過一段時間就檢查一次，可將日期規劃成理想時間跟是實際狀況修改的時間。 ### ### 心得 在閱讀此書時，有種相見恨晚的感覺。我自己本身沒有做過大型專案，但有修過志宏老師的計算機程式，那時是四人一組，做出小型單機遊戲。當時的慘痛經驗跟書中形容幾乎一樣，老師上課時就一再強調變數跟撰寫邏輯的一致性，但對我們這些初學者而言，變數可一眼看出，但設計理念每個人都不一樣，我當時是負責主程式撰寫的部分，剩餘小function發包出去，但回收再整合的過程卻痛不欲生，跟作者的焦油坑所形容的差不多，對他人程式每做一部份的更改都會跳出新的錯誤，在溝通上也耗費許多時間，有人訊息愛回不回，最後有許多部份都是由我直接打掉重練。接近期末時日期已經嚴重Delay，我決定由我負責操刀整體程式撰寫，由好聯絡且家住附近的同學當副手，花費一個星期對全部程式大改，剛好切合到作者所提的外科手術團隊，剩餘兩位組員則負責美術音樂等部分。在人月神話上則是提供我一個全新的看法，不是每種工作投入大量人力物力都會有所進展，在早先撰寫專案時我也是一直保持這種看法，見樹不見林，認為若配給我數量更多且能力更佳的同學就能夠撰寫出來，但看起來跟事實相去勝遠。第二系統效應我也見識到我了，當時的眾多小組中，就有一組是由能力出眾的小所組織而成的，但最後的成品卻沒有達到到他們的理想，我認為可能是他們為了達到最好的效果而花了過多的時間在之微末節上，最後導致遊戲整體性不足。 在面對自己沒有把握的事情時，我喜歡邊做邊學，不停的試錯去完成我想要的結果，但在完成有基礎的專案時，卻傾向於一切都準備好再出發，不久前在實作一項演算法時，攢算法本身並不困難，為了讓所有記憶體得到最佳的配置，function看起來簡潔有力而花了過多的時間，最後也被老師念了一頓，課堂老師也是從最簡單的部分做起，在慢慢完成整體，默認地一次撰寫必定出錯看起來是個不錯的提議。 書中也提及許多專案管理的方式，我認為對於理工科來說是相當有用的，讀到精闢處真的會拍案叫絕，但也有許多部份是我目前我還沒遇過的。看完後也對於各種不一樣的工程師有了更多的了解，也發覺賈伯斯的厲害之處，架構工程師跟軟體工程師的重要性分別在哪。有點小可惜的地方是本書許多例子都早已過時，增訂版也是20年前的產物了，又有許多新問題被發現，舊問題被解決，也期待未來能夠有有有志之士以本書為架溝出版新的增訂版。