一年前開始閱讀人月神話的幾個章節，撰寫一篇關於「No Silver Bullet 沒有銀彈」的文章，主要是討論人月神話中第16章的內容。隨後工作忙碌加上對於書中的內容未能有所體悟，因而將人月神話擱置書房一隅，最近隨著軟體專案的混亂情形，於是我再次品味這本經典著作。
 |
原文書是Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition, 2/E，由Addison-Wesley Professional於1995年出版。
此篇文章，我想談談軟體團隊這個部分。從我過去的經驗當中，每個專案都是由一個人(或二至三個人)從頭到尾負責，因此一個人必須學習各類知識與技巧，時間一久練了不少好功夫(卻累死自己)，自己倒是習以為常！
可是，當自己進入一個企業組織中，竟然發現這組織也是這樣玩！這是績效制度下的結果嗎？擔心考績評比不好計算、還是希望有人可以揹黑鍋啊！軟體不是製造業，軟體不能這樣玩的，難怪怎麼搞就怎麼失敗。
我認為人月神話中的「外科手術團隊(Surgical Team)」的概念值得借鏡，這個團隊是由Harlan Mills所提出的觀點，他建議大系統中的每個小部分都分別交給一個「外科手術團隊」負責，這種團隊的工作優點在於工作是同心且一致的方向，具有概念整體性(Conceptual Integrity)。雖然說是適用於大系統的組織，我(個人直觀)認為小型專案也是可以適用「外科手術團隊」。
「外科手術團隊」的成員是10人，角色如下(其工作內容且參閱書籍)：
- 外科醫師(surgeon)，軟體專案上稱為首席程式設計師(chief programmer)
- 副手(copilot)
- 行政助理(administrator) + 秘書(secretory)
- 文書編輯(editor) + 秘書(secretory)
- 程式助理(program clerk)
- 工具專家(toolsmith)
- 測試員(tester)
- 語言專家(language lawyer)
這種團隊對於軟體專案而言似乎是夢幻，也許是因為軟體不關乎人命，軟體開發可以允許發生失敗(這都快變成定律了...)。因此，一個軟體開發者(軟體工程師)可以從規格制訂、軟體設計、撰寫實作，到後期整合測試與撰寫文件，通通一個人自己來！專案的成敗自己扛，反正程式碼改一改都很快嘛！(這句話你熟悉嗎？)
重要的「Brooks定律」：
在一個時程已經落後的軟體專案中增加人手，只會讓它更加落後。
Adding manpower to a late software project makes it later.
感謝錢一一先生與經濟新潮社對於「人月神話」一書的用心，翻譯品質非常好。
沒有留言:
張貼留言