星期四, 12月 29, 2011

約耳趣談軟體 (Joel On Software)



約耳趣談軟體:來自專案管理的現場實錄
Joel On Software
作者:Joel Spolsky (連結至作者部落格)
譯者:梅普華
出版社:悅知文化
出版日期:2010年04月22日
語言:繁體中文 ISBN:9789866348341
裝訂:平裝









  • 約耳測試12點



每點都命中要點,其中KT 特愛4,5,7 和 12點。 



4. 你有沒有問題(bug)資料庫? 
無論如何,只要你在寫程式時(只有一個人寫也是一樣),沒有一套良好的資料庫列出程式中所有的問題,就一定會產生出品質低劣的程式碼。很多程式設計人員自認能把問題清單記在腦子裡,才怪!我從來沒辦法一次記住超過二或三個問題,而且會在第二天早上,或是趕著出貨時把它們全部忘掉。你一定要正式地記錄問題。

問題資料庫可大可小。一個最簡單有用的問題資料庫必須包含每個問題的下列資料:

● 重現問題的完整步驟。

● 應該看到的行為。

● 實際看到的(有問題的)行為。

● 被指派的負責人。

● 是否已修正。

如果你是因為覺得問題追蹤軟體太複雜才不追蹤問題,請建立五欄的簡單表格,填入上述資料,然後開始使用吧!想要深入瞭解問題追蹤,請參閱「無痛錯誤追蹤」一文。


5. 你會先把問題都修好之後,才寫新的程式嗎? 
古早第一版的Microsoft Word for Windows被視為「死亡行軍」型的專案。進度一直處在落後的情況。整個團隊的工作時間長得離譜,專案卻一延再延三延,大家都承受無比的壓力。拖了幾年後,那個鬼東西終於上市了,微軟就把整個團隊送到Cancun(墨西哥著名海灘)渡假,然後再坐下來做深度反省。

他們發現產品經理過度堅持要維持「進度」,而程式設計人員只能匆匆經過編碼階段。而且正式的時程並未包含錯誤修正這個階段,於是寫出的程式碼非常糟糕。此外,也沒有人試圖要減少問題數量,而事實剛好相反!有位程式設計人員要寫支程式以計算一行文字的高度,結果他只寫了「return 12;」,並等問題報告出爐指出這個函數功能不對。於是,時程表變成一份等著被轉換成問題的功能列表,事後檢討時則稱之為「無窮錯誤法(Infinite defects methodology)」。

為了修正這個問題,微軟全面採用所謂的「零錯誤作法(Zero defects methodology)」。公司裡很多程式設計人員聽了都不禁竊笑,因為感覺就像是管理階層認為能用行政命令降低錯誤數量一樣。實際上,「零錯誤」是指無論何時都要先修正錯誤才能寫新程式。原因如下:

一般來說,愈晚修正錯誤,修正時所付出的成本(時間及金錢)愈高。舉例來說,當你打錯字或出現編譯器會發現的語法錯誤,就修正只是小事一樁。

若你的程式第一次執行出錯時,應該也能立即改正,因為整個程式還在你腦海裡。如果要為幾天前寫的程式除錯,應該需要回想一陣子吧!不過,當你重讀所寫的程式後,就會記起所有細節,並在適當時間內把問題修好。

若是要為幾個月前寫的程式除錯,那很有可能已經忘掉一大半,要修正簡直難上加難!或許,你正在替別人的程式除錯,而當事人遠在阿盧巴渡假,這時除錯的任務就像科學一樣:你得條理分明、小心翼翼地慢慢來,也無法確定要多久時間才能解決。另外,如果要為已出貨的程式除錯,修正問題的代價就更難以估算了!

