人月神話 - 軟體專案管理之道

人月神話堪稱經典中的經典,直到最近幾年仍然時常被提起的一本必讀書。主要在討論軟體專案管理上的問題即規劃死角,個人認為無論是程式設計師、PM 或是相關主管甚至是客戶,都值得閱讀的一本書。而我閱讀的這本人月神話是 20 週年再版的書籍,其中已經有部分的修訂,但在書的後方仍然有登載出版的觀念與思考邏輯供讀者參考。人月神話大方向的討論了:軟體專案為什麼容易失敗、如何降低失敗的機率。大致上分為兩大部分,其餘的篇章分別舉出許多細節來支撐自己的論點。

人月神話 - 軟體專案管理之道

作者:Frederick P.Brooks, Jr.
譯者:錢一一
出版社:經濟新潮社


到底什麼是 “人月” 神話 ?

人月神話這個詞要拆分成兩個名詞來看,人月 + 神話人月 指的是每個人每月的工作時間,專案規劃時使用每人每月的工時來估計進度,利用的 人月 這個單位來計算這個計畫是否可以完成。而 神話 則是直接表達了作者認為這種規劃方式是完全不可行的。與 神話 同樣不可能發生的劇情,這也是整本書中最底層的論點:規劃的方式錯誤導致整個專案失敗。

而人月中存在最明顯的問題有三個:第一,是一個人一個月的產值,通常不是 100% 發揮的。工作中會有許多的雜事影響或單純是開發者個心態、心情,各種 BUG 錯誤拖延等等,讓工時直接得低於預估的一個月工作量。第二,工時是無法堆疊的,兩個人的一月,並不等同於一個人的兩個月,軟體開發中有許多工作是有連續性的,先做完 A 才能再做 B,同時一個月加入另一個人並不會加快工作。第三,就算工作是完全可分割可同步進行的,整個專案中仍然有許多的知識迭代,無論在任何時期,加入新的人手,訓練、了解狀況都需要消耗時間,教導新手也會消耗老鳥的時間。作者更是明白的點出:

在一個進度已經落後的軟體專案中增加人手,只會更加落後

嘗試建立一個高度分工的團隊

作者在一開始提出了一個類似 外科手術團隊 的完美架構,認為個個工程師各司其職,每個人負責好自己的區域,行程一個完美的開發團隊。核心概念是:由一個人操刀,其他人扮演支援性的角色。為了讓系統的整體架構設計有一個統一的概念,統一個設計思維。作者同意這屬於專制的團隊,由極少數人掌控著整個系統發展的方向和設計細節。理所當然的,對於這個獨裁者的技術能力、長遠的規劃視野就相當的重要。在設計模式和無暇程式碼的書中都有提到,系統、程式碼的設計最終原則就是要能體現出自己的目標,一貫的呈現風格就顯得相當重要。

這邊有相當重要的一點:高度分工的團隊需要優秀的領導者,首當其衝的就是這個領導者幾乎不能犯錯,因為每個開發者對於整個團隊的了解都是片面的,如果我們片面的了解事情,有時會相當難去判斷對錯。盲目的開發下,很有可能開發出 “完全符合需求卻錯誤” 的情況,需要領導者必須能完美給予任務命令或是能及時地發現這些錯誤。同樣,這名核心管理者也需要相當能力的溝通技巧。

關於溝通的部分,書中相當重視如何傳達想法。而作者的核心觀念是:完整的文件。同步這份文件、溝通的方式將會影響這整個系統的成敗。而今天的我們也知道,除了文件之外,我們有更多高階的語法、測試程式碼可以在這方面協助我們溝通。

作者相當推薦大家選擇更語意化的高階程式碼,從這邊可以嗅出一點這本書的年齡。

第二系統效應

第二系統效應,在開發第一套系統時,會遭遇許多設計上的瑕疵,想要更多的功能,希望能重構的程式碼。會產生許許多多新的想法,但因為時間的需求或是開發上的難度,沒有辦法執行。當我在第二次開發同一個系統時,會瘋狂的將之前的願望通通加入到新的系統中,造成第二個系統的開發負擔,或是產品需求不夠明確。我們應該對一些特別的誘惑保持清醒,確保正確的概念與目標已貫徹到設計的細節之中。

規劃與管理的重點

在規劃上,管理者是需要相當費盡心血。管理者必須明訂,並且嘗試推動整個專案往前,分割成片段式的工作,如果規劃得不夠明確、或是直接丟出超長時間的規劃,那就準備收到一個失敗的結局,因為沒有人會去進行。而規劃排成方面,書中使用大量的專案管理技巧,包括類似瀑布式的規劃、PERT圖等等,預估工作時間是相當困難的,除了專業技巧之外,需要相當多的經驗。

在專案整體的時間分割上,作者認為時間分配為:

  • 33% 規劃
  • 16.5% 撰寫程式
  • 25% 組建測試和早期系統測試
  • 25% 系統測試,完成所有組件

這邊有兩大個重點:撰寫程式的時間其實只有 16.5%,而組裝和測試的時間總合高達 50%,除了規劃需要使用 33% 我並沒有足夠的經驗之外,我個人相當支持後半段的說法,在合併功能時包含的估計除錯所需的時間,的確需要為後半段發生問題的可能性,預留更多的時間。

沒有銀彈

專案管理到底有沒有正確的做法?有沒有真正的解決方案?答案是沒有,也沒有什麼好棒棒的工具可以解決一切的問題,沒有銀彈就是這個意思。專案管理除了專案本身難以估計之外,開發人員的問題、系統的問題、甚至是是否能應付客戶,都是會影響整個專案的結果。並沒有一個絕對的招式或是方式能解決所有的問題。仍然仰賴管理者的經驗和專業技巧。

結語

這本書的觀念相當清晰,除了嘗試正確預估的工時之外,其餘的部分都在傳達我們要如何寫出正整潔的程式碼,穩定的系統是快速開發的基底,高品質的程式碼能有效的降低錯誤機率,因為錯誤是拖慢專案速度的元兇殺手。

在書中有提及一些東西我完全沒有提到,包括:高階程式語言、記憶體配置、專案管理的算法細節、結構設計、更好的開發工具等等,其中的內容也都是相當彩的篇章,但其實個人覺得有點跟時代脫節,舉例來說現在主流的 Git 就解決了許多作者所說的溝通和管理問題。而其餘設計細節,我認為這完全是另外的討論項目了,所以沒有在這邊多加贅述。

其實這本書明顯的感受得到年紀,畢竟出版是在 30 年前,但並不是說觀念老舊或是不合時宜。換而言之,我們現在手邊更多作者當初所期待的方便的工具,能協助我們來解決對應的問題,例如 Git, Github 就是很好的例子,讓我們能擁有便捷的溝通方式,而且是直接在程式碼上做溝通,測試、文件工具等等現在更是發展的一應俱全,如何利用這些配套的工具強化團隊效率,反而是我們當今的課題。

分享到