簡明人月神話:專案管理之道(The Mythical Man-Month)導讀書摘


Posted by KD Chang on 2021-04-05

前言

在程式設計和軟體開發的圈子中,有幾本經典的書籍即便在資訊科技快速變遷的時代中仍歷久彌新。這次要為讀者介紹的是人月神話這本書。這本書是軟體工程和軟體專案管理上的經典著作(雖然是 1975 年初次出版,距今已經二三十年前出版的書籍),即便在現今的軟體開發領域仍有極大的影響力。

人月神話這本書的作者 Frederick P. Brooks 是開發 IBM System 360OS/360 等大型系統專案的主要負責人,專案人力投入超過千人,累積數千的人年(man-year),是非常龐大的大型專案。也因為有過如此龐大專案管理經驗是非常難得的,作者 Brooks 因此透過反思和整理紀錄的方式將大型專案管理常見的問題整理成冊,希望提供軟體開發和專案管理後進一個參考。當然,即便閱讀完本書也不能完全解決實務上在軟體專案開發管理的難題(軟體工程、專案管理是一個跨學門的學科,不單只有技術還有社會科學、心理學和管理學等相關知識),但至少有一個可以參考的方向。接下來本文會摘錄一些書中重要的內容和觀念以及加入筆者個人自己的一些心得進行分享。

你寫的軟體是產品還是程式?

不就是寫個程式嗎?有這麼困難?

在開始討論軟體專案管理之前我們先來定義要討論的軟體產品。作者認為一般工程師單獨寫出來給自己用或是可丟棄的是程式(program)。透過通用化、測試和建立文件後可以成為一個軟體產品(programming product)。許多的程式元件整合在一起就成為了軟體系統(software system),具有跨元件和介面等特性(原本個別程式都可以運作,結果整合後卻出現了一堆 bug!)。而同時具備軟體產品和軟體系統特性的就稱為軟體系統產品(software system product),是我們軟體開發和專案管理最終希望產出給客戶使用的產物。

這也是為什麼軟體開發比你想的複雜的原因之一,根據作者估計,將一般的單獨程式進行產品化所需要的成本是三倍,將程式組織成系統所需要的成本也是三倍。也就是說若要推出一個完整的軟體系統產品(software system product),所需要投入的成本是一般單獨程式的九倍以上。

學習軟體工程最困難的部分就是要調適自己習慣於追求完美

為什麼軟體開發時程總是估計不準?

軟體專案進行不順利的原因或許很多,但絕大部分都是肇因於缺乏良好的時程規劃所致

作者 Brooks 認為軟體開發時程時常有誤差的主要原因在於:

  1. 過度樂觀:許多程式設計師在規劃思考時過於樂觀,思考不等於實作,有時真正開始動手才發現未能事先預估的問題。另外有許多軟體工程師甚至未清楚了解需求即動手開始實作,也會導致實作不符合所需的程式,徒然浪費了時間。
  2. 人月的迷思:如同懷孕生小孩一樣,需要至少九到十個月不可分割的工作,即便找了十個母親一起幫忙,還是無法縮減時程。對於許多軟體開發專案來說,有許多的工作無法完全切割或是即便多加人手也會增加溝通協調成本,不是增加人手就可以減少工作量(這就是所謂的人月迷思神話 The Mythical Man-Month)。
  3. 系統測試:一般情況下軟體工程師大部時間寫程式時間只佔一部分,還有一大部分時間需要處理溝通規劃和測試。所以合理的時程預估經驗法則應該為:
    1. 1/3 時間規劃
    2. 1/6 時間寫程式
    3. 1/4 時間元件測試
    4. 1/4 系統測試
  4. 缺乏堅持的勇氣:當客戶或是對於第一線開發狀況比較不熟悉的大老闆希望加緊進度時,專業的軟體工程師未必能堅持用客觀的角度(或是沒有權力)去堅持合適的開發時程,導致合理的開發時程不斷被壓縮。對於缺乏堅持的勇氣的工程師而言,在組織中尋求其他工程師及主管的支持和協助是一個可能的解方式。
  5. 惡性循環:在進度落後的專案中,人們往往經過直覺思考就是追加人手來加快速度。然而對於大部分的軟體開發專案來說,在時程已經落後的軟體專案中增加人手,代表的是需要更多的內部溝通協調成本和訓練新人的成本,因此會導致專案時程陷入惡性循環和黏人的焦油坑中。

在時程已經落後的軟體專案中增加人手,只會讓它更加落後

軟體開發如外科手術團隊

在軟體開發領域中有一個特別的現象,那就是頂尖的軟體工程師和普通工程師的生產力有可能有機會相差到十倍以上。若是小型專案,可以透過兩人團隊,其中一位為領導者負責設計規劃架構和主要實作,另外一位為副駕駛協助實作,運用短小精悍的團隊可以產生極大的生產力。

對於大型專案而言,透過即早溝通需求和由少數架構小組進行架構規劃設計並由第三方團隊進行回饋建議。在實作部分則透過一位首席程式設計師為首,組織類似於外科手術團隊的輔佐組織(首席醫師主要操刀加上一群輔助的團隊),可以因為只有少數人擁有決策權兼顧了產品的整體性(conceptual integrity),也可以因多數人的合作與大幅減少溝通而得到全部人的生產力。

總結

以上簡單整理了人月神話:專案管理之道(The Mythical Man-Month)導讀書摘,接下來筆者會持續透過閱讀分享更多經典的軟體開發和程式設計、專案管理以及產品設計書籍與讀者分享。優秀的開發人員除了持續鑽研技術外,若能持續學習關於軟體人員職涯規劃和經營管理相關知識,將對於開發人員的職業生涯有更多元的選擇機會。若讀者有建議提醒或是新的想法也歡迎一起交流討論!


#The Mythical Man-Month #人月神話 #專案管理 #project management









Related Posts

【Day06】實戰開始 - 區塊分割2

【Day06】實戰開始 - 區塊分割2

SQL For Loop, Using Cursor

SQL For Loop, Using Cursor

JS-[Ajax篇]-callback hell 回呼地獄

JS-[Ajax篇]-callback hell 回呼地獄




Newsletter




Comments