人月神話

用戶評論 (總計9條)

•   　　概念的完整性的確需要系統(tǒng)只反映唯一的設計理念，用戶所見的技術(shù)說明來自少數(shù)人的思想。
  　　
  　　外科手術(shù)隊伍，外科醫(yī)生和副手了解所有的設計和全部的代碼。上下級關(guān)系可以達到可觀的一致性。讓200人去解決問題，僅僅需要協(xié)調(diào)20個外科醫(yī)生。
  　　
  　　人月神話的騙局。開發(fā)中人力與時間的關(guān)系，他們并不是簡單的對等的，而是一個更加復雜的函數(shù)。
  　　如何避免第二個系統(tǒng)所引起的后果，從而避免畫蛇添足？運用特別的自我約束準則，來避免哪些功能上的過于修飾，根據(jù)系統(tǒng)基本理念及目的變更，舍棄一些功能。
  　　手冊的重要性：絕不要攜帶兩個時鐘出海，帶一個或三個。
  　　程序維護中的一個基本問題是缺陷修復總會以固定（20%-50%）的幾率引入新的bug。整個過程是前進兩步，后退一步。
  　　文檔的重要性，遇到問題記下來，有記錄，分歧才會明朗，矛盾才會突出。
  　　概念完整性。一個整潔、優(yōu)雅的編程產(chǎn)品必須向它的每個用戶提供一個條理分明的概念模型，這個模型描述了應用、實現(xiàn)應用的方法以及用來指明操作和各種參數(shù)的用戶界面使用策略，。用戶所感受到的產(chǎn)品概念完整性是易用性中最重要的因素。
  　　結(jié)構(gòu)師。結(jié)構(gòu)師負責產(chǎn)品所有方面的概念完整性，這些是用戶能實際感受到的。結(jié)構(gòu)師開發(fā)用于向用戶解釋使用的產(chǎn)品概念模型，概念模型包括所有功能的詳細說明以及調(diào)用和控制的方法。結(jié)構(gòu)師是這些模型的所有者，同時也是用戶的代理。在不可避免地對功能、性能、規(guī)模、成本和進度進行平衡時，卓有成效地體現(xiàn)用戶的利益。這個角色是全職工作，只有在最小的團隊中，才能和團隊經(jīng)理的角色合并。結(jié)構(gòu)師就像電影的導演，而經(jīng)理類似于制片人。
  　　將體系結(jié)構(gòu)和設計實現(xiàn)、物理實現(xiàn)相分離。為了使結(jié)構(gòu)師的關(guān)鍵任務更加可行，有必要將用戶所感知的產(chǎn)品定義棗體系結(jié)構(gòu)，與它的實現(xiàn)相分離。體系結(jié)構(gòu)和實現(xiàn)的劃分在各個設計任務中形成了清晰的邊界，邊界兩邊都有大量的工作。
  　　人月神話介紹軟件工程應該注意的問題，比如團隊組織，空間、銀彈——開發(fā)技術(shù)，時間日程表等等。初出茅廬的菜鳥讀起來壓力很大。
•   　　搬家，準備出售一些閑置書籍，
  　　包括人月神話，轉(zhuǎn)讓。有需要著請與我聯(lián)系。多為計算機方面書籍。
  　　
  　　下面鏈接是我在孔夫子網(wǎng)上書攤
  　　
  　　http://tan.kongfz.com/106218/204986748/
•   　　這是一本談項目管理小冊子，是一些經(jīng)驗的羅列，沒有什么系統(tǒng)性，但是比較有用。這本書強調(diào)幾個重要的理念：
  　　1.項目中，一般用人月來計算工作量，但是人和月是不能互換的。在項目延期的情況下，加更多的人往往會使項目更糟，因為新成員的加入需要很高的溝通成本。
  　　2.概念的一致性：項目中的概念在不同階段，不同成員之間要保持一致性很難，但很重要。
  　　3.交流很重要：巴比倫塔失敗的原因是因為人們不能有效的溝通。
  　　4.隨著程序規(guī)模的增加，工作量不是按比例增長，而是按指數(shù)增長，計劃、文檔、測試、集成等工作都要考慮在內(nèi)。就像人跑一千米所用的時間不等與百米沖刺的10倍一樣。 他給出一個公式：工作量 ＝ （常數(shù)）×（指令的數(shù)量）1.5 不知道他怎么得出這個公式的，我覺得現(xiàn)在以指令數(shù)量來衡量已經(jīng)不適用了吧。
  　　
  　　5.培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)、面向用戶的態(tài)度是軟件編程管理人員最重要的職能。
  　　6.系統(tǒng)剛發(fā)布時，發(fā)現(xiàn)bug的數(shù)量會逐漸減少，但過幾個月后，會增加。因為用戶的使用到了新的熟練水平，開始使用新的功能。
  　　。。。。
