人月神話

原创 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

《人月神话》笔记

人月神话(The Mythical Man-Month) 无论多少个母亲,孕育一个生命都需要十个月。...
  • u010180339
  • u010180339
  • 2017年12月31日 00:24
  • 82

人月神话读书笔记(6)----贯彻执行

贯彻执行他只是坐在那里,嘴里说:“做这个!做那个!”当然,什么都不会发生,光说不做是没有用的。项目经理如何确保每个人听到、理解并实现结构的决策?如何保持系统概念上的完整性?文档化的规格说明——手册 手...
  • liujianli
  • liujianli
  • 2016年07月15日 17:05
  • 313

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

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

《人月神话》读书笔记part1

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

人月神话——-读书笔记20141012

1. 焦油坑( The T a r Pit )
  • zhangliye130
  • zhangliye130
  • 2014年10月12日 20:22
  • 452

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

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

[人月神话]读书笔记5--规模与系统完整性&&项目文档重要性

提纲挈领(The Documentary Hypothesis) 削足适履(Ten Pounds in a Five-Pound Sack)
  • Last_Impression
  • Last_Impression
  • 2015年08月15日 18:18
  • 518

[人月神话]读书笔记7--产品品质保障&&日常进度跟踪

整体部分(The Whole and the Parts) 祸起萧墙(Hatching a Catastrophe)
  • Last_Impression
  • Last_Impression
  • 2015年08月28日 10:51
  • 705

2015/4/25 读人月神话笔记

趁着这段时间还能抽出些时间,我对前一段时间在项目里的经历做了很大程度的思考,不得不说前端时间在项目组里的犹如噩梦一般,诡异的后端架构、不稳定的代码实现、紧张的项目进度以及不断的需求变更都将开发推导了噩...
  • adofsauron
  • adofsauron
  • 2015年04月25日 04:00
  • 272

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

未雨绸缪不变只是愿望,变化才是永恒。试验性工厂和增大规模 对于大多数项目,第一个开发的系统并不合用。它可能太慢、太大,而且难以使用,或者三者兼而有之; 系统的丢弃和重新设计可以一步完成,也可以一块块地...
  • liujianli
  • liujianli
  • 2016年07月18日 18:06
  • 290
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:人月神話
举报原因:
原因补充:

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