發表文章

目前顯示的是 2010的文章

蓋房子和寫軟體

往花蓮的自強號上,旁邊坐著一位五十幾歲的長者,一直反覆的看著一本旅遊書籍,看起來是歐洲旅遊的書。我好奇便問他:『剛從歐洲旅遊回來嗎?』,他嚇了一跳,我連忙向他道歉,他親切說;『沒關係』,接著很興奮的告訴我他的攝影心得,就這麼聊了起來。

他一邊翻閱書上的照片,許多的地方他都去過,他說他喜歡研究別人取景的角度為何和他不同,借此學習更好的攝影技巧。看得出他對生命充滿熱情,喜歡思考、創作與分享。聊著聊著才知道他原來是台中知名建商的董事長。

除了生活上的樂趣外,他也跟我分享他的經營理念。他對員工的要求是『不能凡事都照著規格書、設計圖走,那是官僚』。為什麼?他們的員工每天都在接觸房子的買賣,久了就麻痺了,以為房子的買賣很輕鬆,但是對許多買房子的人可能是畢生的積蓄,一生可能只買一次房子。

他說他接觸過很多醫生、教授或高科技產業的客戶,他們在自己的領域上十分的專業,"但對房子的事情真的就是不懂",所以不能拿規格書來壓他們,應該是要幫助他們。

姑且不論這位董事長是否真的做到這樣的原則(畢竟我跟他不熟),這些道理在軟體工程產業上也是相通的。寫軟體的如果在客戶搞不清楚規格的情況下一直以規格來壓客戶,那就是以專業的傲慢來欺騙客戶的無知。

當然,蓋房子跟寫軟體畢竟不同,各位覺的呢?

有理說不清

軟體系統常常背上許多莫需有罪名,有時候是需求的提供者沒把需求說清楚(或根本說了錯誤的需求),有時候是使用者不會用 (沒參與教育訓練或沒看說明書)造成操作不當。當後者的情況發生時,使用者通常會怪罪『介面設計不好』。

的確多數的軟體工程師對於介面的設計不重視也不在行,但有時候使用者也太無理取鬧,把所有的錯誤都賴在介面設計上。

張大叔最近開始使用線上照片沖洗的功能,但照片卻遲遲沒有寄到,他上網查了一下,發現住址寫錯了。他打電話到客服中心發飆。
『你們的系統有問題不穩定,把我家的地址記錯了。明明是100號,怎麼會記成200號?』

客服查了一下,回應說:『張先生,有可能是您打錯了,系統記錄的的確是200號』

『怎麼可能?我打過無數次了,怎麼可能會把自己的住址打錯?』

客服有耐心的說:『有可能1和2相鄰,您打的時候打太快了,所以不小心打錯了』

『那你們系統要做檢查嘛,哪有那們笨的系統?要做防呆嘛』

客服楞了一下,還好他邏輯還清楚:『張先生,我們系統不知道你住100號,怎麼知道您打錯了?沒有辦法喔...』

這下換張大叔楞了一下,但他還是很生氣。『這照片是我送給老婆的生日禮物,照片我選了好久,沒有按時寄過來這個禮物就沒有意義了』,頓了一下又說:『你們要怎麼賠償我的損失?』

『先生,這是您打字錯誤所造成的,我們沒有辦法賠償。我們會通知郵局將包裹重寄,但您要再負擔一次運輸費用』客服說。

張大叔一聽還要多負擔就生氣:『都是你們系統的問題為什麼要我負擔?你們介面設計的太糟,介面要儘量防呆嘛... 比如說不要讓我們用打的,讓我們用選的...』

客服有點聽不下去了:『先生,忠孝東路門排很多,我們不可能把所有門排都列出來讓你選』

『怎麼不可以,你可以每一個位數都用一個下拉式選單,三個位數只需要三個下拉式選單,你們設計要用點腦筋嘛』

...

問題解決

古時候,中國有一則寓言是說:有四個人走到一面高牆前面,高牆的通門用鐵鍊與鎖鎖住,其中三人試圖用盡各種方法要打開門鎖,用石頭打、火燒、以及用木棒挖鎖等方法,但最後仍然無功,這時候,忽然看到那第四人從森林走出,手握一把長竹竿,走到牆面前以撐竿跳的方式跳過那一面牆。

