書名：人月神話：軟體專案管理之道 (The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition))
譯者：錢一一
ISBN：9867889185
出版商：農學社
出版日期：2004-04-01
頁數：405
最近把這本書看完，此書的作者Frederick P. Brooks曾在IBM任職時擔任過超過一千人的專案主導人，而書裡的內容正是作者在專案結束後所獲得的經驗跟反思。
對於急於知曉書中精要的人，可以把前序跟後記看完，有個概觀後，直接跳讀第18章「《人月神話》的主張：是真是假？」，再依序閱讀16章「沒有銀彈：軟體工程的本質性與附屬性工作」，17章「再論『沒有銀彈』」，19章「《人月神話》二十年」。
第一章中作者對程式、軟體系統、軟體產品、軟體系統產品的定義與區分，對我來說是一個衝擊。
程式：本身是完整的，寫這個程式的人可以在開發系統上執行它……也就是個別的程式設計師用以評估生產力的東西。
軟體產品：可以讓任何人執行、測試、修改和擴充的程式，並且適用於多種操作環境，以及不同情況的資料。……必須以通用的風格來編寫，特別是輸入資料的範圍與形式……程式必須經過徹底的測試……一個程式要晉升為軟體產品，還必須有完整的文件，以指引別人使用、修改或擴充它。
軟體系統：彼此交互運作的一組程式集合，程式之間有律定共同的資料格式與合作模式……。
軟體系統產品：不同於以上所述的簡單程式……但卻是真正有用的，也是大部分軟體工程企圖要做出來的東西。
關於如何要求工程師寫程式文件，作者在第15章「一體兩面」中提到：
多年來，我一直辛勤地工作，並在軟體工程的課堂上強調好文件的必要性，但即使一再地諄諄教誨，卻還是沒用。我假設學生們其實已經學會了如何寫好文件，只是缺乏寫文件的動力，所以我嘗試……親自上場展現文件怎麼寫，這下子效果就好多了。
書中227頁便展示了一段程式，並說明作者如何在程式中寫註解。這樣的方式，很明顯的比單獨列出原則清晰許多。
所謂的「人月神話」是當專案進度落後時，試圖招募更多的人手來解決落後的進度，反而會招致反效果。原因是必須有原專案成員訓練新進人員，訓練完成前，能工作的人力反而減少；當新進人員訓練完成後，原有工作的重新分配及成員之間的溝通變得更加不易，也會拖延專案的進行（作者強調專案架構概念的一致性對於系統的穩定及建構非常重要，而新進人員可能無法維持架構概念的一致性）。另外，有些專案系統的建構工作是連續性不可切割的，也使人手的增多無助於追趕進度。
專案人員之間有良好溝通的重要性也在於要維持系統架構的一致，但本書作者與《The Art of Designing Embedded Systems》的作者Jack Ganssle都強調，根據研究，安靜不受打擾的工作環境對提昇工作效率有極大的幫助。
作者認為在開始寫程式之前，將規格、介面先仔細考慮訂定，並寫成文件，可以藉由文件溝通，讓成員清楚架構概念。另外，為了避免概念不一致，作者建議專案的架構設計以集權的方式來進行。
系統建置的時候，每一個模組都應先測試，並解決所發現的錯誤後才可以加入系統中。模組加入系統中後，需再做測試，以確定系統的穩定及模組間的正常運作。作者建議系統的建置採模組功能漸增的方式來進行，維持一個持續可穩定運行的系統，才不至於在時程快要結束時，既無法完成所有功能，也不能建立可運行的系統。
在《The Art of Designing Embedded Systems》中所提到的code review的進行方式，我認為可以輔助達到「人月神話」作者所提到上述原則。透過code review，實作人員可以對系統的其他架構更加瞭解，減少程式的錯誤，增加程式的可讀性，並同時知道其他人寫了哪些函式，以後若有需要可加以利用（這增加了程式的再利用）。
相關文章：
你是雲雀(lark)、貓頭鷹(owl)，還是蜂鳥(hummingbird)？
熬夜加班（唸書）有多沒效率？
劣幣驅逐良幣的加班文化
別搞錯了，Google的「打盹艙nap pods」可不是員工福利
松下幸之助談工作
樵夫
學習新解：多元智能理論心理學家的看法
《大腦當家：靈活用腦12守則，學習工作更上層樓》(Brain Rules)
傑克‧威爾許(Jack Welch)檢驗策略的5張投影片
為顧客創造價值
繼續閱讀...
