茶年 · 中文维基百科

人月神话

Wikipedia · 2026-07-17 维基百科 👁 1 阅读

《人月神话：软件项目管理之道》（）是由美國軟體工程師暨IBM System/360系統之父佛瑞德·布魯克斯（）所著文集，全書講解軟體工程、项目管理相关课题，被譽為軟體領域的聖經，內容源於作者布魯克斯在IBM公司System/360家族和OS/360中的專案管理經驗。該书于1975年首次发行（ISBN 978-0-201-00650-6），並於1995年重新发行纪念版（ISBN 978-0-201-83595-3），其中新增了对-{zh-hans:《;zh-hant:〈}-没有银弹-{zh-hans:》;zh-hant:〉}-一文的评论和回应，與4個額外的新章節。

內容簡介
焦油坑
跟只為私人使用而單獨寫出來的組件程式相比，做出軟體系統產品（programming systems product）所要付出的代價將是九倍以上。估計產品化（productizing）的代價是三倍，若要對組件從事設計、整合、測試，進而凝聚成為一個系統，則代價也是三倍，而且這方面的成本計算基本是獨立的。}}

軟體開發的另一個難題，是從單一程式到軟體系統過程中，所造成複雜度的快速上升，期間並需要包含不同的活動與技能，使得軟體開發必須面對多樣性的挑戰。布魯克斯最早認識到設計程式、開發軟體的差別，他以程式與系統、產品的差異，解釋兩者之間的不同，並以3×3的複雜度加以說明。

人月神話
人月神話（）：這部分講述人力和時間並不呈現線性關係。指出以大量人員和較短的時間，並不能縮短軟體的開發進度。一窩蜂的作業方式無助於軟體生產，且會製造麻煩，產生出更差的軟體。向進度落後的專案追加人力，只會使進度更加落後。因為新進的人員需要時間了解整個專案，而增加額外的溝通消耗。當有N個人必須在這群人之中進行溝通時（無階級關係），當N增加，其輸出M將抵消其效益，甚至倒退（最後幾天所完成的進度，遠不如剛開始幾天所完成的進度。像是發現了許多錯誤）。
:* 團隊交流公式： n(n - 1)/2
:* 範例：50個開發人員，就要 50(50 - 1)/2 = 1225 個溝通管道
用「人月」來衡量工作規模的大小是危險的，也是一個容易遭到誤解的迷思，使用人月的前提必須是在人力和工時可以互換的情況之下：當一份工作因具有連續性的限制而不可切分時，就算投入再多的人力，也不會對時程有所影響，生小孩就是需要九個月，你叫多少個媽一起生都一樣，軟體工程就是像這樣的工作，因為它必須除錯，而除錯本身就具有連續性的本質。以成本會計（cost accounting）為基礎的時程預估技術，使我們誤把工作量和專案進度混為一談，人月是個危險並很容易就遭到誤解的迷思（myth），因為它假設人力和工時可以互換。

  • 20週年紀念版

二十週年紀念版
增修內容：
#將初版中所主張的所有論斷整理出一個簡潔的摘要，包括了原書的主要理念：就人力配置的比例而言，大型軟體專案所面臨的是跟小型專案完全不同的管理問題，這引申出產品的概念整體性是其中的關鍵，而達成概念整體性雖然困難，但卻是可能辦到的。
#作者佛瑞德·布魯克斯對他當初所提出的這些論斷，在經過一個世代之後所做的觀察。
#轉載布魯克斯1986年發表於IEEE《Computer》的論文-{zh-hans:《;zh-hant:〈}-沒有銀彈-{zh-hans:》;zh-hant:〉}-。
#布魯克斯對於他1986年的論斷「十年內不會有任何銀彈」所做的回應。

参见
*反面模式
*代码重构
*-{zh-hans:《;zh-hant:〈}-沒有銀彈-{zh-hans:》;zh-hant:〉}-

  • Productive Projects and Teams

注释
參考文獻
引用
來源
; 书籍
*

外部链接

#電腦書籍 #軟體專案管理 #1975年书籍

评论 (0)

  • 还没有评论，来抢沙发吧。