人月神話

＠單元：IT書訊

@欄目：書評

@標題：人月神話

@副標：軟體專案的管理之道

＠內文：

這大概是近年來所看過最好的一本討論軟體專案管理書籍，32 年前的經驗至今竟然歷久彌新，在變動不止的軟體科技上，果然有可抽象、萃取的智慧。

首先節錄一段本書的開場白：「史前時期最駭人的景象，莫過於一群巨獸在焦油坑裡做垂死前的掙扎。不妨閉上眼睛想像一下，你看到了一群恐龍、長毛象、劍齒虎正在奮力掙脫焦油的束縛，但越掙扎，焦油就纏得越緊，就算牠再強壯，再厲害，最後，都難逃滅頂的命運。過去十年間，大型系統的軟體開發工作就像是掉進了焦油坑裡…」。從事資訊工作的你我是否也踩進了焦油坑呢？

IT 專案管理一直是個讓人頭大的事情，因為至今它仍不成熟，仍在手工業階段蹣跚走向工業化。雖 CMMI、Agile、RUP…等等理論與架構盛行，PMP 課程充斥，但資訊專案失敗，不滿意的比率仍大過成功，滿意的比率。

早在 1974 年 Brooks 博士把他帶領建置 IBM System/360、OS/360 的經驗集結成書，撰寫了這本「人月神話」。至今，它的內容依然讓我受益良多。自己在 IT 世界裡，學習、實做了將近 20 年，最大的感嘆莫過於：唯一不變的就是”變”。一直覺得掌握不變的，較為抽象，形而上的觀念，其重要性遠高於埋沒在繁雜變動的技術中。而此本書就是討論這類議題的好書，它敘說著 IT 專案管理上的誤謬。

在筆者己身的經驗中，IT 專案的起始需要細細琢磨 who、what、which、when、how。

who(有沒有夠專業的團隊)：這是成功與否的絕對關鍵因素，沒有正確的人，其他四個 w 都是瞎掰的。

what(需求是否清晰？系統主架構是否明確)：有正確的方向，做對的事情，否則只有嘆將帥無能，累死三軍。

which(什麼樣的技術、軟硬體產品、開發方法論是適合的)：工欲善其事，必先利其器，如此才能把事情做對。

when(什麼是合理的時程，進度)：品質、功能、時程、成本是四個互相牽扯制肘的面向，而時程最難預估與掌控。

how(如何按部就班地實踐)：細節是成功的關鍵，要能有效地施行、監控與評估。

一直覺得資訊專案管理是一門藝術，也就是它不太容易標準化，複製成功案例。它太倚賴高素質的人一起團隊合作，而與人相處本身就是一種藝術，要學有專精的人一起集結創意更是藝術中的精品。

在這本書中，作者條列了 IT 專案的特徵，成功者須具備的條件，失敗者常誤入的陷阱，但並沒有 step by step 的流程，可能 IT 開發的本質就沒有放諸四海皆準的流程，畢竟功能需求、使用技術、人力配置、經費成本…等等面向差異太大。需要管理者小心翼翼，步步為營，關注呵護一個系統的成長。這其實是 IT 經理人應該深思的，就筆者廣泛接觸的經理人，為數不少的人都還在等待書中所懷疑的銀彈，癡妄地以為花點時間學到一套蓋世神功，陷在泥淖的系統開發就可迎刃而解。

一些無心的專業經理人擁有甚囂塵上的 PMP，朗朗上口 CMMI 的枝節，但未關注團隊人心，溝通不良。我無意貶抑 PMP、CMMI、Agile …等學理的重要性，它們非常的重要，或許，可視為現今資訊專案管理的基本知識。但我想強調的是：IT 是活的，落於紙上的都是死的。”擱淺的船就是燈塔”，死掉的理論只能讓我們避免不要在同一塊礁石上擱淺。而無心不經意地駕駛，終究會擱淺在另一塊礁石上。

部份 IT 經理人不具備資訊科技的基本常識，也沒興趣吸收常識。對於使用者需求應用面也僅略知一二，整日忙著把酒言歡，與關鍵關係人建立人際關係。奢言要求他對系統主架構的認知與重視。

同時，在人月迷思中，貶抑了專業的價值，以為人多就可辦事，花錢就可解決問題，而不思如何建構具水準的團隊。想要當個入門的 IT 經理人，或許需要先讀通本書，了解揉合科技與人性的困難。

30 多年前，Brooks 博士在本書中所提及的概念，至今仍是 IT 開發的圭臬，由於己身知識與經驗不足，我試著表列自認為的重點如下：

l          軟體開發的問題源自於本質上的複雜性，以及複雜性隨著軟體規模成非線性成長。

l          人月是個危險並很容易就遭到誤解的迷思，因為他假設人力和工時是可以互換的。

l          在一個時程已經落後的軟體專案中增加人手，只會使它更落後。

l          同樣資歷下，優秀程式設計師的生產力要比差勁的好上十倍。

l          專案如果要成功，人的品質，以及人的組織與管理，遠遠比他們所運用的工具或技術要來得重要。

l          設計系統時，最重要的是保要概念整體性。

l          太多的失敗都源自於自始至終都搞不清楚要做的是什麼。

l          專案經理最好的朋友，就是整天和他唱反調的，獨立的產品測試小組。

l          每個子案子(subproject)都必須具備兩種領導角色，也就是管理者和技術總監或架構設計師，兩種角色的職掌不同，需要的天份也不同。

l          在功能、效率、程式大小、成本和時程之間總是衝突的情況化，架構設計師需要綜觀全局，站在維護使用者利益的角度上做出取捨。

l          為什麼專案會落後一年，因為每次落後一天。每天一點點的延誤讓人無關痛癢，很難預防也很難挽救。

l          軟體專案越到後期，進展越慢。

l          第一次出爐的系統絕少是有用的，把必然的一次失敗納入到正式計劃中，製作測試系統(如現今的 alpha、beta 版本)。

l          每修正一個錯誤之後，都應該將之前所有的測試案例拿來進行迴歸測試。

l          交付出去的程式都應附帶一小組測試案例，包含合法的輸入、罕見的輸入和明顯不合法的輸入。

l          系統除錯與組件除錯相比，所耗費的時間將超乎你的預期，須具備一套條理分明，規劃良好的測試方案。

l          …

在書中，Brooks 博士根據己身的經驗，或是旁徵博引各大師的研究著述，娓娓敘說著箇中原委。讀完此書，讓我有一個深深的感受，資訊專案的開發過程中，局部的錯誤失敗是必然的，並不可怕。可怕的是不能從失敗錯誤中學習，一再犯同樣的錯誤導致全面性的失敗。

若你從事的是資訊相關工作，不管是經理人，架構或需求的分析設計人員，開發、除錯、維護人員等，或許都該翻翻這本書，了解用來安身立命的工作之特質。書中描述了許多應有的態度與方式。從仿效開始，強迫自己養成好習慣，久而久之，自發性地做對的事情，自然會累積成功。

由於本書的各章節有其獨立的討論議題，建議你先概略瀏覽一下全書，在心中對軟體專案的特質有個概念，而後在專案進行中，隨著情境的變遷，再回來溫習一下，相信會更有所得。

期待這一本好書能讓你在資訊海洋航行時，摸索出正確的航向。

 

@書名：人月神話

@Frederick P. Brooks, Jr./著，錢一一/譯

@經濟新潮社出版

@售價：480元

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=757382