《人月神話:軟件專案管理之道》(英語:The Mythical Man-Month: Essays on Software Engineering)是由美國軟件工程師暨IBM System/360系統之父佛瑞德·布魯克斯(Fred Brooks)所著文集,全書講解軟件工程、專案管理相關課題,被譽為軟件領域的聖經,內容源於作者布魯克斯在IBM公司System/360家族和OS/360中的專案管理經驗[1]。該書於1975年首次發行(ISBN 978-0-201-00650-6),並於1995年重新發行紀念版(ISBN 978-0-201-83595-3)[註 2],其中新增了對〈沒有銀彈〉一文的評論和回應,與4個額外的新章節。
![]() |
內容簡介
跟只為私人使用而單獨寫出來的組件程式相比,做出軟件系統產品(programming systems product)所要付出的代價將是九倍以上。估計產品化(productizing)的代價是三倍,若要對組件從事設計、整合、測試,進而凝聚成為一個系統,則代價也是三倍,而且這方面的成本計算基本是獨立的。[1]
“ | 史前時期最駭人的景象,莫過於一群巨獸在焦油坑裏做垂死前的掙扎。不妨閉上眼睛想像一下,你看到了一群恐龍、長毛象、劍齒虎正在奮力掙脫焦油的束縛,但越掙扎,焦油就纏得越緊,就算他再強壯、再厲害,最後,都難逃滅頂的命運。過去十年間,大型系統的軟件開發工作就像是掉進了焦油坑裏…… | ” |
——佛瑞德·布魯克斯[2] |
軟件開發的另一個難題,是從單一程式到軟件系統過程中,所造成複雜度的快速上升,期間並需要包含不同的活動與技能,使得軟件開發必須面對多樣性的挑戰。布魯克斯最早認識到設計程式、開發軟件的差別,他以程式與系統、產品的差異,解釋兩者之間的不同,並以3×3的複雜度加以說明。[3]
人月神話(英語:The mythical man-month):這部分講述人力和時間並不呈現線性關係。指出以大量人員和較短的時間,並不能縮短軟件的開發進度。一窩蜂的作業方式無助於軟件生產,且會製造麻煩,產生出更差的軟件。向進度落後的專案追加人力,只會使進度更加落後。因為新進的人員需要時間了解整個專案,而增加額外的溝通消耗。當有N個人必須在這群人之中進行溝通時(無階級關係),當N增加,其輸出M將抵消其效益,甚至倒退(最後幾天所完成的進度,遠不如剛開始幾天所完成的進度。像是發現了許多錯誤)。
- 團隊交流公式:
- 範例:50個開發人員,就要個溝通管道
用「人月」來衡量工作規模的大小是危險的,也是一個容易遭到誤解的迷思,使用人月的前提必須是在人力和工時可以互換的情況之下:當一份工作因具有連續性的限制而不可切分時,就算投入再多的人力,也不會對時程有所影響,生小孩就是需要九個月,你叫多少個媽一起生都一樣,軟件工程就是像這樣的工作,因為它必須除錯,而除錯本身就具有連續性的本質。[1]
人月(英語:man-month)指的是「一個人要花幾個月」才能完成軟件開發的單位,通常用來評估一件軟件專案的大小。[4]以成本會計(cost accounting)為基礎的時程預估技術,使我們誤把工作量和專案進度混為一談,人月是個危險並很容易就遭到誤解的迷思(myth),因為它假設人力和工時可以互換。[1]
在一個時程已經落後的軟件專案中增加人手,只會讓它更加落後[註 3]。根據Brooks法則,增加人員到一個已經延誤的專案裏,等於是火上加油。除非你可以把工作區分,讓新進人員可在不影響他人工作的狀況下有所貢獻。
把工作切分給更多人做將造成額外的溝通(communication)代價——訓練和相互的交流(intercommunication)。欲增加軟件專案的人手,總共必須付出的代價可分為三方面:工作重新切分本身所造成的混亂與額外工作量、新進人員的訓練、新增加的相互交流。[1]
在接受相同的訓練、同樣都是兩年資歷的情況下,優秀專業程式設計師的生產力要比差勁的程式設計師好上十倍。短小精悍團隊是最棒的——盡可能用最少的人。兩人團隊,其中一人當領導者,這通常是最佳的用人方式。以短小精悍團隊開發真正大的系統就太慢了。絕大多數大型軟件系統的經驗顯示,使用一堆人蠻幹的方式最耗成本、最慢、最沒有效率,做出來的系統在概念上也最不完整。
以一位首席程式設計師為主、類似於外科手術團隊的組織提供了一個良方,既可因少數人的決策而兼顧到產品的整體性,又可因多數人的合作與大幅溝通減少而得到全部人的生產力。[1]
第二系統效應(英語:The second-system effect)就一個人所做過的設計而言,第二個系統是最危險的系統,一般來說,都傾向於過度設計。[1]
當他做第三或之後的系統時,之前的經驗會互相印證,以確認出這類系統的一般性特色,而系統彼此之間的不同處,也會幫助他辨別出屬於特殊和非通用的部份。除了做些功能上的修飾之外,第二系統效應還有另外一項特徵,那就是傾向於將之前已熟悉的技術發揮到淋漓盡致,但卻沒有留意到,這項技術早就跟目前專案的基本系統假設有衝突而不再適用,OS/360有好多這樣的例子。(Windows NT則似乎是1990年代的範例)
對大部份OS/360的設計人員來說,它也是個第二系統,設計成員分別來自1410-7010磁碟作業系統、Stretch作業系統、Project Mercury即時系統、給7090用的IBSYS作業系統等等,幾乎沒有人擁有兩個上述系統的發展經驗,所以OS/360可稱得上是一個最佳的第二系統效應範例。
手冊或書面規格是不可或缺的工具,雖然光靠它是不夠的。手冊載明的是產品的外部(external)規格,用來描述並制定出用戶從外觀上將或看到的所有細節,撰寫手冊便是架構設計師的主要工作。當用戶和實作人員的反應不斷地顯示出設計上難以使用或實現之處,手冊就會墮入重新準備、修改的輪迴之中。為了造福實作人員,將修改的程度予以量化(quantize)是很重要的——在時程上應該要有載明日期的版本資訊。[1]
失敗的軟件專案經常發生在開發者與用戶間對需求認知的誤解。開發者抱怨用戶說不清楚需求,而用戶抱怨開發者誤解他們的意思。布魯克斯認為「軟件開發最困難的單一項目,是精確地決定要建造什麼。」[註 4]
書目
增修內容:[1]
參見
註釋
參考文獻
外部連結
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.