•   　　書中的一些技術(shù)細節(jié)讀起來比較費力，我更多地是從“項目管理”的角度來閱讀此書。
  　　
  　　【1】缺乏合理的時間進度是造成項目滯后的最主要原因。
  　　
  　　【2】通常，我們會過于樂觀，錯誤地假設“一切都將運作良好，每項任務僅花費它所應該花費的時間”。
  　　
  　　【3】在估計和進度安排中常常使用“人月”作為工作單位。但我們往往錯誤地假設人員數(shù)量和時間是可以相互替換的。當項目進度滯后時，我們往往會投入更多的人力。然而，此時我們需要考慮額外增加的培訓成本、溝通成本等。
  　　
  　　【4】Brooks 法則：向進度落后的項目增加人手，只會使進度更加落后。
  　　我認為應該辯證地看待這個法則，我發(fā)現(xiàn)在實際工作中發(fā)現(xiàn)進度落后的時候，一般采取以下三種措施（1）加班（2）減少項目范圍（3）增加人手
  　　
  　　【5】系統(tǒng)測試進度的安排。由于我們的樂觀主義，通常實際出現(xiàn)的缺陷數(shù)量比預料的要多得多。作者會把項目一半的時間預留在測試上。
  　　在今后參與測試相關(guān)的項目時，留意一下如何安排測試進度的。
  　　
  　　【6】為了獲得概念完整性，設計必須由一個人或者具有共識的小型團隊完成。概念上統(tǒng)一的系統(tǒng)能更快地開發(fā)和測試。盡早交流和持續(xù)溝通能使結(jié)構(gòu)師有較好的成本意識。
  　　
  　　【7】外科手術(shù)隊伍。對于大型系統(tǒng)，小型精干的隊伍太慢了。建議采用外科手術(shù)隊伍的團隊架構(gòu)（有一個主要的負責人，其他人都是分工協(xié)作的副手），既能獲得由少數(shù)頭腦產(chǎn)生的產(chǎn)品完整性，有能得到多位協(xié)助人員的總體生產(chǎn)率，還徹底地減少了溝通的工作量。
  　　
  　　【8】團隊中的交流（項目工作手冊）和組織架構(gòu)影響項目的成??；同時也強調(diào)了文檔的重要性。
