《人月神話》讀後感

標籤：

《人月神話》讀後感

  第一次聽到 《人月神話》這本書的名字時看上去帶有濃重的神話色彩，我也就認為這是一本神話故事，課開啟書後我才知道與我所想象的截然相反，而作者想要表達的意思是在軟體開發項目上項目進度和增加人員這兩個概念是不能互換的相關原理。

  在軟體領域，很少能有像《人月神話》一樣具有深遠影響力和暢銷不衰的著作。Brooks博士為人們管理複雜項目提供了最具洞察力的見解，既有很多發人深省的觀點，又有大量軟體工程的實踐。本書內容來自Brooks博士在IBM公司SYSTEM／360家族和OS／360中的專案管理經驗，該項目堪稱軟體開發專案管理的典範，使它確立了其在行業內的經典地位。初版的20年後，布魯克斯重新審視了他原先的觀點，增加了一些新的想法和建議。新增加的章節包括：原著中一些核心觀點的精華；在經過了一個時代以後，Brooks博士對原先觀點新的認識；1986年的經典文章《沒有銀彈》；對1986年所下論斷（在10年內不會出現銀彈）現在的認識。

  或許是因為書名的緣故，我對這本書產生了濃厚的興趣，我想通過度這本書想要知道作者問什麼給這本書去這樣的名字，我也試著用自己的方法來闡釋這本書的名字，我個人認為“人”應該代表軟體開發的人群，“月”代表著軟體開發所需要的時間，人月之所以不能成為神話，正是因為增加人手的同時也增加了人與人之間的交流，有些是不能明確說出功能列表的; 有些則是沒有能力知道開發中可能遇到的障礙點在哪裡的; 有些則不知道團隊人員的真正能力的; 更有些是集以上之大成的. 在有些時候, 我也是其中的一員說到這裡, 要說一下人月神話，我們所有的進度都是以人月代碼產量來衡量的，而增加"人"並不能縮短"月"的量。

  它之所以能稱之為經典是因為本書有其重要的貢獻，深深的影響了我們的思維和意識，主要貢獻在於對軟體開發過程的幾個重要關鍵點，提出了獨到的見解：

   包括以下幾點

（1）提倡外科手術式的團隊組織： 
　　 在軟體開發組織上的過份民主，往往帶來的是沒有效率和責任，參與其中的人想法太多，層面參差不齊。所以，軟體開發的組織，應該借鑒外科手術式的團隊方式，有一個主要的負責人，其他人都是分工協作的副手，這樣效率最好，結果最好。
　　（2）軟體項目的核心概念要由很少的人來完成，以保證概念的完整性： 
　　 少就是多，項目的定位需要和功能多少的權衡。太多的想法，使項目沒有焦點，什麼都要放進去，結果什麼都做不象；
　　（3）軟體開發過程中必要的溝通手段； 
　   軟體開發中最大的風險往往不是技術的缺陷，而是缺少溝通；
　　（4）如何保持適度的文檔： 
　     在開發中，保持適度的文檔。喜歡過度多的文檔的人，忘記了文檔不是最終的產品，不是使用者需要的，最後以為文檔好，就是好的開發，其實完全不是。
　　（5）在軟體開發的過程中，只有適度改進，沒有包治百病的銀彈。 
在軟體開發的過程中，重要的不是採用了什麼工具，而是不論用何種工具，都要達到項目本身的客戶需求。任何方法論之前，先要探求問題的來源，否則，對各種方法論的依賴或濫用，有害無益。

  　這本書中對我啟發最大的就是有關使用專業和進階的工具未必就能提高工作效率和品質，這一點對我有很大的驚醒作用。我往常還是很迷信這些一些好的工具和好的制度，以為有了這些，整個流程，所有工作都可以正規起來。現在想想，實在是沒有必要。如果要提高工作品質和效率，正確的方法是逐步解決工作中存在的問題。往往一些小的管理技巧要比複雜的軟體和制度來的有效，簡單的Word+Excel+PPT用的好了不比進階的管理軟體差。

 

 

《人月神話》讀後感