《I. M. Wright's "Hard Code"》第一章閱讀札記

I. M. Wright's "Hard Code"》一書的內容係來自作者 Eric Brechner 原先發表於雜誌上的專欄文章,其筆調輕鬆詼諧,有時亦頗辛辣,挺適合躺在床上看。本書還有個特色,就是每篇文章都有附一張作者「玉照」,且每一張都有不同的搞怪表情或動作。不妨到作者的部落格看看,上面的文章也延續了這種搞笑風格。

這本書有簡體中文版,書名是《代碼之道》。台北天龍簡體書局可以買到,價格 180 NTD,還蠻划算,便買了一本。雖然很少讀簡體書,但讀起來並沒感覺特別困難。看了第 1 章,聯想到自己陷入參與的專案,便順手寫下一些感想。

第 1 章的標題是「專案的不當管理」(Project Mismanagement),其中有一篇名為「2001-06-01:開發時程、飛天豬、和其他幻想」的文章,裡頭提到:

我心裡從來沒有特定功能的交付日期,而只有一系列的「專案日期」--里程碑、測試版、正式版發行等等。一個好的開發時程應該只簡單列出每個里程碑所要完成的功能。第一個里程碑要完成的通常都是那些「必須有」(must have)的功能,至於要放哪些、放多少,則須以開發人員的數量和功能的「困難/適中/容易」三種難易度來考量。那些「最好有」(like to have)的功能可放在第二個里程碑,「希望有」(wish)的功能則放在第三個里程碑,其餘功能皆不予考慮。(註1)

[原文]:In my mind, there are no dates for features on a dev schedule beyond the project dates—milestones, betas, and release. A good dev schedule works differently. A good dev schedule simply lists the features to be implemented in each milestone. The "must-have" features go in the first milestone and usually fill it. Fill is based on the number of devs and the "hard/medium/easy" scale. The "like-to-have" features go in the second milestone. The "wish" features go in the third milestone. Everything else gets cut.

第一個念頭是聯想到目前正在纏鬥的專案。這個專案從開標完成、動工開始算,預計整個完工時間大約三年(這是非常樂觀的時程吧 @_@),開發人員粗略估計約 20~30 人--其中包括 PM、SA、PG、測試員、以及其他打雜、跑龍套的人(我算其一)。不過,開發期間人員來來去去,而我並非 PM,所以這些數字只是根據自己觀察所推估的,不見得準。

勉強來說,這個專案也有訂里程碑,稱為一期、二期、三期。以三年分三期來看,這樣的里程碑週期肯定是太長了,作者的建議是每個里程碑應為期 6 至 12 週。但比較奇妙的地方在於,這個專案並沒有明顯區分甚麼 must-have、like-to-have、wish 功能,大概講起來就只有一種,就是:no-matter-what-I-just-want-to-have 功能。回想起來確實挺「隨性」的,專案需要哪些功能,以及各項功能的重要性、急迫性似乎沒有經過審慎評估,而是只要 user 想得到的,通通都放進去,然後再依子系統粗略切割時程和實作的順序。如此隨性的後果,便是有些規劃在初期要先完成的功能,卻因為其他基本功能尚未實作而卡在那裡(沒有先找出功能相依的順序);要不然就是東西寫好了卻沒什麼人用,平白浪費開發人員的時間。

談到做專案總是容易流於發牢騷,寫到這裡就好。

註1:前面摘錄的段落是自己根據原文翻譯,並非取自簡體中文版。我也發現自己翻譯的結果跟簡體版的譯文有些差異(非簡繁術語差異,而是對原文意思的解讀不同)。不過,此差異應屬末節,無關宏旨;抑或是我誤解了原文的意思,也有可能。大體而言,簡體中文讀起來挺順的,比讀原文要快多了(原文挺多俚語之類的,看起來似乎不好翻譯),可以省下不少時間,這要感謝譯者陸其明先生的用心。

2008-12-31 更新:

由於有提到不同譯法的意見,我在發文後便一併到譯者陸先生的部落格留下本文的網址,而陸先生也迅速做出了回應,將翻譯的修正更新到《代碼之道》的勘誤表。對其認真態度表示敬佩與感謝!

沒有留言:

技術提供:Blogger.
回頂端⬆️