•   　　“軟件的復雜度是根本屬性，不是次要因素。因此，抽掉復雜度的軟件實體描述常常也去掉了一些本質(zhì)屬性。數(shù)學和物理學在過去三個世紀取得了巨大的進步，數(shù)學家和物理學家們?yōu)閺碗s的現(xiàn)象建立了簡化的模型，從模型中抽取出各種特性，并通過試驗來驗證這些特性。這些方法之所以可行，是因為模型中忽略的復雜度不是被研究現(xiàn)象的根本屬性。當復雜度是本質(zhì)特性時，這些方法就行不通了。”
  　　
  　　“愛因斯坦曾不斷地重申自然界一定存在著簡化的解釋，因為上帝不是專橫武斷和反復無常的。軟件工程師卻無法從類似的信念中獲得安慰，他必須掌握的很多復雜度是隨心所欲、毫無規(guī)則可言的，來自若干必須遵循的人為慣例和系統(tǒng)。它們隨接口的不同而改變，隨時間的推移而變化，并且，這些變化不是必需的，僅僅由于他們是不同的人——而非上帝——設計的結(jié)果。”
  　　
  　　“當我們試圖用圖形來描述軟件結(jié)構(gòu)時，發(fā)現(xiàn)它不僅僅包含一個，而是很多相互關(guān)聯(lián)、重疊在一起的圖形。這些圖形可能代表控制流程、數(shù)據(jù)流、依賴關(guān)系、時間序列和名字空間的相互關(guān)系等等。它們通常不是有較少層次的扁平結(jié)構(gòu)。實際上，在上述結(jié)構(gòu)上建立概念控制的一種方法是強制將關(guān)聯(lián)分割，直到可以層次化一個或多個圖形?！?br /> 　　
  　　原書中，這兩段話分別針對軟件四項內(nèi)在特性中的兩項：“復雜度”和“一致性”而論，這三段話讓我有豁然開朗的感覺，所以相當喜歡！
  　　
  　　第一段加深了我對數(shù)學和物理的理解——我們的學習思路的確是這樣的；
  　　
  　　第二段反映了一個心結(jié)：我們都想將精力放在解決問題本身，而不是因為人為設計不一致造成的無謂卻必要的勞動上；
  　　
  　　第三段則介紹用圖形描述軟件結(jié)構(gòu)的一種抽象方法——強制將關(guān)聯(lián)分割。
  　　
  　　“沒有銀彈”全篇（包括16、17章）則深化了我對軟件的認識，這源自本篇的中心論點：軟件存在根本的和次要的兩種困難，為了提高軟件開發(fā)的效率，人們同時在為解決這兩種困難而努力著。如今，解決次要的困難已經(jīng)取得了巨大進步，但根本的困難仍然困擾著人們——這也是作者“沒有銀彈”論斷的來源。（將軟件開發(fā)比作人狼——簡單明了的東西可能變成落后進度、超出預算、存在大量缺陷的怪物，殺死人狼的武器是銀彈，但是解決軟件開發(fā)困難的銀彈可能并不存在，因為人們面對的是軟件的根本困難。）
  　　
  　　由于作者所有的討論都是針對軟件的根本困難和次要困難，所以，理解這兩種困難對于深化軟件的認識至關(guān)重要，這也是我認為全書最精華的地方——作者講得深入淺出，又發(fā)人深省。
  　　
  　　··················································
  　　
  　　作者認為，所有的軟件活動包括兩種任務：
  　　
  　　1.根本任務：打造構(gòu)成抽象軟件實體的復雜概念結(jié)構(gòu)。
  　　
  　　2.次要任務：使用編程語言表達這些抽象實體，在空間和時間限制內(nèi)將它們映射成機器語言。
  　　
  　　相應的，軟件就存在兩種困難：
  　　
  　　1.根本的困難：軟件特性中固有的困難。
  　　
  　　2.次要的困難：出現(xiàn)在目前生產(chǎn)中，但并非那些與生俱來的困難。
  　　
  　　作者的觀點是：
  　　
  　　“我認為軟件開發(fā)中困難的部分是規(guī)格說明、設計和測試這些概念上的結(jié)構(gòu)，而不是對概念進行表達和對現(xiàn)實逼真程度進行驗證?！?br /> 　　
  　　所以，軟件無法規(guī)避的內(nèi)在特性是（雖然書中沒有明說，但我能感覺到，這些就是作者所說的根本困難）：
  　　
  　　1.復雜度：沒有任何兩個軟件部分是相同的（至少在語句的級別上）……數(shù)字計算機本身就比人類建造的大多數(shù)東西復雜……軟件系統(tǒng)的狀態(tài)又比計算機的狀態(tài)多若干個數(shù)量級……軟件的復雜度是根本屬性，不是次要因素……
  　　
  　　2.一致性：許多情況下，因為是開發(fā)最新的軟件，它必須遵循各種接口。另一些情況下，軟件的開發(fā)目標就是兼容性……很多復雜性來自保持與其他接口的一致方面，對軟件的任何再設計，都無法簡化這些復雜特性……
  　　
  　　3.可變性：軟件實體經(jīng)常會遭受到持續(xù)的變更壓力……系統(tǒng)中的軟件包含了很多功能，而功能是最容易感受變更壓力的部分……軟件可以很容易地進行修改——它是純粹思維活動的產(chǎn)物，可以無限擴展……所有成功的軟件都會發(fā)生變更……功能擴展的壓力主要來自那些喜歡基本功能，又對軟件提出了很多新用法的用戶們……軟件一定是在某種計算機硬件平臺上開發(fā)，成功軟件的生命期通常比當初開發(fā)軟件所用的計算機硬件平臺要長……簡言之，軟件產(chǎn)品扎根于文化的母體中，如各種應用、用戶、自然及社會規(guī)律、計算機硬件等等。后者持續(xù)不斷地變化著，這些變化無情地強迫軟件也隨之變化……
  　　
  　　4.不可見性：軟件是不可見的和無法可視化的……軟件的客觀存在不具有空間的形體特征……除去軟件結(jié)構(gòu)上的限制和簡化方面的進展，軟件仍然保持著無法可視化的固有特性，從而剝奪了一些具有強大功能的概念工具的構(gòu)造創(chuàng)意。這種缺憾不僅限制了個人的設計過程，也嚴重阻礙了思路相互之間的交流。
  　　
  　　*注：這里，未必說作者所說的都是對的，我們當然需要批判性思維，但是當這方面的知識遠遜于作者時，將其作為知識吸收，從而促進自己的思考，顯然是個不錯的選擇。
  　　
  　　文章中剩余的部分則討論了解決次要困難的突破（高級語言、分時、統(tǒng)一編程環(huán)境），以及解決根本困難的可能途徑（Ada和其他高級編程語言、面向?qū)ο缶幊?、人工智能、專家系統(tǒng)、“自動”編程、圖形化編程、程序驗證、環(huán)境和工具、工作站）——當然這些都被作者否定了。
  　　
  　　最后，作者提出了自己所認為的一些可能解決根本困難的方法（參考如今的軟件開發(fā)，作者30多年前的觀點多么具有前瞻性?。。?br /> 　　
  　　1.購買和自行開發(fā)。
  　　
  　　2.需求精煉和快速原型。
  　　
  　　3.增量開發(fā)——增長，而非搭建系統(tǒng)。
  　　
  　　4.卓越的設計人員。
  　　
  　　以上節(jié)選自：http://wuguoren.com/2012/12/29/%E3%80%90%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E3%80%91%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9-%E6%9C%89%E5%85%B3%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E7%9A%84%E8%AE%BA%E6%96%AD/
