一、關(guān)于人月神話這本書

　　記得在上大學(xué)的時候，就經(jīng)常聽學(xué)長和老師講起《人月神話》，但是卻一直沒有閱讀。記得當(dāng)時一聽到這個書名，還以為是個神馬科幻類別的書，結(jié)果是個軟件工程方面的書籍。這本書是“圖靈獎得主、“IBM360系統(tǒng)之父”作者Brooks寫的，人們都說它顛覆了項(xiàng)目管理領(lǐng)域，是一本長久不衰的傳奇經(jīng)典，暢銷了40多年。的確，在我們熟悉的豆瓣讀書上面，它的評分達(dá)到了8.6（滿分10分），不可不畏是一本好書。最近快速地閱讀完后，按照我的老規(guī)矩，也需要總結(jié)總結(jié)，寫一篇筆記來日后回顧之用。

二、什么是“人月神話”？

　　“人月”這個詞英文原文是“Man Month”，代表一個人一個月的時間內(nèi)能夠完成的工作量，在軟件開發(fā)項(xiàng)目管理中，常用來估算任務(wù)量，比如“這個項(xiàng)目需要多少個人月？”。很多時候我們或多或少都有過這樣的經(jīng)歷，很多的項(xiàng)目管理人員總是希望通過增加更多的人手來加快軟件工程的完成進(jìn)度。比如，一個工作量為10個人月的項(xiàng)目，如果只有一個人做，需要10個月才能完成。于是，我們的項(xiàng)目管理人員認(rèn)為，只要再加入9個人，那么10個人一起做，就只需要一個月啦。然而，實(shí)際情況并非如此，因此軟件工程的各項(xiàng)工作之間，往往存在著一個前后繼承的關(guān)系，完成了這一項(xiàng)，下一項(xiàng)才能開始。那么，加進(jìn)來的人手呢，他并不能立即開始工作。所以，想要通過增加人手來縮短工程時間，其實(shí)只是一個“神話”而已。這里，就不得不提經(jīng)常被拿來舉例的一個例子，一個孕婦生一個小孩需要10個月，那么請10個孕婦來就只需要1個月啦？顯然是不可能完成的任務(wù)。

　　而“人月神話”反映出的，就是軟件開發(fā)在項(xiàng)目管理中所遇到的難題：管理人員因?yàn)槊つ繕酚^，對項(xiàng)目開發(fā)過程中的困難沒有充分的認(rèn)識，在計算項(xiàng)目的工作量和交付時間上采用了錯誤的計算方法，忽略了細(xì)節(jié)對整體的巨大影響，而這很可能會導(dǎo)致項(xiàng)目延期。

三、如何處理“人月神話”的難題？

首先，作者建議，以小團(tuán)隊(duì)的方式開展工作。

　　這里不得不說，作者在當(dāng)時提出了一個類似于外科手術(shù)團(tuán)隊(duì)的組織結(jié)構(gòu)來開展工作。外科手術(shù)團(tuán)隊(duì)的奧秘就在于，它是以主刀醫(yī)生為核心，其他像負(fù)責(zé)助理醫(yī)生、麻醉師、護(hù)士等人都是為主刀醫(yī)生服務(wù)的，大家各司其職、齊心協(xié)力，從而保證手術(shù)順利完成。那么，反映到軟件工程上面，就是以架構(gòu)師或者高級程序員充當(dāng)主刀醫(yī)生的角色，而團(tuán)隊(duì)管理者充當(dāng)副手或者服務(wù)人員，其他團(tuán)隊(duì)成員則分別負(fù)責(zé)單元代碼編寫，功能單元測試，文檔管理，工具開發(fā)及技術(shù)支持等等。即使整個項(xiàng)目團(tuán)隊(duì)的人數(shù)龐大，但只要根據(jù)工作邊界，將大家劃分到一個個類似于外科手術(shù)隊(duì)伍那樣的小團(tuán)隊(duì)當(dāng)中去，就可以保障在一定程度上的效率提升。

其次，要進(jìn)行行之有效的溝通。

