??人月神話是一篇由美國軟件工程師弗雷德里克·布魯克斯所寫的軟件工程經典之作，最早發(fā)表于1975年。這篇文章的全名是《人月神話：軟件工程的神話與現實》（The Mythical Man-Month: Essays on Software Engineering），它涵蓋了布魯克斯在IBM公司參與OS/360操作系統(tǒng)開發(fā)過程中的經驗和觀察。
??本書英文版一經面世，即引起業(yè)內人士的強烈反響，后譯為德、法、日、俄、中、韓等多種文字，成為軟件開發(fā)和管理人員的必讀經典。

??作者簡介：熱愛跑步的恒川，致力于C/C++、Java、Python等多編程語言，熱愛跑步，喜愛音樂的一位博主。
??本文收錄于恒川的日常匯報系列，大家有興趣的可以看一看
??相關專欄C語言初階、C語言進階系列、恒川等，大家有興趣的可以看一看
??Python零基礎入門系列，Java入門篇系列、docker技術篇系列、Apollo的學習錄系列正在發(fā)展中，喜歡Python、Java、docker的朋友們可以關注一下哦！

一、讀《人月神話》后的感想

??最近讀了一本書《人月神話》，這本書是軟件工程類的一本經典著作。閱讀這本書的第一感受就是感覺這本書不像是一種和學習相關的書，更像是用很多形象的比喻，闡述項目管理當中的一些問題，讓讀者能夠很輕松，明白的去閱讀。一般在大學學習計算機行業(yè)的時候，都會學習一門叫做軟件工程的課程，老師也會跟我們講一些關于“軟件項目開發(fā)的完成與增加人員的問題”，在讀這本書的時候，這個問題給了我很大的感觸。很多人認為，當任務在規(guī)定期限內還完成不了的時候，適當的加一些人員進去，可以加快任務的進度，從而能夠在規(guī)定的時間完成任務。但是這個觀點在軟件工程當中是不適用的。這也是我在閱讀完《人月神話》這本書時最大的感受。這本書的第二章就講述了人月神話的關系，完成工作的人數和時間是不能進行簡單的互換的。因為新加入的人對原有的項目不了解，需要花時間培訓，讀后感交流，同時新人也有可能對原有的設計有不同的意見，這些都會導致任務的進度大打折扣?！跋蜻M度落后的項目中增加人手，只會使進度更加落后”，是這本書作者布魯克斯得到的結論。我覺得開發(fā)一個軟件，要有合理的時間進度安排，項目開發(fā)的人員少而精，團隊開發(fā)之前要提前交流，開發(fā)的時候要持續(xù)的溝通，合理的分配任務工作。所有只有在一個團隊溝通了解，通力協作和努力下，才能更好的完善項目。

??在軟件領域，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理復雜項目提供了最具洞察力的見解，既有很多發(fā)人深省的觀點，又有大量軟件工程的實踐。讀完本書后，感觸頗深，書中通過介紹在軟件項目開發(fā)過程中遇到的一系列問題，以及解決的方法，向IT從業(yè)者講述軟件開發(fā)過程中需要注意的各種問題。

??我想更仔細地閱讀，但我們的項目經驗與作者大不相同（下面我會介紹一下作者）。書中的許多概念仍然給我留下了深刻的印象，將來，當我有更豐富的團隊作戰(zhàn)經驗或管理經驗時，我可能會有更多的收獲。
下面讓我們來了解一下作者：
作者簡介
??小弗雷德里克·P.布魯克斯（Frederick P.Brooks，Jr.1931-2022），圖靈獎得主、美國國家科學院院士，對計算機體系結構、操作系統(tǒng)和軟件工程做出里程碑式貢獻的計算機科學家。

??布魯克斯博士于20世紀60年代初主持與領導了被稱為人類從原子能時代進入信息時代的標志的IBM/360系列計算機的開發(fā)工作，取得輝煌成功，被認為是“IBM360系統(tǒng)之父”。布魯克斯博士創(chuàng)立了北卡羅來納大學的計算機科學系，并于1965-1985年擔任系主任。他還曾任職于美國國家科技局和國防科學技術委員會。