•   　　張小龍說“不聽搖滾的程序員不是好產(chǎn)品經(jīng)理”，作為一個聽搖滾但不是程序員的產(chǎn)品經(jīng)理，理應尋找中間的那個名詞。
  　　1、向進度落后的項目中增加人手，只會使項目更加落后；
  　　2、項目的時間依賴于順序上的限制，人員的最大數(shù)量依賴于獨立子任務的數(shù)量；
  　　3、研究表明，效率高和效率低的實施者之間個體差異非常大，經(jīng)常能夠達到數(shù)量級的水平；
  　　4、需要協(xié)作溝通的人員數(shù)量影響著開發(fā)成本；
  　　5、對于效率和高年的完整性來說，最好由少數(shù)干練的人員來設計和開發(fā)，面對于大型系統(tǒng)，則需要大量的人手，以使產(chǎn)品在時間上滿足需求；
  　　6、以易用性為目標，功能與理解上復雜程度的比值才是系統(tǒng)設計的最終測試標準；簡潔和直白來自概念的完整性；易用性實際上需要設計的一致性和概念的完整性；
  　　7、手冊不但要描述包括所有界面在內(nèi)的用戶可見的一切，它同時還要避免描述用戶看不見的事物；
  　　8、手冊需精確的規(guī)定限制，描述將達到的目標，列舉差異，需在仔細定義規(guī)定什么的同時，定義來規(guī)定什么；
  　　9、產(chǎn)品責任人和技術(shù)主管必須在基本的技術(shù)理論上具有相似的觀點，他們必須在主要的技術(shù)問題出現(xiàn)之前，私下討論這些問題，產(chǎn)品責任人必須對技術(shù)主管的技術(shù)才能表現(xiàn)出尊重；
  　　10、交流和交流的結(jié)果——組織，是成功的關(guān)鍵。交流和組織的技能需要管理和仔細考慮，相關(guān)經(jīng)驗的積累和能力的提高同軟件本身一樣重要；
  　　11、實踐是最好的老師，但智者還能從其他的地方有收獲；
  　　12、為了滿足目標，每個人都在局部優(yōu)化自己的程序，很少有人會停下來考慮一下對客戶的整體影響；
  　　13、培養(yǎng)開發(fā)人員從系統(tǒng)整體出發(fā)，面向客戶的態(tài)度是軟件編程管理人員最重要的職能；
  　　14、技藝改進的結(jié)果往往是戰(zhàn)略上的突破，而不僅僅是技巧上的提高；
  　　15、數(shù)據(jù)的表現(xiàn)形式是編程的根本；
  　　16、軟件開發(fā)人員為客戶所承擔的最重要的職能不斷重復的抽取和細化產(chǎn)品的需求；
  　　17、不了解，就無法真正擁有；
  　　18、原型通常展示了應用程序的功能主線，但不能處理任何如無效輸入，退出清除等異常情況；
  　　19、原型的目的是明確實際的概念結(jié)構(gòu)，使客戶可以測試一致性和可用性；
  　　20、增量開發(fā)——增長，而非搭建系統(tǒng)；
  　　21、低劣設計和良好設計之間的區(qū)別可能在于設計方法的完善性，而良好設計和卓越設計之間的區(qū)別肯定不是如此，卓越設計來自卓越設計人員；
  　　22、我們理解也好，不理解也好，描述都應該簡短精煉；
  　　23、項目經(jīng)理面臨的中心問題就是如何設計架構(gòu)和流程，來提高而不是壓制主動性和創(chuàng)造力；
  　　24、管理人員的職責不是要人去工作，而是創(chuàng)造工作的可能；
  　　25、附屬職能行駛原理：如果較低級別組織的自由和責任得以保留，中心權(quán)威實際上得到了加強。
