The Mythical Man-Month
人月神話,探究工時與人力無耗損互換的迷思

人月神話》出版至今已經超過三十年,一直被視為是軟體專案管理的聖經。《人月神話》之所以能歷久不衰,一方面是作者Frederick P. Brooks, Jr.本身曾擔任IBM System/360與OS/360這類大型軟體系統專案的專案經理,因此能從實務中提取出具體意見。另一方面,即使IT產業在這三十年中飛快成長,然而《人月神話》對於軟體專案提出的看法與建議,至今仍有參考價值。

所謂的人月(man-month)是用來衡量工作量的單位,也就是一個人在一個月內所能完成的工作量,例如有個專案預估需要12個人月,那麼如果派了4個人來處理這項專案,理論上只要三個月就能達成。Brooks之所以將這個換算的機制稱為神話,是因為軟體專案在本質上,人力與工時是無法互換的,換言之,當專案進度落後時,光靠加派人力到該專案中,並不會增加產能,反而有可能讓情況更加失控。

Brooks認為,軟體專案在本質上是系統性的工作,在過程中必須處理複雜的交互關係,在溝通上必須花費不少的成本。

因此Brooks認為,在專案的人員配置上,最好是有如外科手術團隊,利用支援性的角色,協助操刀的外科醫師,讓開刀過程可以更流暢,而不是讓整個開刀床旁圍滿了一堆外科醫師。另外書中也針對軟體專案的問題,像是架構與實作的分野、溝通的方式、軟案時程預估、預防失敗等多種面向,提出理論與實務兼俱的立論,希望藉此讓陷入困境的專案能順利走出焦油坑。文⊙黃天賜

Tar Pit
焦油坑

焦油坑是因石油揮發而成的黏稠瀝青,表面會因日照而反射出光亮,而讓野獸誤以為是水池而走近,最後陷在其中無法逃脫。

Brooks以焦油坑作比喻,形容他觀察到的大型系統的軟體開發。雖然系統最後總能釋出、運作,但是開發團隊往往無法達到既定的目標、時程或預算上的要求,因此被種種問題困住的開發團隊,就好像跳不出焦油坑的巨獸一樣。

Tractable Medium
易操控介質

在論及寫程式的樂趣時,Brooks舉出數個原因,包含創造的樂趣、有益於他人、可目睹成果動起來、持續學習的樂趣,以及最後的原因便是易於操控的介質。

在介質這一點,Brooks將程式設計師與詩人相提並論,只要動動腦筋,兩者就可以創造出美妙的事物,而更甚於詩人的是,程式設計的結果,能具體讓人感受到它的運作。一些問題也伴隨容易操控的特性而來,軟體工程便是在解決這些問題。

Aristocracy
貴族政體、菁英份子

軟體系統在設計時,至關重要的一點是保持概念的整體性(conceptual integrity),Brooks認為寧可丟棄某些新奇或更好的特色,以反映出同一組設計理念。

為了達到這樣的目的,在設計系統時,必須採用少數人決定的方式,類似於貴族統治的方式,由架構設計師這類角色,決定系統整體的規格。雖然在開發團隊中採用民主方式,可以廣納意見與創意,卻會破壞概念整體性。

Tower of Babel
巴別塔

巴別塔是聖經上的知名故事,人們想要合作搭建通天的高塔,上帝於是將人類的語言分成多種言語,彼此即無法溝通,高塔的任務即告失敗。

Brooks用這個故事來聚焦軟體開發過程中溝通的重要性,他指出許多問題都源自左手不知道右手在做什麼的情況,因此開發團隊成員應該應用各種方式,包含非正式方法、會議與工作手冊進行溝通。

Document Hypothesis
文件假說

「在成堆的書面資料中,有一小部分關鍵性文件記錄著任何專案管理的核心工作,而這些文件是身為管理者最重要的工具。」這是Brooks提出的假說,而他透過與其他產業運用文件的情況,驗證這個假說的真實性。

紙上作業經常被視為繁瑣、無趣,但Brooks認為對管理者而言,文件能讓團隊的思考與討論更集中,也能作為監督和預警的機制,因此對軟體工程的文件作業和其他產業一樣重要。

Silver Bullet
銀彈

在傳說中,銀彈是殺死狼人的致命武器,因此如果將軟體專案比喻為狼人,那麼能讓狼人一槍斃命的銀彈會是什麼呢?Brooks懷疑這種銀彈並不存在,這和軟體工程的本質有關。

他認為軟體工程的本質是架構許多抽象概念,並進一步制定規格、設計與測試,這造成它的高度複雜性,易變性、隱匿性等特質,因此軟體工程,這些難度不會因為軟體技術進步(像高階語言、整合開發環境)而帶來根本性改變。

Catastrophe
大災難

軟體專案釀成不可收拾的大災難究竟是如何造成的?Brooks認為大災難其實就是每天一點一點地的延誤中造成的。

因此日常的監控機制便相當重要,像是建立明確描述、可量測的里程碑(milestone),或是利用計畫評核圖來監控與應變進度狀況。
另外,成立計畫監控小組,擔任進度的守門員,進而提醒團隊容易疏忽掉的落後時程,對於專案有相當大的幫助。

Auxiliary Program
輔助程式

開發軟體系統,測試與除錯是相當重要的一環,因此建立良好的測試方案就至關重要。Brooks介紹了數種測試方案中應該包含的項目,而在介紹建立充份的測試鷹架(scaffolding)這個項目時,他介紹三種鷹架形式:傀儡組件、迷你檔案和輔助程式。

輔助程式是用來產生測試資料、列印特定分析結果與分析交互參考的表格的工具程式,提升除錯工作的效益。

Surgical Team
外科手術團隊

Brooks認為太多人參與專案開發,往往會增加溝通的成本,容易因為傳達不清形成不良影響。然而面對大系統,精簡的人力又往往增加時間成本。

兩難之中權衡,他認為開發團隊應該像外科手術團隊,不需要每個人都要實際操刀,而是應該安排像隨侍在外科醫生旁邊的支援性角色,增加操刀者的效率與生產力。換句話說,可以適時地加入行政助理、祕書、程式助理等人員。


熱門新聞

Advertisement