??布魯克斯博士作為硬件和軟件的雙重專家和出色的教育家始終活躍在計算機舞臺上，因其專業(yè)成就和對計算機體系結構的卓越貢獻而屢獲表彰，包括美國國家技術獎、ACM杰出服務獎、ACM Fellow、ACM Newell獎、IEEE McDowell獎、計算機先驅獎、馮·諾伊曼獎、富蘭克林學會鮑爾獎、圖靈獎等。
??了解作者之后我又對文章有了更深的感悟。
??接下來，讓我們談談我在閱讀后對軟件工程的新理解。

二、軟件工程領域的危機

??圍繞成本核算的估算技術，混淆了工作量和項目溝通技能的進展。月亮是一個危險和欺騙性的神話，因為它表明人員的數量和時間可以相互替換。
??日夜和程序員在一起bug在頑固的過程中，我們也形成了樂觀的心態(tài)。自然，我們在時間、成本和人力估計的藝術軟件項目中也帶來了樂觀的色彩。什么是這個樂觀的色彩數據庫也是我們思維的雙刃bug。但現實很骨感，真正的架構師工資軟件項目往往面臨延遲交付。
??我們常常覺得人多力量大，人人齊心協力，斷金。如果是一次性分配，可以自己開始，互不干涉，那么這句話無疑是正確的。只要花在可控成本上，人越多，任務就越快完成。
??但是軟件項目在數據庫系統(tǒng)若干人員軟件中分解任務時會引發(fā)額外的工作量——培訓和溝通。這都需要時間、金數據庫系統(tǒng)的核心是錢和人力的成本。向項目中增派新的人手從三個方面增加了項目必要的總體工作量：任務重新分配本身和所造成的任務中斷：培訓新人員、額外架構師證書的相溝通技巧和方法互溝通。
作者在書中提到了一個Brooks法則：
增加進度落后的項目人員只會使進度落后。

最后我想再說一下看完后得出的經驗和方法

三、實踐經驗和管理方法

1. 經驗

??同樣有兩年的經驗且受到軟件商店下載相同培訓的情況下,優(yōu)秀的專數據庫設計業(yè)程序員的效率是較差的程序員的10倍。
??這促使我們奠定堅實的基礎，成為團隊不拖軟件測試后腿溝通技能和方法程序員，很難想象軟件工程專業(yè)程序員的工資只有十倍的技能差異，所以雇傭一個優(yōu)秀的程序員為公司獲得九倍的效率，這無疑是建筑師和程序員之間的差異是巨大的回報。

2. 管理方法

??小而有能力的團隊是最好的，盡可能少的數據庫。但對于真正意義上的大系統(tǒng)來說，小而有能力的團隊太慢了。
??那么，對于大型系統(tǒng)來說，軟件商店下載有哪些更好的管理方法呢？這是書中一個經典的例子：外科團隊。
??對于大多數大型編程系統(tǒng)來說，開發(fā)方法成本高、速度慢、軟件庫效率低，開發(fā)的產品無法整合概念。
??所以有一個首席程序架構員，像外科團隊團隊架構達到了這樣的效果——由少數頭腦構建完整的產品概念，數據庫系統(tǒng)的核心是整體生產率，也完全減少了架構圖溝通的工作量。

3. 概念一致性