•   　　很難想象是50年前寫成的
  　　更難想象50年前 人們曾經(jīng)走過的彎路 我們?nèi)缃襁€在走
  　　
  　　除了經(jīng)典的人月理論，列舉一些個人認為至今依然收益的論斷
  　　
  　　- Documentation is the chief production of the architecture
  　　- Second system effect
  　　- The first version is done to be thrown away
  　　- Build up a surgeon team
•   　　1，老外在32年前就對軟件項目管理有了很深入透徹的了解，令人驚嘆。
  　　2，前人總結(jié)出來的經(jīng)驗教訓，而我們由于各種原因一直在重犯。
  　　3，某些語言或者技術(shù)會過時，但是這部書的內(nèi)容永遠不會過時。
  　　
  　　-
•   　　這本書是“國外程序員推薦：每個程序員都應讀的書”中一本非技術(shù)書，書中沒有任何技術(shù)知識。我花了大概一周的時間粗略讀了一遍，感觸呢，如書中所說“大多數(shù)觀點本來已經(jīng)知道”。
  　　
  　　軟件工程師應該至少過一遍書中提出的觀點，在實際工作中加以運用，比如：多交流，不知道的一定要問；多做實驗來驗證不確定的東西；選順手的工具；用合理的方式管理文檔。
  　　
  　　其實我更建議經(jīng)理級別的人/部門老大來讀這本書，從而能用更合理的方式來管理項目和工程師。為什么產(chǎn)品總是延期？為什么增加人手不能趕上進度？為什么工程師士氣低落？為什么...... 本書不僅解答了這些為什么，而且提出了實施的建議。我先后經(jīng)歷過幾家公司，發(fā)現(xiàn)管理上的混亂是如何拖慢進度，如何消磨大家工作的積極性的，希望這本書能引起老大們的注意。
  　　
  　　誠然，國內(nèi)環(huán)境復雜，軟件工程師就是被壓迫的一個階層，想必書中觀點也很難在現(xiàn)實中應用。

相關(guān)圖書

• 合同法學
• 新編五筆字型培訓教程
• 經(jīng)濟犯罪罪名釋解與法律適用
• 網(wǎng)絡股價值評估
• 成才心理學
• 追尋外星人的足跡
• 俄羅斯上空的外星人
• 我是大廚師-新杭州名菜
• 肖斯塔科維奇
• 審計學概論
• 水污染物化控制原理與技術(shù)
• 《英語寫作基礎(chǔ)》模擬試題集
• 英語口語模擬試題集
• 陸儼少教授課徒稿.樹法
• 傳染科主治醫(yī)生230問
• 醫(yī)學信息檢索
• 嵌入式系統(tǒng)
• 新編Visual Basic程序設計教程
• 最新高考話題作文
• 時尚川菜
• 人體結(jié)構(gòu)與功能
• 醫(yī)學統(tǒng)計學
• 正常人體學基礎(chǔ)
• 實用頭針穴線掛圖（中英對照）
• 實驗口腔病理學