　　定期召開項(xiàng)目進(jìn)度例會，對數(shù)據(jù)結(jié)構(gòu)進(jìn)行監(jiān)督和全員反饋等等，都是常見的增進(jìn)溝通的手段。而近年來流行的敏捷開發(fā)模式，例如Scrum這種敏捷開發(fā)流派，就特別倡導(dǎo)小團(tuán)隊(duì)的高頻率的溝通，每個迭代（大概2周一個迭代）都會完整經(jīng)歷計劃會議、每日站立會議、項(xiàng)目評審會議、團(tuán)隊(duì)回顧會議等，特別是每日站立會議，雖然一般只有短短15分鐘，但是確是增進(jìn)溝通的主要行之有效的方式。

　　此外，作者還在特別強(qiáng)調(diào)了兩個點(diǎn)：

• 使用產(chǎn)品文檔

• “手把手帶”的溝通方式

最后，要“防微杜漸”

　　關(guān)于“防微杜漸”，作者具體給出了幾點(diǎn)建議：

• 在項(xiàng)目推進(jìn)的過程中設(shè)立一些關(guān)鍵節(jié)點(diǎn)，作者稱之為“里程碑事件” => 我所在的團(tuán)隊(duì)每天的站立會議都會設(shè)立“今日目標(biāo)”，也就是一些里程碑，在每天下班時后看看這些里程碑事件完成了多少，如果完成100%那么久擦掉，如果沒有就說明情況和問題，留到下一個工作日繼續(xù)完成。

• 為項(xiàng)目設(shè)立一個專門的規(guī)劃和控制小組

• 項(xiàng)目管理必須認(rèn)清一個現(xiàn)實(shí)：“唯一不變的就是變化” => 我所在的團(tuán)隊(duì)經(jīng)歷過多次需求大改的情況，迫使我們每次修改都要面向未來考慮變化點(diǎn)和可擴(kuò)展性

• 為了避免項(xiàng)目延遲和失敗，要盡可能地提前集成測試 => 只有盡快集成測試，才能暴露前后端在對于backlog的理解上存在的問題，有沒有完成AC（驗(yàn)收條件）

四、“人月神話”為何無法徹底解決？

　　“人月神話”中的一些問題，其根源在于軟件工程本身的特性，是無法徹底解決的，這也是廣大IT從業(yè)人士的共識。其原因歸根結(jié)底有以下幾點(diǎn)：

• 計算機(jī)技術(shù)的發(fā)展實(shí)在是太快了 => 想想摩爾定律到現(xiàn)在前后端的框架變化，我們時常感嘆前一陣子學(xué)的東西現(xiàn)在又被淘汰了，是否要開始學(xué)習(xí)AI了？

• 軟件研發(fā)本身的內(nèi)在的特性也制約了軟件工程的進(jìn)展 => 作者用了4個詞來概括這種特性：復(fù)雜性、一致性、可變性和不可見性。

五、改善軟件開發(fā)根本難題的建議

　　雖然作者說到上面提到的這些困境是軟件開發(fā)的根本困難，無法徹底解決。但是，它還是給出了三方面的建議，來盡可能改善這種困難造成的困境：

• 采用新技術(shù) => 使用高級語言總比低級語言方便吧，使用.NET Core總比.NET Framework程序性能和跨平臺好吧？

• “快速開發(fā)原型”，然后再做“增量開發(fā)” => 其實(shí)跟我們的敏捷開發(fā)思想一致，通過在不斷地迭代反復(fù)中堆成一個完整的系統(tǒng)，在精益創(chuàng)業(yè)中，也有一個MVP（最小可用產(chǎn)品）的概念，它提倡快速原型試錯，快速獲取市場反饋，然后再慢慢完成最后的完整的產(chǎn)品。

• 聘用卓越人才 => 這一點(diǎn)毋庸置疑，有了新的技術(shù)和敏捷開發(fā)，還需要合格的、追求卓越的程序員人才，這讓我想起了ThoughtWorks這家公司，它是一個尊重技術(shù)，提倡敏捷并且積極追求卓業(yè)人才的代表性企業(yè)，Martin Fowler是其首席科學(xué)家，無數(shù)的咨詢師走上了技術(shù)布道之路，敏捷開發(fā)，DDD，微服務(wù)等實(shí)踐總結(jié)和分享雨后春筍般地出來，向ThoughtWorks致敬。

整體腦圖

參考資料

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

王福強(qiáng)，《喜馬講書：人月神話》

---

總結(jié)

以上是生活随笔為你收集整理的也读《人月神话》：没有银弹的软件工程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。