【正文】 再進一步地說，既然Brooks設定了“大型工程或系統(tǒng)項目”這么的目標，并給出了一些答案。不過書中在引用Joel Aron(IBM在馬里蘭州蓋茲堡的系統(tǒng)技巧主管)的例子時說，“大型意味著過程員的數(shù)目超過25人，將近30,000行的號召”。事實上我們目前的軟件工程的進展是被駕駛了，而不是被預言了。第四篇：人月神話讀后感3110402157_ 王森_軟件112《人月神話》讀后感在閱讀這本書之前, 《人月神話》,正好老師的作業(yè)要求我們閱讀這本書,一點一滴的閱讀這本書,讓我印象深刻的是《人月神話》提出的兩條著名的法則：人月神話：向一個已經(jīng)延后的項目中投入更多的人力資源只會讓它更延后。,在焦油坑那一章里面,有一句話讓我難以忘懷:岸上的船,如同海上的燈塔, 過去幾十年的大型 系統(tǒng)開發(fā)就猶如這樣一個焦油坑，很多大型和強壯的動物在其中劇烈地掙扎。提出問題就是解決問題的答案。如何得到概念的完整性2。印象比較深刻的是＂體系結構設計人員必須為自己描述的任何特性準備一種實現(xiàn)方法，但他不應該支配具體的實現(xiàn)過程。主要講述項目中管理好各種工具的重要性，項目經(jīng)理首先要制定一種策略，讓各種工具成為公用的工具，這樣才能使開發(fā)、維護和使用這種工具的開發(fā)人員的效率更高，這種工具可能是開發(fā)人員開發(fā)出來的，也可能是使用現(xiàn)有的，可能是通用的，也可能是專用的或個人偏好的。這章節(jié)說明使項目進度拖后的最大原因不是重要的事件，如新技術、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項目的進度嚴重拖后。：流程圖是被吹捧得最過分的一種程序文檔。他行動的第一步是將大塊的“巨無霸理論”替換成“微生物理論”。余下的作者把軟件工程按“巨無霸理論”替換成“微生物理論”的過程詳細的說明，值得看，我關注的不是具體的內(nèi)容，具體內(nèi)容可能有些不合適宜，我關注的是作者的思考方式以及處理方法，這是非常重要的。作者通過軟件系統(tǒng)的內(nèi)在特性復雜性、一致性、可變性和不可見性來分析說明了軟件天生就沒有銀彈。于是作者提出了兩個觀點：amp。這句話對我的以后想從事系統(tǒng)分析工作有很大的幫助。在大型項目中，項目經(jīng)理需要有兩個和三個頂級程序員作為技術輕騎兵，當工作繁忙最密集的時候，他們能急馳飛奔，解決各種問題。4的回答基本上都可以找到，但第3個似乎找不到?！?，民主政治Aristocracy，Democracy，System要獲得概念的完整性，設計必須由一個人或具有共識的小組來完成。這就是生活真理。雖然現(xiàn)在有不少人對他的觀點持反對或不同意見，但我始終覺得他的觀點是對的——根本和次要問題的劃分以及定義。為什么“爽利”之初頗受爭議?為什么爽利對一些中小型的群體顯得管用和可厲行?為什么當這些爭議被擺在現(xiàn)在的獲勝平息爾后，傳統(tǒng)工程的理論家們卻不忘恨恨地評上一句：那是一種不能(或難以)利用于大型工程的措施呢?!因為萬一大家都很“爽利”，都只做比這些大型工程“小那么一點點”的工程，那么傳統(tǒng)工程的專家們就失業(yè)了。Brooks所述的工程是要獲得編程系統(tǒng)產(chǎn)品。然而在我看來，Brooks早曾經(jīng)在最佳位置上，給出了撬動它們的一個支點：Brooks感受發(fā)生“自力更生小型過程”與“編程系統(tǒng)產(chǎn)品”是不同的問題。我們追憶上一細節(jié)，在《人月神話》中的那“31%的答案”的前提——也即便那7%的性質中，如下兩項是顯明猜忌的(也是重要置疑)：目標的性質：是大型工程，是系統(tǒng)項目，而不是過程個體的性質：是私利性的其實早就有人意識到個體的性質“未必全是私利的”，尊重這些個體就會帶來一些收獲。大師們預言了未來也就改換了未來，即便未來未必“該當”好像他所預言的那樣。我在開篇中說《人月神話》“是一本可怕的書”。其維護基本上不同于硬件的維護，它主要由各種變更組成，如修復設計缺陷、新增功能、或者是使用環(huán)境或者配置變換引起的調整而且維護總成本通常是開發(fā)成本的40％或更多。進度表有時可以根據(jù)進展情況進行適度的修改。通常，開發(fā)一個軟件我們還會設立規(guī)模目標，控制規(guī)模，發(fā)明一些減少規(guī)模的方法——就如同硬件開發(fā)人員為減少元器件所做的一樣。良好的工作手冊和組織架構可以開發(fā)出更加符合用戶的需求。從而，添加更多的人手，實際上是延長了，而不是縮短了時間進度。Brooks 博士為人們管理復雜項目提供了最具洞察力的見解,既有很多發(fā)人深省的觀點,又有大量軟件工程的實踐,影響著一代又一代….通過閱讀《人月神話》，我從中學到了一些東西：首先，開發(fā)一個項目，我們錯誤的認為用人月這個工作量單位來估計和進行進度安排。作者認為軟件項目具有人狼的特性，因為軟件項目也可能變成一個怪物，一個落后進度、超出預算、存在大量缺陷的怪物。 a Catastrophe這章節(jié)說明使項目進度拖后的最大原因不是重要的事件，如新技術、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項目的進度嚴重拖后。 Pounds in a FivePound Sack主要講述程序占用的空間等，在70年代比較突出，但現(xiàn)在好多了。在此我說說書中許多非常好的觀點。這個辦法行不通的話，難道只有“加班”一條路了？如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么?！辈恢榔渌镜某绦騿T們?nèi)绾慰础o論對小軟件還是大軟件，都必須由一個設計師主導，最多兩個人討論來共同完成軟件的整體設計。由于OS/360是多達1000位程式師共同合作的大型軟件開發(fā)工作﹐讓他深刻了解到大型軟件開發(fā)的技術和管理上所面臨的種種困難和挑戰(zhàn)。在1956~1965 之間﹐Brooks實際領導IBM 360 大型電腦的開發(fā)計劃﹐包括硬體結構及龐大的OS/360作業(yè)系統(tǒng)在內(nèi)﹐因之他具有IBM 大型電腦之父的尊稱。本書對我觸動最大的，一是保持設計的概念完整。二是“一個拿2倍工資的人，生產(chǎn)率可能是其他人的10倍。以前，增加人手基本是挽救進度落后項目的主要辦法。不同的社會經(jīng)驗，不同的思想狀態(tài)，對讀本書的心得也不一