30年后仍適用的軟件項目管理概念

在人月神話中，工作完成所需的月數，會因人員的增加而遞減，然而由于軟件項目是交互關系復雜的工作，需要大量的溝通成本，因此人數的增加，容易因溝通問題，反而無法達到預期的效果。  

 

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將程序設計師與詩人相提并論，只要動動腦筋，兩者就可以創造出美妙的事物，而更甚于詩人的是，程序設計的結果，能具體讓人感受到它的運作。一些問題也伴隨容易操控的特性而來，軟件工程便是在解決這些問題。

 

貴族政體、菁英份子

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

 

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

 

Tower of Babel

巴別塔

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

 

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

 

Document Hypothesis

文件假說

「在成堆的書面數據中，有一小部分關鍵性文件記錄著任何項目管理的核心工作，而這些文件是身為管理者最重要的工具�！惯@是Brooks提出的假說，而他透過與其它產業運用文件的情況，驗證這個假說的真實性。

 

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

 

Silver Bullet

銀彈

在傳說中，銀彈是殺死狼人的致命武器，因此如果將軟件項目比喻為狼人，那么能讓狼人一槍斃命的銀彈會是什么呢？Brooks懷疑這種銀彈并不存在，這和軟件工程的本質有關。

 

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

 

大災難

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

 

因此日常的監控機制便相當重要，像是建立明確描述、可量測的里程碑（milestone），或是利用計劃評核圖來監控與應變進度狀況。

另外，成立計劃監控小組，擔任進度的守門員，進而提醒團隊容易疏忽掉的落后時程，對于項目有相當大的幫助。

 

Auxiliary Program

輔助程序

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

 

輔助程序是用來產生測試數據、打印特定分析結果與分析交互參考的表格的工具程序，提升除錯工作的效益。

 

Surgical Team

外科手術團隊

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