第四人並沒解決門鎖的問題,而是避開重新定義問題,創造新的而可解決的問題,因此基本上問題不在門鎖,而目的是人要到達牆的另一面。

這則故事顯示,"what"與"how"的問題,前面三個人只想『我如何打開那道門』(how),至於另外一個人則避開那三個人的困境,只是想『我要做甚麼』(what),答案是『我要過那面牆』,一旦他將問題放在"what"上面,他就可以設計如何執行而獲得成功,他解決問題不只是解決,而是問題要合理解決。

發展軟體就應如這則寓言中第四人的作法,要如何達到有許多方法,其中CRC cards (Class-Responsibility-Collaborator cards)技術,可能是最佳方法之一,但似乎未在國內引起廣泛注意,我們另文討論。

從種樹小故事看流程改善

今天上課前突然想到一個故事,稍作改變後用來跟學生講解流程改善。

某公司聘用一個員工上種樹,他需要鋤頭挖洞,將樹植下,最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹,比老闆預期的進度差太多,於是老闆又聘了兩個人來幫忙,速度提昇了兩倍。

[from work harder to work smarter]
但是這樣的速度還是不夠快,而成本又太高已經沒有經費在聘用員工,只好想辦法進行流程改善。他仔細觀察三個員工的工作方式,發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作:A 只做挖洞的動作,B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間,更棒的是,每個人更能夠把自己的工作做的專精,效率又提高了兩成。

[但,小心成為官僚流程]
這樣的流程跑了很久,員工來來去去換了許多次,但都保持一定的高效率。一天,老闆去看工地,發現A 挖玩洞後,C 緊接著把洞補起來填平,老闆生氣的說:『你們在做什麼?B君呢?』
『喔,他今天請假了』A 說。

最後這個笑點看似誇張,但在企業流程卻常見。許多人習慣了只知道follow 流程去做,卻不之所以然,所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練,所以常常空有好流程卻無法發揮最大的效用。

軟體工程與大型整合專案—以WiMAX整合型計畫為例 (3/3)

圖片
Continuous Integration

在討論版本控管時,我們曾經提到WiMAX計畫使用一個輔助工具「JCIS」進行持續整合(Continuous Integration)的工作。那麼,為什麼要做持續整合呢?維基百科中對於持續整合的理論有些初步的介紹,包含下列十個重要的Practices:
維護一個程式庫(Maintain a code repository)將建置自動化 (Automate the build)使建置能進行自我測試(Make the build self-testing)每人每天送交程式碼(Everyone commits every day)每次送交都應該被建置(Every commit should be built)維持快速的建置時間(Keep the build fast)在實際運行的環境下進行測試(Test in a clone of the production environment)簡化取得最新可交付版本的方法(Make it easy to get the latest deliverables)每個人都能看到最新版建置的測試結果(Everyone can see the results of the latest build)將佈署自動化 (Automate deployment) 上述許多Practices都要求自動化,自動化又可以分為半自動和全自動,以半自動為例,可能是有人每天固定手動執行make指令,將所有要建置的檔案編譯與連結,接著有人將結果複製到實際運行的環境,再下指令讓電腦執行所有的測試,這個過程雖然必須由人來操作,但只要下少許指令就可以完成了。那麼全自動呢?就是在專案開始的時候進行若干設定,之後由電腦自動處理一切編譯、連結、測試等工作,這就需要一套輔助工具了。

要確實完成這麼多的Practices,其實門檻是很高的。即使是在企業界,也難免會有不遵守遊戲規則的軟體工程師,更何況我們的開發主力是學校裡沒什麼專案成敗壓力的學生。舉例說,要做到「每人每天送交程式碼」幾乎是不可能的,基本上學生開發程式是有一天沒一天的,最多只能要求到「有修改就必須送交程式碼」。另外像是「每次送交都應該被建置」,在我們第一年的WiMAX計畫中可以說是完全失敗。在開發環境未能統一的情況下,子計畫的開發人員往往以為只要在自己的開發環境上能建置…