关闭

人月神話

1865人阅读 评论(0) 收藏 举报

@單元:IT書訊

@欄目:書評

@標題:人月神話

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

@內文:

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

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

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

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

在筆者己身的經驗中,IT 專案的起始需要細細琢磨 whowhatwhichwhenhow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

l         

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

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

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

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

 

@書名:人月神話

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

@經濟新潮社出版

@售價:480

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:262485次
    • 积分:3389
    • 等级:
    • 排名:第10244名
    • 原创:60篇
    • 转载:0篇
    • 译文:2篇
    • 评论:136条