也讀《人月神話》：沒有銀彈的軟體工程

一、關於人月神話這本書

　　記得在上大學的時候，就經常聽學長和老師講起《人月神話》，但是卻一直沒有閱讀。記得當時一聽到這個書名，還以為是個神馬科幻類別的書，結果是個軟體工程方面的書籍。這本書是“圖靈獎得主、“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致敬。

整體腦圖

參考資料

弗雷德裡克·布魯克斯，《人月神話》

王福強，《喜馬講書：人月神話》