今天這篇閱讀筆記主要討論《人月神話》中的「人月神話」以及組建「外科手術隊伍」。
首先介紹一下什麼是人月神話。我以前聽人月神話的時候總是覺得很玄幻，以為這是乙個神話故事之類的。我相信很多剛剛聽到這個詞彙的人都會這麼認為，但是經過閱讀發現，人月神話並不是神話故事。這是一種軟體開發過程中的度量單位。估計完成乙個專案大概需要多長時間，比如需要12人月，則可以理解為需要3個人工作4個月。
那麼怎麼又稱為神話呢？因為使用人月這種度量方式，在很多情況下衡量乙個一項工作的規模是乙個危險和帶有欺騙性的神話。因為在以上關於人月的介紹中，根據這種計算方式，似乎人和月是可以等價互換，互相補充彌補的，但實際情況並不是如此。並不能用增加人的數量來減少開發的週期，這是一種愚蠢的想法和做法。
人們在對專案進行估計的時候往往是非常樂觀的，這是我們應該保持的一種良好的心態，但是我們更要從實際問題出發，遵循客觀規律，不能盲目的樂觀。當人月可以互為轉化時，這說明這個專案的每個模組的關聯性很小，團隊成員之間的交流也不會很多，而且交流起來會非常簡單，只有基於這種情況下，人月的內涵才能夠充分的得到體現，這種度量方式才能很好的闡述人月可以等價互換的理念。但是事實往往並非如此。每乙個專案，專案的各個模組的聯絡都是非常緊密的，而且很多模組之間是由時間先後順序的，這些因素決定了人月模型並不適合。當人的數量大大增加時，並不能有效的縮短專案的完成時間，相反，還可能會增加專案的時間。
試想一下，當團隊人數比較少時，每個人負責的工作量可能會比較大，但是每個人之間的交流會變得相對來說更加簡單，而且交流的時間會比較少，而當人數比較多時，因為各個模組並不是孤立的，要考慮到其他的模組的實現方式，所以交流會變得困難起來，這樣無疑就增加了時間開銷，而且這種事件開銷在乙個專案中會占用大量的時間。
那麼關於人月之間存在的這種矛盾，我們該如何解決呢？
一是，開發並推行生產率圖表、缺陷率、估算規則等等，而整個組織最終會從這些資料的共享上獲益。
二是，在基於可靠基礎的估算出現之前，專案經理需要挺直腰桿，堅持他們的估計，確信自己的經驗和直覺總比從期望派生出的結果要強得多。
總之，專案的時間依賴於順序上的限制，人員的數量依賴於單個子任務的數量。 從這兩個數值可以推算出進度時間表， 該錶安排的人員較少， 花費的時間較長（ 唯一的風險是產品可能會過時）。相反，分派較多的人手， 計畫較短的時間，將無法得到可行的進度表。
下面介紹另一種解決方案，組建「外科手術隊伍」。這是一種團隊模式，通過這個模式，理論上來說能夠大大提高團隊開發效率，並在一定程度上有效縮減開發時間。
軟體開發過程中存在以下這幾種情況：
優秀程式設計師和較差的程式設計師之間生產率的差異。
一擁而上的開發方法是高成本的、 速度緩慢的、 不充分的， 開發出的是無法在概念上進行整合的產品。
對於效率和概念的完整性來說，最好由少數幹練的人員來設計和開發， 而對於大型系統， 則需要大量的人手。
對於上述情況和存在的矛盾，我們可以通過組建「外科手術隊伍」來進行解決。這個隊伍的核心是外科醫生，他需要親自定義功能和效能技術說明書，設計程式，編制源**，測試以及書寫技術文件。其他的人要對他進行支援和服務。其他人員還包括：副手（工作和外科醫生相同，但不進行實現），管理員（對財務、人員等進行管理）、編輯（整理文件）、秘書（兩個，負責專案的協作一致）、程式職員（負責技術記錄，類似於構建大師的工作）、工具維護人員（提供特殊工具，保證所需服務可靠執行）、測試人員（設計提供測試案例）、語言專家（解決語言使用上的問題）。
通過這個隊伍，是系統在客觀上達到了概念一致性，同時也確保了工作概念上的一致性。同時由於是外科醫生和副手兩個人建立起來的系統，因此便於交流，減少了不必要的時間開銷，同時也是體系結構更加清晰明確。而剩餘人員的智慧型的專業化分工使得他們的工作能夠更加高效。
《人月神話》閱讀筆記（一）
人月神話 是由布魯克斯編寫的，其內容源於作者在ibm公司任system計算機系列以及其龐大的軟體系統os專案經理時的實踐經驗。它屬於我們軟體工程專業的優選讀物，因為內容較多我並沒有讀完，這裡寫下我所讀過的內容中，所體會到的東西。本書開篇是 焦油坑 講了恐龍時代大型動物在焦油坑中掙扎的畫面，來對映出軟...
《人月神話》閱讀筆記一
假期中閱讀了 人月神話 這本書，這本書的思想很靠前，以至於至今還被軟體工程系的人們津津樂道。這本書至今沒有看完，但是所看的那一部分也給了我很大的感觸，所以分成了三次來講述 人月神話 這本書後的感受。人月神話 第一章 焦油坑 給了我兩點感受 1 程式設計系統產品開發的工作量室供個人使用的，獨立開發構建...
人月神話之閱讀筆記一
寒假閱讀王老師推薦的人月神話這本書，一共210頁，分為三部分閱讀，首先閱讀了70頁，那麼對這一部分的內容做下總結 首先，我們軟體工程這門專業正如這本書所敘述的，所有職業都有樂趣，那麼我們這門專業的樂趣呢？我們剛學的時候還未發現樂趣的 那麼程式設計為什麼有趣？作為回報，他的從業者期望得到什麼樣的快樂？...