1）為什么要有概念一致性？
??為了獲得概念的完整性，設計必須由一個人或一個有共識的小團隊來完成。
無論項目規(guī)模如何，都有必要將數據庫管理系統(tǒng)的設計和實現分開，這是一種強有力的手段，可以獲得完整的概念架構是什么意思。正如我們在軟件系統(tǒng)結構課程中學到的重要概念解耦一樣，我們將抽象方法包裝在單獨溝通的重要性類別中，并在具體實現中調用抽象類別，使編程不局限于復雜的實現細節(jié)，易于維護和修改，這就是架構師的意義。
??某些規(guī)則有利于軟件項目的推廣。外部溝通的重要性體驗部的系統(tǒng)結構規(guī)定實際上增強了個人或小團隊的創(chuàng)造力，因為他們在編程時有一個統(tǒng)一的邊界，不需要花很多時間絞盡腦汁思考和交流軟件架構等抽象事務，從而專注于軟件的實現，從而提高開發(fā)效率，提高軟件質量。
2）如何設計概念？
??為了準確性，我們需要正式的設計定義，同樣，我的軟件工程需要記敘定義來加深理解。
??剛讀到這里，我不是很產品批號是生產日期理解正式定義，后來想到離散數學邏輯知識，軟件商店下載可能數據庫系統(tǒng)的核心是解決所謂的正式應該使用特定的語言規(guī)則產品設計表達定義，以軟件測試確保數據庫的邏輯意義，同時溝通，為了提高可讀性，溝通能力輔以敘述性文本，降低溝通成本。

4. 團隊組織

1）交流
??因為左手不是軟件技術專業(yè)知道右手在做什么，導致災難、不合理的功能和系統(tǒng)缺陷。由于對他人的各種假設，團隊成員之間的溝通能力開始出現偏差。
當我第一次加入老師的項目團隊時，我負責在前端頁面上設置溝通技巧計。然而，由于項目不是很緊急，我在學習新技術方面很懶惰，團隊之間的溝通沒有數據庫系統(tǒng)的核心。因此，在第一個項目節(jié)點中，由于缺乏團隊溝通，我積累的疑問沒有得到解決，幸運的是，當時項目分工明確，我的部分和其他學生暫時不需要對接，但在交流軟件庫藍奏云果時有點尷尬。
2）項目工作手冊
??項目工作手冊不是一個獨立的文檔，而是組織項目必須生成的一系列文檔的結構。
我們需要盡快和仔細地設計如何制作手冊的結構，每個產品經理也應該了解所有的材料。
之前有過幾次團隊合作經驗，從最初的校園培訓，項目文檔——每個人都有自己的一部分，到最后必要的時刻聚集在一起，數據庫技術后來使用雀平臺管理項目所有文檔，從需求分析到數據庫設計到接口設計，實時更新在線，使團隊減少一些不必要的溝通，提高溝通效率，也減少了文檔更新，沒有及時通知項目組成員。
3）組織架構
??團隊組織的目標是減少必要的溝通和合作。為了減少溝通，組織結構包括人力劃分和責任范圍限制。
??傳統(tǒng)的樹軟件工程專業(yè)組織反映了權力數據庫管理系統(tǒng)的原理結構，即不允許雙重領導。然而，組織中的溝通是網絡的，因此組織結構圖中的虛線部分是調整溝通路徑，以克服樹組織結構中缺乏溝通的困難。
??每個子項目都有兩個領導角色——產品負責人、技術總監(jiān)或架構師。他們是左手和右手，他們的功能非常不同。

5. 溝通能力. 控制軟件管家度

??控制大型項目的第一步是指定由里程碑和日期組成的進度表。
里程碑必須是具體的，軟件量可以明確定義，這樣軟件測試，程序員就不能欺騙數據庫系統(tǒng)工程師，欺騙里程碑的進展。
??所有成員的產品密鑰都必須有評估機制才能通過它了解真實狀態(tài)。
??評審使我們能夠及時關注個人進度、團隊溝通技巧和方法團隊進度數據庫設計的差異。如果有一個計劃和控制軟件系統(tǒng)小組來維護里程碑報告，這將對項目的及時交付有很大的幫助。

京東購買鏈接：

京東購買鏈接：人月神話

??如果這份博客對大家有幫助，希望各位給恒川一個免費的點贊??作為鼓勵，并評論收藏一下?，謝謝大家?。?！
??制作不易，如果大家有什么疑問或給恒川的意見，歡迎評論區(qū)留言。文章來源地址http://www.zghlxwxcb.cn/news/detail-694707.html

到了這里，關于【人月神話】重新探索人月神話：軟件工程的現實與挑戰(zhàn)的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！