何爲人月神話？
人是程序員，月是時間
1個人幹10個月如果等同10個人幹1個月
這就叫神話
寫在開頭
最初聽到這個書名，是在大一剛開始學Java基礎的時候聽到老師推薦的。當時還聽到了《Thinking in Java》，《Effective Java》，較這些高端霸氣上檔次的書名相比之下，《人月神話》更像是在講故事的書，而且還是帶有奇幻色彩。最近一段時間拜讀了這本神作，的確是在講故事，是講一個失敗的經驗故事，沒有奇幻色彩，通過失敗經驗反思軟件項目推進過程中的各類可能出現的情況。
有人曾這樣評論：這本書不是教你該怎麼做，而是教你不應該怎麼做。它基本上是對一個僞常識的否定，而不是教你用什麼方法把事情做得更好。
從對編程、軟件開發一臉懵逼的小白，到畢業後進入開發崗位。
站在一個從業者角度來看：40年前的一本書，現在仍暢銷，不是沒有原因的。從雖然不懂你在講什麼但是好像很有道理，到切實參與到軟件開發流程中，作爲執行實現者，體會明顯不同，這裏對感觸較深的章節分享一下自己的理解。
人月神話
-
缺乏合理的時間進度是造成項目滯後的最主要原因，它比其他所有因素的總和影響還大。
何爲合理的時間進度？合理一詞如何定義，在目前快速迭代開發的市場大環境中，時間就是首要考慮因素，拋開系統複雜度、實現技術難點等項目核心問題。從時間的角度去給項目下定義我覺得就是不合理的，我想一個優秀的產品是需要時間錘鍊的，慢工出細活。從用戶交互、使用體驗到後續維護運營、拓展升級，一個優秀的產品必經之路。若一次性開發一次性使用那我想時間的確是第一要義，我想這類情況也不在書作者的考量範圍之內吧。
軟件產品的迭代，更像是一個孩子從咿呀學語到長大成人的過程，合理的時間進度就是18年。這樣來講，揠苗助長是否合理我想我們心中都有答案了。
-
良好的烹飪需要時間，某些任務無法在不損害結果的情況下加快速度。
談到烹飪，高級菜品所需要的食材極爲講究，包括調料用量，火候把控，成菜擺盤。這樣的菜品就是大廚們精心雕琢的藝術品。那藝術品的創造和不需要充裕的時間呢？這裏我覺得和第一點很類似，都是強調了時間對產品質量的影響。
談到烹飪了，來一張國宴名菜開水白菜的皁片：這還是我認識的白菜嗎？
-
所有的編程人員都是樂觀主義者：“一切都將運作良好”。
這點上我覺得我有發言權，作爲開發人員，必須自信，我寫的代碼就是沒有bug，不信你點，你再點，咦，你咋這樣點呢？不是應該那樣點嗎？
在線翻車，2333，一切都將運作良好是站在正常操作的角度上，問題是無法控制用戶的操作啊，難道可以心靈控制，讓用戶按照你的思路操作？軟件開發本身就是服務行業，我們的金主客戶纔是上帝，你忒讓上帝看到這個產品一切運作良好。
樂觀可取，必須樂觀，生活都這麼難了，再不樂觀可咋整。
在開發過程中，開發人員要站在用戶的角度上考慮問題，考慮可能出現的各類突發狀況以及應對方案。
-
由於編程人員通過純碎的思維活動來開發，我們期待在實現過程中不會碰到困難。
面向用戶開發，產品依託於業務需求。關於業務需求，我覺得對業務的深入瞭解是增量式的，絕不可能一口喫下個大胖子的。在日常開發編碼中可能遇到這樣那樣的業務問題，逐步進行增量式的業務填坑。考慮到整體業務的閉環，基於業務閉環需要考慮某處的業務設計是否合理，考慮角度仍然不能僅從開發者，更多的應該是使用者。
-
但是，我們本身的構思是有缺陷的，因此總會有bug。
perfect plan，是反覆修改出來的，而不是從一開始就存在。既然軟件開發是服務行業，無法總是滿足用戶日益增長或變化的需求，正因爲這樣才需要迭代升級，逐步完善，朝着設計出一個perfect software目標而前進。
這裏講到的缺陷涵蓋的不限於設計缺陷、編碼缺陷等，但是最終的缺陷體現方式都是產品出現的Bug。開發太難了~~
-
圍繞着成本覈算的估計技術，混淆了工作量和項目進展。
人月是危險和帶有欺騙性的神話，因爲它暗示人員數量和時間是可以相互替換的。這句加粗變色的文字我覺得是章節的核心思想。
一個女人懷胎十月才能生下一個寶寶，難道十個女人懷胎一個月就能生下一個寶寶？
一盤西紅柿炒蛋一個廚師需要做十分鐘，難道十個廚師一分鐘搞定？
軟件開發是增量式的，是需要前置工作驅動後續發展的，不是基於人員的獨立工作。是幾個人共同創造一個軟件產品，而不是每個人各自做自己的，最後簡單的組裝。
帶有些許諷刺意味的人月神話類似理論，的確實實在在的存在。在成本與盈利需求面前，永遠存在這這樣的不可調和好的矛盾。如何調和這兩者之間的矛盾，若問我我也答不上來，我想着不單單是經驗不足，更多的是我所瞭解的軟件開發是存在於
烏托邦裏的吧。就像上學時書本是我們認知和理解的權威渠道。如今，社會現實這個萬花筒，並非我們想象中的那樣。還是太年輕~~~
-
在若干人員中分解任務會引發額外的溝通工作量 —— 培訓和相互溝通。
這點也是一個項目推進過程中的痛點問題，我以實際經驗來講溝通成本太大，甚至大到誇張都不足爲過。
就像幾個人一起在跑馬拉松，突然有個人參與進來，但是不明確路線，而且進度緩慢，你在半路，而他在起點。這時候就需要有人放慢速度甚至回退與在起點的成員對接，然後繼續帶領新加入的成員向前追趕。可是，時間一直在流逝啊~，時間可不會等人的。
又談到了時間，真的是句句呼應全文中心思想。
-
關於進度安排，我的經驗是爲1/3計劃、1/6編碼、1/4構件測試以及1/4系統測試。
這裏我想對三分之一的計劃安排談談自己的看法：
需求階段計劃的一部分必定包括需求分析階段，需求分析在整個軟件開發流程中是具有重要地位的，作爲前置工作的基礎。完善的需求分析，合理的需求落地要求是必要的。正所謂，良好的開端是成功的一半。
從用戶角度出發，通過需求採集、需求分析、需求篩選，到需求落地進行開發。這一個需求從無到有，從籠統到明確過程是必要且必須的。我很佩服那些能夠把想法落實成文字，轉換成實際需求進行產品設計的人。這些人才是軟件產品的拓荒者和佈道者。
-
作爲一門學科，我們缺乏數據估計。
數據估計，關係到對項目整體進度的把控和管理，這裏經驗的重要性就很明顯了。經歷過就是和沒經歷過不一樣，或許人家踩過的坑比你喫過的鹽都多。經驗這個能力評定無法量化，但是能力的體現是通過產品來反映的。
優秀的PM會有一股無形的力量，把控着全局。
-
我們對自己的估計技術不確定，因此在管理和客戶的壓力下，我們常常缺乏堅持的勇氣。
勇氣，可不是來首《勇氣》就能有的，烏托邦式的軟件開發存在於紙面而非現實。那麼，在面對現實時，《勇氣》能給你勇氣嗎？
-
Brooks法則：爲進度落後的項目增加人手，只會使進度更加落後。
-
任務重新分配本身和所造成的工作中斷；
-
培訓新人員；
-
額外的相互溝通。
-
從三個方面增加項目必要的總體工作量：
-
總結
其實說了這麼多，還只是書中的冰山一角，紙面上的內容雖然讓人很有感觸，但是落實成行動還是一個艱難的過程。
爲何艱難呢？試錯成本太高。回顧歷史，變革往往代表着推翻重新構建，誰又能保證別人的經驗也適用於自己呢？作者通過實際例子告訴我們不要這樣做，但是又有多少人相信了呢？就算相信了又有多少人真正理會並踐行了呢？
以上內容純屬個人想法，不喜勿噴，如有雷同，是你抄我~~。
以書中結束語作爲本次分享的結束語吧：
軟件工程的焦油坑在將來很長一段時間內會繼續使人們舉步維艱，無法自拔。軟件系統可能是人類創造中最錯綜複雜的事物，只能期待人們在力所能及的或者在剛剛超越力所能及的範圍內進行探索和嘗試。這個複雜的行業需要：進行持續的發展；學習使用更大的要素來開發；新工具的最佳使用；經論證的工程管理方法的最佳應用；良好的自我判斷以及能夠使我們認識到自己的不足——上帝所賜予的謙卑。