【正文】 一樣。而且不要逐步加入，一定要一次性加入。以前，增加人手基本是挽救進度落后項目的主要辦法。微軟就是這種思路吧，把最聰明的人集中在一起，想不成功都難。二是“一個拿2倍工資的人，生產(chǎn)率可能是其他人的10倍。需要注意的一點是，即使是總設(shè)計師一直是同一個人，他腦海中所認為理所當然的規(guī)則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。本書對我觸動最大的，一是保持設(shè)計的概念完整。也就得出著名的Brooks法則── 「對于進度已落后的軟件開發(fā)計劃而言﹐若再增加人力﹐只會讓其更加落后。在1956~1965 之間﹐Brooks實際領(lǐng)導(dǎo)IBM 360 大型電腦的開發(fā)計劃﹐包括硬體結(jié)構(gòu)及龐大的OS/360作業(yè)系統(tǒng)在內(nèi)﹐因之他具有IBM 大型電腦之父的尊稱。不過，我決定去買本英文版回來，收藏，以后再多看幾次。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設(shè)計有不同意見（特別是加入的人中有比較強大的設(shè)計者）。：）如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么。記得當年看《C＋＋編程思想》，Bruce說“十個婦女不能在一個月內(nèi)生下小孩”（大意），于我心有戚戚焉。不過，我覺得，作為公司，應(yīng)該給最好的人最好的待遇，或者說給比目前更高的待遇。不知道其他公司的程序員們?nèi)绾慰?。感覺整體概念完整性的控制效果還不錯。概念的完整性，對于很多小規(guī)模軟件，由于開發(fā)人員不多，開發(fā)經(jīng)理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了。具體的實現(xiàn)人員可以細化概念，但只有總設(shè)計者才有否定與發(fā)展基本概念的權(quán)力。把感觸比較深的幾點記下來，順便整理一下自己的思路，與大家分享。第一篇：《人月神話》讀后感～623　字數(shù)：1345當我捧起《人月神話》，馬上就被深深的吸引了。1，保持設(shè)計的概念完整。需要注意的一點是，即使是總設(shè)計師一直是同一個人，他腦海中所認為理所當然的規(guī)則或者概念，很可能由于沒有明確的文檔化，而沒有成為所有開發(fā)者共同的概念。但要注意以后的Bug修改，功能擴展的時候，也要時刻留意與最初的設(shè)計是否概念上相容。我沒有更多人數(shù)項目的具體實踐經(jīng)驗，希望以后能有機會參與比較大的項目。我的同事中有一個牛人，做出的貢獻特別大，應(yīng)該相當于我們公司普通的十個程序員，不過工資最多也就是普通程序員的二倍。組建一個團隊，最好的就是那種精英團隊，大家都是牛人，效率會特別高。而本書作者Brooks得出的結(jié)論是對我是震撼性的：“向進度落后的項目中增加人手，只會使進度更加落后”。唯一的方法還是只有….加人。那么，就當作，新組建了一個團隊吧。第二篇：人月神話讀后感人月神話讀后感二十九年前(1975)﹐IBM大型電腦之父──Fred Brooks 出版一本書﹕“The Mythical ManMonth”。由于OS/360是多達1000位程式師共同合作的大型軟件開發(fā)工作﹐讓他深刻了解到大型軟件開發(fā)的技術(shù)和管理上所面臨的種種困難和挑戰(zhàn)?！?Adding manpower to a late software project makes it later)這是該書名稱的涵義。無論對小軟件還是大軟件，都必須由一個設(shè)計師主導(dǎo)，最多兩個人討論來共同完成軟件的整體設(shè)計。概念的完整性，對于很多小規(guī)模軟件，由于開發(fā)人員不多，開發(fā)經(jīng)理一般都能控制住所有的代碼，概念完整性在組織層面就維持住了?！辈恢榔渌镜某绦騿T們?nèi)绾慰?。三是進度落后與增加人力。這個辦法行不通的話，難道只有“加班”一條路了？如果不想加班，不想削減功能，不想推遲發(fā)布日期，那么。要小心的是，新加入的人可能對原來的組織造成沖擊，或者對原來的設(shè)計有不同意見（特別是加入的人中有比較強大的設(shè)計者）。在此我說說書中許多非常好的觀點。 the word印象比較深刻的是“體系結(jié)構(gòu)設(shè)計人員必須為自己描述的任何特性準備一種實現(xiàn)方法，但他不應(yīng)該支配具體的實現(xiàn)過程。 Pounds in a FivePound Sack主要講述程序占用的空間等，在70年代比較突出，但現(xiàn)在好多了。比如：文檔編寫工具、開發(fā)工具（包括各種不同開發(fā)平臺）、調(diào)試工具、測試工具、數(shù)據(jù)庫工具、版本管理、項目管理工具等。 a Catastrophe這章節(jié)說明使項目進度拖后的最大原因不是重要的事件，如新技術(shù)、重組等，而是一些瑣碎的小事，每件小事只耽誤半天或一天時間，但這種小事多以后，將使項目的進度嚴重拖后。想想，這種情況在現(xiàn)在仍然沒有改變。作者認為軟件項目具有人狼的特性，因為軟件項目也可能變成一個怪物，一個落后進度、超出預(yù)算、存在大量缺陷的怪物。這個變化的過程告訴你，進步是逐步取得的，伴隨著辛勤的勞動，對規(guī)范化過程應(yīng)進行持續(xù)不懈的努力，而這個努力的過程相應(yīng)的就誕生了軟件工程。成本的確隨開發(fā)產(chǎn)品的人數(shù)和時間的不同，有著很大的變化，進度卻不是如此。當任務(wù)由于次序上的限制不能分解時，人手的添加對進度沒有幫助。對于編程，有其樂趣和苦惱。同時，文檔形成了關(guān)鍵的樞紐，每個項目管理的工作都圍繞著它們運轉(zhuǎn)，它們是經(jīng)理們的主要個人工具。手冊、或者書面規(guī)格說明，是一個非常必要的工具，盡管光有文檔是不夠的。記敘性文字則可以顯示結(jié)構(gòu)性的原則，描述階段上或?qū)哟紊系慕Y(jié)構(gòu)，以及提供例子。規(guī)模預(yù)算必須與分配的功能相關(guān)聯(lián)； 在指明模塊大小的同時，確切定義模塊的功能。它可以持續(xù)一個很長的時間，從而可能影響項目的交付日期。產(chǎn)品測試時每個產(chǎn)品在提交給用戶的一道程序。不時地，細心的產(chǎn)品測試人員總會發(fā)現(xiàn)一些沒有貫徹執(zhí)行、設(shè)計決策沒有正確理解或準確實現(xiàn)的地方。維護成本受用戶數(shù)目的嚴重影響，用戶越多，所發(fā)現(xiàn)的錯誤也越多。興趣太多，令人興奮的學(xué)習(xí)、研究和思考的機會也太多——多么不可思議的矛盾??！這個神奇的時