IT項目管理——《人月神話》讀後感

這也許是和候紅老師的最後的幾節課了吧，侯老師是一個頗有思想深度，很關心同窗的好老師。

一開學就佈置了閱讀《人月神話》的做業，說實話，我沒有看，以個人速度可能二、3個小時就看完了，可是我以爲沒有什麼意義，在網上找了一個洗的很好的總結，大概看了看，並加入了一些本身的見解，由於目前才大三，沒有什麼項目開發經驗，因此只能從平時的編程中遇到的問題來看待《人與神話》這本書。

參考：

《人月神話》讀書筆記——陳浩要安靜（http://www.jianshu.com/p/da8a68354caa）

人月神話讀書筆記

　　開頭的話：第一次聽到《人月神話》是在陳曉江老師的新生導讀上，當時對這個專業充滿了好奇與期待，因而便立馬買了這本書來看，可是當時的我對編程都是一竅不通，更是不能理解這本書的內容了。而現在已步入大三，我再次讀了這本書，首先有了必定的編程經驗以及小的項目開發經驗，其次學習了《軟件工程》和《項目管理》，即是對這本書有了初步的理解。不過，我始終相信每次一的讀書都會帶來新的收穫，等我工做了之後再次讀這本書的時候確定會有新的感觸吧。

　　人是程序員，月是時間，若是1人幹10個月若是等同10人幹1個月，那就成神話。

　　第一章的標題即是很吸引人「焦油坑」。程序員，就像詩人同樣，幾乎僅僅工做在單純的思考中。程序員憑空運用本身的想象，來建造本身的「城堡」。不多有這樣的介質——創造的方式如此靈活，如此得益於精煉和重建，如此得容易實現概念上的設想。沒錯，程序員就像創做者同樣，每一次指尖的敲下，即是有一串字符誕生，而這串字符即是蘊含着創做者本身獨特的思惟，就如同做家、畫家等同樣，程序員所作的也是智力創造，不斷地推翻之前本身的所想就成爲常態。一開始設計上的不完善，再加上後來不斷地推翻修改，如果沒有在更高的高度上的對總體的把控，就會使得軟件架構愈來愈複雜，冗餘的內容愈來愈多，還不敢隨意刪除，這就成爲了一個焦油坑，越是掙扎，編越是深陷其中。「Adding mapower to a late software project makes it later.」向進度落後的項目中增長人手，只會使進度更加落後。這是書中提到的Brooks法則，人月神話一文的核心觀點。用人月這一觀念來衡量項目進度帶有欺騙性。由於他使得項目看上去好像人力和時間是可交換的。若是時間不夠，那麼增長人手就能夠加快進度。可是這個衡量方式忽略了新增長人手的培訓時間、隊員之間的溝通時間等等因素，結果就是，盲目的增長人手只會致使項目落後。因此問題是，如何使得項目進度不落後；要想使得項目進度不落後，就要制定出合理的項目進度。因此，問題是，如何制定出合理的項目進度。

外科手術隊伍是指有經驗的程序員決定了項目的絕大部份內容，而其餘人只完成一些細節的工做，可是這裏我認爲做者只是從如何高效的完成項目來考慮了，沒有從一個公司管理者的角度來考慮。

　　多此一舉，我以爲這裏的翻譯有一些奇怪，其實做者是想表達，系統設計師應該足夠當心並關注第二個系統，由於第一個系統在設計時是毫無經驗的，是一次大膽的嘗試，而第二次應該嘗試全集與第一次設計的差集，而這種嘗試必然是十分危險的。之後的設計中則可參考前兩次的設計經驗。

爲何巴比倫塔會失敗？書中列舉了一個項目想要成功的一些必要因素。清晰地目標、人力、材料、時間、技術，這些條件所有都達到了要求，可是爲何仍是會失敗呢？這就像聖經中的巴比倫塔故事同樣。當時人類聯合起來興建但願能通往天堂的高塔，爲了阻止人類的計劃，上帝讓人類說不一樣的語言，令人類相互之間不能溝通，計劃所以失敗，人類自此各散東西。因此他們還缺少什麼？那就是交流和組織。他們沒法相互交談，從而沒法合做。當合做沒法進行時，工做陷入了停頓。經過史書的字裏行間，咱們推測交流的缺少致使了爭辯、沮喪和羣體猜忌。很快，部落開始分裂——你們選擇了孤立，而不是互相爭吵。

