今天這篇閱讀筆記主要討論《人月神話》中的“人月神話”以及組建“外科手術隊伍”。

????? 首先介紹一下什么是人月神話。我以前聽人月神話的時候總是覺得很玄幻，以為這是一個神話故事之類的。我相信很多剛剛聽到這個詞匯的人都會這么認為，但是經過閱讀發現，人月神話并不是神話故事。這是一種軟件開發過程中的度量單位。估計完成一個項目大概需要多長時間，比如需要12人月，則可以理解為需要3個人工作4個月。

????? 那么怎么又稱為神話呢？因為使用人月這種度量方式，在很多情況下衡量一個一項工作的規模是一個危險和帶有欺騙性的神話。因為在以上關于人月的介紹中，根據這種計算方式，似乎人和月是可以等價互換，互相補充彌補的，但實際情況并不是如此。并不能用增加人的數量來減少開發的周期，這是一種愚蠢的想法和做法。

????? 人們在對項目進行估計的時候往往是非常樂觀的，這是我們應該保持的一種良好的心態，但是我們更要從實際問題出發，遵循客觀規律，不能盲目的樂觀。當人月可以互為轉化時，這說明這個項目的每個模塊的關聯性很小，團隊成員之間的交流也不會很多，而且交流起來會非常簡單，只有基于這種情況下，人月的內涵才能夠充分的得到體現，這種度量方式才能很好的闡述人月可以等價互換的理念。但是事實往往并非如此。每一個項目，項目的各個模塊的聯系都是非常緊密的，而且很多模塊之間是由時間先后順序的，這些因素決定了人月模型并不適合。當人的數量大大增加時，并不能有效的縮短項目的完成時間，相反，還可能會增加項目的時間。

????? 試想一下，當團隊人數比較少時，每個人負責的工作量可能會比較大，但是每個人之間的交流會變得相對來說更加簡單，而且交流的時間會比較少，而當人數比較多時，因為各個模塊并不是孤立的，要考慮到其他的模塊的實現方式，所以交流會變得困難起來，這樣無疑就增加了時間開銷，而且這種事件開銷在一個項目中會占用大量的時間。

????? 那么關于人月之間存在的這種矛盾，我們該如何解決呢？

????? 一是，開發并推行生產率圖表、缺陷率、估算規則等等，而整個組織最終會從這些數據的共享上獲益。

????? 二是，在基于可靠基礎的估算出現之前，項目經理需要挺直腰桿，堅持他們的估計，確信自己的經驗和直覺總比從期望派生出的結果要強得多。

????? 總之，項目的時間依賴于順序上的限制，人員的數量依賴于單個子任務的數量。?從這兩個數值可以推算出進度時間表，?該表安排的人員較少，?花費的時間較長（?唯一的風險是產品可能會過時）。相反，分派較多的人手，?計劃較短的時間，將無法得到可行的進度表。

????? 下面介紹另一種解決方案，組建“外科手術隊伍”。這是一種團隊模式，通過這個模式，理論上來說能夠大大提高團隊開發效率，并在一定程度上有效縮減開發時間。

????? 軟件開發過程中存在以下這幾種情況：

???????????? 優秀程序員和較差的程序員之間生產率的差異。

??????????? ?一擁而上的開發方法是高成本的、?速度緩慢的、?不充分的，?開發出的是無法在概念上進行集成的產品。

???????????? 對于效率和概念的完整性來說，最好由少數干練的人員來設計和開發，?而對于大型系統，?則需要大量的人手。

????? 對于上述情況和存在的矛盾，我們可以通過組建“外科手術隊伍”來進行解決。這個隊伍的核心是外科醫生，他需要親自定義功能和性能技術說明書，設計程序，編制源代碼，測試以及書寫技術文檔。其他的人要對他進行支持和服務。其他人員還包括：副手（工作和外科醫生相同，但不進行實現），管理員（對財務、人員等進行管理）、編輯（整理文檔）、秘書（兩個，負責項目的協作一致）、程序職員（負責技術記錄，類似于構建大師的工作）、工具維護人員（提供特殊工具，保證所需服務可靠運行）、測試人員（設計提供測試案例）、語言專家（解決語言使用上的問題）。

通過這個隊伍，是系統在客觀上達到了概念一致性，同時也確保了工作概念上的一致性。同時由于是外科醫生和副手兩個人建立起來的系統，因此便于交流，減少了不必要的時間開銷，同時也是體系結構更加清晰明確。而剩余人員的智能的專業化分工使得他們的工作能夠更加高效。

轉載于:https://www.cnblogs.com/x-m-/p/8304199.html

總結

以上是生活随笔為你收集整理的人月神话1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。