這就是要立即修正問題的理由之一,因為這樣做能少花點時間。另一個理由是,寫新程式的時間遠比修正現有錯誤的時間容易估計。舉例來說,如果要你估計寫串列排序的程式需時多久,你應該能估算得相當準確;但假如你的程式在裝了Internet Explorer 5.5之後有問題,要估計需要多久才能修好,恐怕用猜的都猜不出來,因為你不知道(當然不知道)問題點在哪裡。要找出問題可能就要花上三天,但也可能兩分鐘內解決。

如果時程裡包含很多有待修正的問題,那麼這種時程是不可靠的。假如把已知的錯誤都修好了,剩下的就只有新程式了,那麼時程就會變得非常準確。

把錯誤數量維持在零還有另外一項優點,就是面對競爭時反應可以更快。有些程式設計人員認為這樣做可讓產品隨時推出。一旦競爭者推出某個殺手級新功能來搶客戶時,只要把該功能加上去,即可立即出貨,不必修正累積下來的大量問題。


7. 你有寫規格嗎? 
寫規格就像是使用牙線:大家都同意這是好事,卻沒有人真的這麼做。

我不知道原因,或許是大多數程式設計人員都討厭寫文件吧!所以當全是程式設計人員的團隊面對問題時,自然傾向用程式碼而非文件來表示。他們寧願跳進去寫程式,死也不願先寫規格。

在設計階段發現問題時,只要改幾行文字就能輕易修正。但等到程式寫出來之後,修正的代價就高多了,代價包含了情感(人們討厭拋棄程式碼)和時間,所以會抗拒修正問題。通常未依據規格製作的軟體,到最後的設計都很糟,而且進度完全無法控制。這似乎就是Netscape所發生的問題。它的前四版一團亂,結果管理階層還愚蠢地決定把程式丟掉重新開始。然後在Mozilla上又重蹈覆轍,製造出一個無法控制的怪物,耗了好幾年才進入alpha測試階段。

我的小秘方是把程式設計人員送去上密集的寫作課程,讓他們變得不那麼排斥寫作,就可以解決這個問題。另一個方法是雇用聰明的產品經理來寫規格。不管用哪一種方法,你都應該強制執行「沒有規格就不寫程式」這個簡單的規則。



12. 是否進行走廊使用性測試? 
「走廊使用性測試(Hallway usability)」是指在走廊攔住下一位經過的人,然後逼他試用你剛寫好的程式。如果能攔下五個人並且試用完成,就可以發現程式中95%應注意的使用性問題。

設計出良好的使用者介面並沒有想像中那麼困難,但是必須要能夠吸引客戶並購買產品,才是最重要的。你可以參閱我所寫的免費線上使用介面設計書,這是針對程式設計人員的入門書籍。

不過,處理使用者介面有一點最重要:如果你把程式展示給少數幾個人看(事實上,只要五或六個就夠了),就能快速地發現一般人會遇到的主要問題。在Jakob Nielsen的文章中有解釋原因。即使你的UI設計技巧不足,只要強硬逼自己實行不花太多時間的走廊使用性測試,就會讓你的UI水準大幅提昇。(摘錄整理自第三章)























Feature : 功能

Task :任務 (將功能細分很多小節任務)

Priority : 工作優先順序的權重

Orig[Est] (Original estimate) : 最初估計,工作所需時數 (工作應該是以小時計而不是以天計)

Curr [Est] (Current estimate) : 目前實際估計,工作所需時數 (隨時更新實際時程)

Elapsed : 耗時多久

Remain : 提醒還剩幾個小時


附錄:你該知道的Excel二三事

Excel分析工具箱中的WORKDAY函數是個在無痛時程中計算日曆天數的好方法。






參考資料:

1. 書摘─邁向高品質程式碼的12個步驟
2. Joel on Software   周思博趣談軟體
3. The Joel on Software Translation Project:實體書

0 意見 :

張貼留言

回覆意見時,麻煩輸入一下暱稱
(隨便取個名字也好~ ^_^)
好讓我方便回覆您的問題,
選擇「名稱/網址」輸入您的暱稱,
麻煩一下,謝謝大家。

關閉廣告 [X]