　　成竹在胸。這章討論一個程序員的生產效率究竟有多高？書中說「對規模平均爲3200指令的程序...大約單個的程序員所須要的編碼和調試時間爲178個小時，由此能夠外推獲得每一年35800語句的生產率。而規模只有一半的程序花費時間大約僅爲前者的四分之一，相應推斷出的生產率幾乎是每一年80,000代碼行1。計劃、編制文檔、測試、系統集成和培訓的時間必須被考慮在內。所以，上述小型項目數據的外推是沒有意義的。就好像把100碼短跑記錄外推，得出人類能夠在3分鐘以內跑完1英里的結論同樣。」工做量和代碼行數不是線性關係，而是指數型關係：工做量 ＝ （常數）×（指令的數量）^1.5。

　　禍起蕭牆。項目是怎樣被延遲的？就像高中英語老師所說的，你天天比別人早來20min，早點來讀讀單詞、背背課文；每次課間多作兩三道單選；天天晚上作一道閱讀理解，那麼你半年比別人進步多少？雖然當時以爲頗有道理，但一直也沒這樣作......反向分析一下項目進度也是極其類似的，由於種種事情而推遲的計劃在最後累積到一塊兒，致使整個項目延期到不可思議的地步。雖然咱們都很不想讓進度落後，可是一天一天的進度落後是難以識別的、不容易防範和難以彌補的。某個關鍵人員生病了、公司停電、下暴雪、緊急任務、私人問題——這個列表能夠無限被擴展，每件事都會使項目延期半天、一天，雖然都是小的時間碎片，可是整個項目進度開始落後了，儘管每次都只有一點點。

　　另一面。這一章主要闡述了文檔在項目開發中起到的做用是多麼重要。可是什麼樣的文檔纔是好的文檔呢？文中給出了一些參考內容：1. 目的。主要的功能是什麼？開發程序的緣由是什麼？2. 環境。程序運行在什麼樣的機器、硬件配置和操做系統上？3.範圍。輸入的有效範圍是什麼？容許顯示的合法範圍是什麼？4.實現功能和使用的算法。精確地闡述它作了什麼。5.輸入——輸入格式。必須是確切和完整的。6.操做指令。包括控制檯及輸出內容中正常和異常結束的行爲。7.選項。用戶的功能選項有哪些？如何在選項之間進行挑選？8.運行時間。在指定的配置下，解決特定規模問題所須要的時間？9.精度和校驗。指望結果的精確程度？如何進行精度的檢測？

　　沒有銀彈。There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.Fred Brooks提出的註明論斷。在民俗傳說裏，全部能讓咱們充滿夢靨的怪物之中，沒有比狼人更可怕的了，由於它們會忽然地從通常人變身爲恐怖的怪獸，所以人們嘗試着查找可以奇蹟似地將狼人一槍斃命的銀彈。咱們熟悉的軟件專案也有相似的特質（以一個不懂技術的管理者角度來看），日常看似單純而率直，但極可能一轉眼就變成一隻時程延誤、預算超支、產品充滿瑕疵的怪獸，因此，咱們聽到了絕望的呼喚，渴望有一種銀彈，可以有效下降軟件開發的成本，就跟電腦硬件成本能快速降低同樣。第一次看到這個標題的時候，感受很奇怪查了一下才明白其中的寓意。好比面向對象編程，只能解決一些非本質的困難，對於軟件工程的根本問題無事於補，即複雜性、一致性、可變性、不可見性、遺留問題。所以，如今的技術中最有但願的，而且解決了軟件的根本而非次要問題的技術，是開發做爲迭代需求過程的一部分——快速原型化系統的方法和工具。快速原型之因此能夠解決根本問題，是由於快速原型有助於澄清軟件工程的概念結構，從而下降了後期變動的幅度。基於快速原型進行增量開發，目前已經成爲實際開發的標準流程。我以爲這是做者首次明確地作出確定。

