人月神話

原创 2006年05月27日 11:18:00

@單元: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

相关文章推荐

人月神话读书笔记(11)----未雨绸缪

未雨绸缪不变只是愿望,变化才是永恒。试验性工厂和增大规模 对于大多数项目,第一个开发的系统并不合用。它可能太慢、太大,而且难以使用,或者三者兼而有之; 系统的丢弃和重新设计可以一步完成,也可以一块块地...

“人月神话”摘录

焦油坑 编程的乐趣与苦恼 思维创造性活动的特性注定在这个创造活动中有太多的困难与不确定因素,每个细小的偏离的累积都会象焦油坑一样使你举步维艰。 一 人月神话 编程,一个...

人月神话札记:削足适履

前言:所谓削足适履,就是把解决问题的办法弄得本末倒置,使用了错误的方式去解决问题,自然就得不到好的结果。那么如何才能更好的解决问题呢,对于本章,我已经反复读了5遍了,然而苦于自己的理解能力,我仍然一知...

人月神话,那么远,有那么近

《人月神话》 关于软件工程方面的书记可谓是多如牛毛,可是有多少是基于实际开发项目抽象而出的呢?很幸运,《人月神话》就是这样的一本书,真真正正的从实际大型项目中领悟而来,可谓经典二字。《人月神话》一书...

《人月神话》之浅析

《人月神话》之浅析 “中国科学技术大学软件学院”+ 李 宁 + “原创作品版权所有转载请注明出处”  印象里,第一次接触软件工程,是在大四的时候,当时我们专业选修一门课叫做“GIS设计与实现”,因...

《人月神话》摘录

胸有成竹1. 对常用编程语句而言,生产率似乎是固定的。这个固定的生产率包括编程中需要注释,并可能存在错误的情况。2. 使用适当的高级编程语言,编程的生产率可以提高5倍。削足适履1. 为了满足目标,每个...

《人月神话》读书笔记part1

——这本书的内容是源于作者Brooks在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验,在计算机这个领域里几乎是无人不知。大型编程项目深受由于人力划分产...

【人月神话】第四章:贵族专制、民主政治和系统设计

在软件系统的设计中,概念完整性是最重要的考虑因素。 为了反映一系列连贯的设计思路,宁可省略一些不规则的特性和改进,也不提倡独立和无法整合的系统,哪怕他它其实包含着许多很好的设计。 ...

读《人月神话》

所谓人月(Man-Month),是软件开发中工作量的度量,然而它却不是线性的,10个人10个月可以完成的工作,很多情况下100个人并不能在1个月完成。读完《人月神话》一书,我的理解与摘抄:当人数增多时...

《人月神话》阅读笔记

1.为什么
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:人月神話
举报原因:
原因补充:

(最多只允许输入30个字)