一、關於人月神話這本書
記得在上大學的時候，就經常聽學長和老師講起《人月神話》，但是卻一直沒有閱讀。記得當時一聽到這個書名，還以為是個神馬科幻類別的書，結果是個軟件工程方面的書籍。這本書是“圖靈獎得主、“IBM360系統之父”作者Brooks寫的，人們都說它顛覆了項目管理領域，是一本長久不衰的傳奇經典，暢銷了40多年。的確，在我們熟悉的豆瓣讀書上面，它的評分達到了8.6（滿分10分），不可不畏是一本好書。最近快速地閱讀完后，按照我的老規矩，也需要總結總結，寫一篇筆記來日后回顧之用。
二、什么是“人月神話”？
“人月”這個詞英文原文是“Man Month”，代表一個人一個月的時間內能夠完成的工作量，在軟件開發項目管理中，常用來估算任務量，比如“這個項目需要多少個人月？”。很多時候我們或多或少都有過這樣的經歷，很多的項目管理人員總是希望通過增加更多的人手來加快軟件工程的完成進度。比如，一個工作量為10個人月的項目，如果只有一個人做，需要10個月才能完成。於是，我們的項目管理人員認為，只要再加入9個人，那么10個人一起做，就只需要一個月啦。然而，實際情況並非如此，因此軟件工程的各項工作之間，往往存在着一個前后繼承的關系，完成了這一項，下一項才能開始。那么，加進來的人手呢，他並不能立即開始工作。所以，想要通過增加人手來縮短工程時間，其實只是一個“神話”而已。這里，就不得不提經常被拿來舉例的一個例子，一個孕婦生一個小孩需要10個月，那么請10個孕婦來就只需要1個月啦？顯然是不可能完成的任務。
而“人月神話”反映出的，就是軟件開發在項目管理中所遇到的難題：管理人員因為盲目樂觀，對項目開發過程中的困難沒有充分的認識，在計算項目的工作量和交付時間上采用了錯誤的計算方法，忽略了細節對整體的巨大影響，而這很可能會導致項目延期。
三、如何處理“人月神話”的困境？
首先，作者建議，以小團隊的方式開展工作。
這里不得不說，作者在當時提出了一個類似於外科手術團隊的組織結構來開展工作。外科手術團隊的奧秘就在於，它是以主刀醫生為核心，其他像負責助理醫生、麻醉師、護士等人都是為主刀醫生服務的，大家各司其職、齊心協力，從而保證手術順利完成。那么，反映到軟件工程上面，就是以架構師或者高級程序員充當主刀醫生的角色，而團隊管理者充當副手或者服務人員，其他團隊成員則分別負責單元代碼編寫，功能單元測試，文檔管理，工具開發及技術支持等等。即使整個項目團隊的人數龐大，但只要根據工作邊界，將大家划分到一個個類似於外科手術隊伍那樣的小團隊當中去，就可以保障在一定程度上的效率提升。
其次，要進行行之有效的溝通。
定期召開項目進度例會，對數據結構進行監督和全員反饋等等，都是常見的增進溝通的手段。而近年來流行的敏捷開發模式，例如Scrum這種敏捷開發流派，就特別倡導小團隊的高頻率的溝通，每個迭代（大概2周一個迭代）都會完整經歷計划會議、每日站立會議、項目評審會議、團隊回顧會議等，特別是每日站立會議，雖然一般只有短短15分鍾，但是確是增進溝通的主要行之有效的方式。
此外，作者還在特別強調了兩個點：
- 使用產品文檔
- “手把手帶”的溝通方式
最后，要“防微杜漸”
關於“防微杜漸”，作者具體給出了幾點建議：
- 在項目推進的過程中設立一些關鍵節點，作者稱之為“里程碑事件” => 我所在的團隊每天的站立會議都會設立“今日目標”，也就是一些里程碑，在每天下班時后看看這些里程碑事件完成了多少，如果完成100%那么久擦掉，如果沒有就說明情況和問題，留到下一個工作日繼續完成。
- 為項目設立一個專門的規划和控制小組
- 項目管理必須認清一個現實：“唯一不變的就是變化” => 我所在的團隊經歷過多次需求大改的情況，迫使我們每次修改都要面向未來考慮變化點和可擴展性
- 為了避免項目延遲和失敗，要盡可能地提前集成測試 => 只有盡快集成測試，才能暴露前后端在對於backlog的理解上存在的問題，有沒有完成AC（驗收條件）
四、“人月神話”為何無法徹底解決？
“人月神話”中的一些問題，其根源在於軟件工程本身的特性，是無法徹底解決的，這也是廣大IT從業人士的共識。其原因歸根結底有以下幾點：
- 計算機技術的發展實在是太快了 => 想想摩爾定律到現在前后端的框架變化，我們時常感嘆前一陣子學的東西現在又被淘汰了，是否要開始學習AI了？
- 軟件研發本身的內在的特性也制約了軟件工程的進展 => 作者用了4個詞來概括這種特性：復雜性、一致性、可變性和不可見性。
五、改善軟件開發根本困境的建議
雖然作者說到上面提到的這些困境是軟件開發的根本困難，無法徹底解決。但是，它還是給出了三方面的建議，來盡可能改善這種困難造成的困境：
- 采用新技術 => 使用高級語言總比低級語言方便吧，使用.NET Core總比.NET Framework程序性能和跨平台好吧？
- “快速開發原型”，然后再做“增量開發” => 其實跟我們的敏捷開發思想一致，通過在不斷地迭代反復中堆成一個完整的系統，在精益創業中，也有一個MVP（最小可用產品）的概念，它提倡快速原型試錯，快速獲取市場反饋，然后再慢慢完成最后的完整的產品。
- 聘用卓越人才 => 這一點毋庸置疑，有了新的技術和敏捷開發，還需要合格的、追求卓越的程序員人才，這讓我想起了ThoughtWorks這家公司，它是一個尊重技術，提倡敏捷並且積極追求卓業人才的代表性企業，Martin Fowler是其首席科學家，無數的咨詢師走上了技術布道之路，敏捷開發，DDD，微服務等實踐總結和分享雨后春筍般地出來，向ThoughtWorks致敬。
整體腦圖
參考資料
弗雷德里克·布魯克斯，《人月神話》
王福強，《喜馬講書：人月神話》