　　軟件重用。做者提出「重用是一件提及來容易，作起來難的事情。它同時須要良好的設計和文檔。即便咱們看到了並不十分常見的優秀設計，但若是沒有好的文檔，咱們也不會看到能重用的構件」。這一點我算是體會深入，在Python中模塊（包）的概念可謂深刻人心從，一開始接觸的Django，Web.py，到requests，bs4，unittest，coverage，以及他們的管理工具pip等等還有不少。這些優秀的模塊拋開它們自己優秀的設計思路，以及強大的功能。你會發現這些優秀的模塊都有一個共同點——文檔寫得十分優秀。好的文檔能極大的提升開發效率，例如Django的官方文檔，體系十分龐大，並且對於每一個版本都有對應的文檔，每次更新的內容也會在首頁展現，只不過純英文看的我有點頭痛，由於不少術語即便翻譯了也感受怪怪的，大部分都是專業詞彙。再說一個依賴模塊而誕生的強大工具Atom，這個是github推出的一款編輯器，他的強大之處在於它的可擴展性，比較知名的有elemet，minimap等等，這些下載量驚人的擴展或是主題拋去自己十分好用不談即便沒有像Django的官網，去看他們的gihub的README，寫的十分清楚，什麼快捷鍵，快速入門，寫的明明白白，由於atom的開發者是良莠不齊，不想pypi那種有嚴格的審覈，致使一些明明十分好用的擴展和主題，由於爛的一比的文檔（這裏我不得不說一些很粗俗的話，我當時下載了一個主題的擴展包，可使用透明的自定義背景，十分好看，可是我怎麼都不知道在哪裏改，甚至去他的源碼裏替換了一些我也不知道是什麼的.jpg文件，弄了有兩天，都沒有弄好，後來在特別偏僻的論壇裏發現了一條，有一個快捷鍵‘ctrl+shift+e’這你不說誰能想到啊，真的很生氣）致使根本沒人用，甚至被罵。因此在軟件重用這裏，順便說一下文檔的重要性。

　　20年後的人月神話。做者說「今天，我比以往更加確信。概念完整性是產品質量的核心。擁有一位結構式是邁向概念完整性的最重要一步。這個原理不只限於軟件系統，它適用於全部的復瑣事物」 20年後的人月神話有些結論獲得驗證，有些狀況已經變化，下面是這些狀況的簡單歸納：1.第二系統定律獲得驗證：開發第二個系統老是由於盲目的功能致使易用性、甚至是可用性的災難。圖形界面的成功2.瀑布模型被證實是錯的了，由於沒有構建捨棄原型。事實上增量開發與快速迭代纔是理想的開發方式。3.增量開發和快速原型，漸進地精華，讓軟件像生物進化那樣逐漸演化成更爲複雜的結構，演化出更多的功能。4.信息隱藏：Parnas是正確的，我是錯誤的。20年前關於信息隱藏的兩大觀念，其一是Brooks主張的，全部的程序員應該瞭解全部的材料。而Parnas則認爲代碼模塊應該採用定義良好的接口來封裝，這些模塊內部結構應該是程序員的私有財產。Brooks認可，Parnas所主張的方案確實更符合實際。5.對人月神話實際研究發現，向進度落後的項目中添加人手會增長項目的成本，可是不必定會使項目更加落後。若是在項目早期添加額外的人比在後期添加額外的人更安全些。6.人就是一切。這一點能夠從《人件：高生產率的項目和團隊》能夠見出。7.放棄權利的力量——公司經過將權利下放到具體的團隊，事實上使得組織機構變得更加「融洽和繁榮」。8.最使人驚訝的新事物——數百萬的計算機。9.使用塑料包裝的成品軟件包做爲構建：成熟的模塊和對象組合提高了軟件複用的層次。

　　軟件工程的將來。做者說「軟件工程的焦油坑在未來很長一段時間內會繼續地令人們舉步維艱，沒法自拔。軟件系統多是人類創造中最錯綜複雜的事物，只能期待人們在力所能及的或者剛剛超越力所能及的範圍內進行探索和嘗試。這個複雜的行業須要：進行持續的發展；學習使用更大的要素來開發；新工具的最佳使用；經論證的管理方法的最佳應用；良好判斷的自由發揮；以及可以使咱們認識到本身不足和容易犯錯的——上帝所賜予的謙卑」。