l

2011年3月28日 星期一

都市游擊隊

March 28 20:06~21:13

看到標題不要以為這一篇是要談 online game 或是恐怖份子,今天要談的還是 Scrum。

不知道鄉民們有沒有這種經驗,學習了 Scrum ,任何軟體工程的方法或是所謂的 best practices,想要在自己的團隊中大展長才,好好地應用一番,但是卻不時遇到亂流,地震,甚至是海嘯:
  • 在硬體公司中軟體開發不受重視。
  • 沒有資源,要什麼沒什麼。要 tester... 自己測;要 technical writer...自己寫;要測試...沒設備...
  • 人力都已經極端不足了,還被抽調人手去支援其他專案。
  • 計畫比不上老闆的一句話... 時程和需求一直變更。
  • 隔 team 如隔山,而且還是喜馬拉雅山。所有工作只要牽扯到其他 team (同部門或不同部門)就變得窒礙難行。
  • 三姑六婆與鄉民們總是在該講話的時候不講話,不該講話的時候亂放炮。
  • 有些鄉民一時興起想要教你如何『用嘴巴開發軟體』。
  • 另外有些鄉民想要『靠不停的轉寄 email』來了解客戶的需求。
  • 還有些大爺們希望你帶領著『九條好漢』在一年內完成反攻大陸的偉業。
遇到這種情況,請問單兵該如何處置?

請鄰兵以火力掩護我....

很抱歉,鄰兵不是老早就已經『投共』,就是正在以『省電模式』運行中,哪來的火力支持你。

Scrum 告訴我們,要改善團隊,改善產品,改善公司...拜託,人家都可以用飛彈去攻擊示威的民眾了,還是『趴著,趴著,卡賣中槍』。

***

無論你是 Scrum Master,Product Owner 或是 Development Team,是不是也曾幾何時感到空虛,感到寂寞,感到冷,想找一個不是那麼臭的男人 想找一家不是那麼臭的公司來混一混....

請看『建築家 安藤忠雄』這本書,學學他的『都市游擊隊』哲學。

『住吉長屋』是安藤忠雄的出道作品,該建築的特色是:
  • 房屋四面都被牆包圍,沒有對外的窗戶。除了入口以外,沒有別的開口。
  • 整個房屋都是清水混凝土的表面。
  • 把已經很狹小的長方形建地再切成三等分,中間當作露天中庭。
有興趣的鄉民們 google 一下『住吉長屋』就可以找到一些照片。當 Teddy 讀到這邊的時候,也覺得很奇怪,哪有人蓋房子不開窗戶的,這是哪根經不對了才設計出這種封閉的建築?!

簡而言之,安藤忠雄認為(以下是 Teddy 的解讀):
  • 大環境不好(窗戶打開不是看到隔壁正在晒太陽的內衣褲,就是面對別人的抽油煙機或是冷氣機)。
  • 在不好的大環境中,如何創造自己的小宇宙?
  • 結論:
    • 把自己封閉起來,不要看到外面的醜陋(房屋四面都被牆包圍,沒有對外的窗戶)。
    • 將外部空間包覆於住家之中(把屋子切成三等份,中間當作露天中庭)。
安藤忠雄沒有能力(至少在當年)去改變整個大環境,只好以『都市游擊隊』的形式,將自己隔離於世,蓋起自我封閉的碉堡。

***

Scrum 說,要管理階層的支持。問題是,要是管理階層沒有意願支持怎麼辦?

Scrum 說,要有 Product Owner 代表客戶與團隊溝通。問題是,要是 Product Owner 是個馬屁精,只會轉寄 email 與壓榨 Development Team 該怎麼辦?

Scrum 說,Development Team 應該要『自我管理』。問題是,developers 都還是『化外之民』該如何自我管理?


你,不幸剛好是這個 team 的 Scrum Master,在心灰意冷之際,不小心看到『建築家 安藤忠雄』這本書,豁然開朗。既然整個城市不可能打掉重練,那就只能先蓋個『都市游擊隊住宅』。換句古人的話,先『修身』 --> 『修 team』--> 『修 Product』--> 『修公司』。無論環境再惡劣,第一關『修身』還是可做的到的。沒事多看『搞笑談軟工』就算是一種修身了。感恩啊...


***
 友藏內心獨白:本篇有點玄。

2011年3月25日 星期五

電子化比不上一通電話

March 25 22:00~23:22

兩,三個禮拜前,Teddy 要購買長榮航空的機票,因為發現用『花旗長榮聯名卡』去買機票,可以便宜 1000 元,此時 Teddy 貪小便宜的心態又復發,因此就想申請一張花旗長榮聯名卡。說來好笑,去年花旗銀行的人還打電話給 Teddy 推銷這張卡,Teddy  還說之前 Kay 要用這張卡上網買機票,結果便宜的機票老早就沒有了,所以沒什麼 用,還要繳 1200 元的年費,因此就沒辦。沒想到現在卻自己送上門。

由於 Teddy 因故需要趕快買到機票,因此 Teddy 就想利用花旗銀行的『網路申請信用卡功能』來申辦信用卡。透過網路應該都會比較快吧,不是嗎?結果卻是一連串的慘劇的開始。首先,在花旗銀行的網站上填了一堆資料,之後網站會產生一份 pdf 檔案,將 pdf 檔案下載之後,有一張需要簽名,另外還需要附上身份證正反面和第二證件的影本,以及財力證明等資料。

好不容易填完資料後,將下載的 pdf 印出來之後發現有兩個地方的資料填錯了。好,沒關係,用立可白塗掉再用手寫一次。OK,Teddy 把資料都準備好之後,可以選擇傳真或是直接將資料掃描後上載。身為一個資訊人,當然是選擇直接上載啊,況且當時已經是晚上 11 點多了,這時候傳真過去萬一被不相干的人給拿走那 Teddy 的資料不是外洩了。好,先把資料掃描好,再轉成一份 pdf,這難不倒 Teddy。等要上載的時候才發現,...仔細一點,居然最多只能上載四個檔案,而且每個檔案不能超過 1 MB。這是什麼爛系統啊,設計這個系統的人倒底自己也沒有用過?剛剛掃描的資料就算是分成四份也會有一個檔案超過 1 MB 啊,都什麼時代了,還限制一個檔案不能超過 1 MB。

這..... Teddy 有個人的堅持,剛剛因為有三筆資料不小心打錯,所以要多掃描兩頁,因此檔案大了點,再重填一次小心一點不要打錯就好了,這樣可以把檔案控制在 1 MB 裡面。經過一番折騰之後,總於又產生一份新的 pdf 檔案。我......進一點看清楚,居然還是有兩筆資料是錯的,此時 Teddy 才意會到,這個系統有 bugs。天啊,難道 Teddy 每天上班 debug 還不夠,老天爺還要懲罰 Teddy 下班之後繼續幫別人 debug... 算了,不想理他了,直接上載。

***

隔天 Teddy 一直注意手機的鈴聲有沒有響起,想說銀行的人應該會聯絡 Teddy。結果,等了一天除了一通打錯電話的以外,連個屁聲也沒有。好吧,隔天自己打到花旗銀行去問,結果:

Teddy:您好,我昨天在網路上申辦信用卡,想請問一下進度。

花旗小姐:請問您的資料是用傳真的嗎?

Teddy:不是耶,我是直接網路上載。

花旗小姐:請問有人跟您聯絡過了嗎?

Teddy:沒有耶(Teddy 內心獨白:有我還打電話來幹嗎....)

花旗小姐:敝姓 X,很高興為您服務(花旗小姐內心獨白:心中暗爽,自己送上門... 設計對白...)。

花旗小姐:因為網路上載的資料不是隨時都有人去看,我給您一個我們主管的 e-mail,您把資料寄到這個 e-mail 這樣比較快。

Teddy 內心獨白:網路上載的資料不是隨時都有人去看...這是什麼邏輯...難道是 Teddy 在 PxHome 24 HR 上面買太多東西了,形成一種『網路比較快』的錯覺。

Teddy :那要請你等一下,我去找紙筆。

花旗小姐:我直接把 e-mail 用簡訊傳給您就好了。

Teddy :好的,謝謝。不過因為我急著要用信用卡買機票,想請問有什麼辦法可以加速核卡速度嗎?

花旗小姐:請問你要辦的是什麼卡?

Teddy:花旗長榮聯名卡。

花旗小姐:是花旗長榮航空聯名遨遊卡嗎?

Teddy:不是,我要辦花旗長榮航空聯名白金卡。

花旗小姐:那您有任何一家銀行,使用超過一年的信用卡,信用額度在 6 萬(還是 8 萬,有點忘了)以上的嗎?

Teddy:有啊。

花旗小姐:那這樣就可以了,你附上雙證件,把簽名的資料 e-mail 給我的主管這樣就可以了。我趕著明天早上 10 點那一批幫您送急件。

Teddy:好的,謝謝。 

***

明天過後...

花旗小姐:陳先生,我收到您的資料了。在此跟您核對一下資料內容。

Teddy:好的。

......... 資料核對中...........

花旗小姐:那我就幫您送急件,如果核卡成功的話,大概 5-7 天內會把卡片寄到你的帳單地址。

Teddy:好的,謝謝。

Teddy 內心獨白:『急件』還要 5-7 天.... 真是.... 急死人的案件...簡稱『急件』。

***

更扯的是,就在 Teddy 上載完檔案的第二天早上,終於接到一通遲來的電話。

花旗小姐 2:陳先生,請問您是否有在網路上申請花旗信用卡?

Teddy :是滴。

花旗小姐 2:請問有人跟您聯絡過了嗎?

Teddy :有的,她已經幫我把申請資料送出了。

花旗小姐 2:好的,那我幫您把這筆資料取消。

Teddy :謝謝....再聯絡....XD


***

等了 N 天之後終於拿到信用卡了,還好來得及買到原本要買的票。如此的電子化,不禁讓 Teddy 想起之前寫的『需求分析書中最重要的資訊是什麼? 』:

答案:寫這本需求分析書的那個人的電話號碼

咳,再怎麼『電子化』,最終還是比不上一個電話號碼來的實在。

這 1000 塊還真是不好賺啊。

***

友藏內心獨白:申請之後發現這張卡原本的很多優惠都要被取消了,難道當初不申請這一張信用卡的直覺才是對的啊!

2011年3月23日 星期三

同誰,九陰真經不是這樣子練滴

March 23 20:44~22:11

上一篇寫了『Scrum 之逆練九陰真經』,希望鄉民們不要以為 Teddy 鼓勵大家『假 Scrum 之名,行亂搞之實』。上一篇的重點是,就算你是『逆練九陰真經』,好歹練功的內容還是和『九陰真經』相關連,總不能說當年郭靖給歐陽峰一本『瑜伽大全』或是『第一次學有氧舞蹈就上手』然後騙他說這是『九陰真經』,這樣就『騙太大了』。

幾個禮拜前在某個 sprint demo meeting 中,某人用很認真的表情說了一句對 Scrum『大逆不道』的話,令 Teddy 印象深刻:


因為這個 story 太大了,在這個 sprint 中做不完。接下來我打算不要開始下一個新的 sprint,等我繼續把這個 story 做完再說。

這好比你去參加超市所舉辦的 『1 分鐘大搬家』活動,在限時 1 分鐘內隨你搬任何超市內的東西。就在時間截止的時候,你跳出來說『等一下.... 我還沒搬完,等我搬到爽之後你們才可以換下一組人馬』。
***

Teddy 還曾經看過一個類似這樣的 story:

身為程式設計師,我可以設計一個具有擴充性的軟體架構。

不要笑,地球上就是有這種 story,說不定鄉民們不經意也會寫出類似的 story。這種 story 要怎麼施工,要如何 demo?Teddy 也可以舉一反三寫出類似的 stories:
  • 身為食神,我可以做出宇宙無敵好吃的飯菜。
  • 身為歌神,我可以舉辦場場爆滿的演唱會。
  • 身為唬神,我可以寫出超級賣的企劃案。
  • 身為員工,我可以月入數十萬
反正 Scrum 說要把需求寫成 story 啊,好啊,你要 story,我就給你 story,誰怕誰啊,反正吹牛又不用繳稅!於是產生了上述的 stories....Scrum 的『形式』是有了,但是卻沒有抓到重點。這樣的練功方法,不要說『逆練』,就算是學小龍女躺在『寒冰床』上練,甚至是跑到『火星去練』,練的再久都沒用。

***

請問哪個程式設計師不想設計出『具有擴充性的軟體架構』,那個廚師不想做出『宇宙無敵好吃的飯菜』,那個歌手不想『舉辦場場爆滿的演唱會』,那個企劃人員不想『寫出超級賣的企劃案』?問題是,把『幻想 願望』以 story 的形式寫出來不表示這個願望就可以實現。


那麼『具有擴充性的軟體架構』要怎麼達成?很簡單,利用『完成若干個功能性的 story 來達成』。這樣講沒人聽得懂,舉例說明,假設你要開發一個『具有擴充性的會計系統』,stories 可以這樣寫:
  • 身為使用者,我可以安裝新的會計模組-->這樣這個 story 又太大了,繼續細分:
    • 身為使用者,我可以安裝薪資模組
    • 身為使用者,我可以安裝進貨模組
    • 身為使用者,我可以安裝 xx 模組
       上面這幾個 stories 完成後,系統就具備了『功能模組擴充性』,接下來

  • 身為使用者,我可以設定薪資規則 --> 一樣可以繼續細分:
    • 身為使用者,我可以計算全職人員的薪資
      • 身為使用者,我可以計算全職人員的國內出差費
      • 身為使用者,我可以計算全職人員的國外出差費
      • 身為使用者,我可以計算全職人員的加班出差費
      • .....
    • 身為使用者,我可以計算兼差人員的薪資
    • 身為使用者,我可以計算派遣人員的薪資
以此類推,可以一直寫下去。『具有擴充性的軟體架構』是一個很抽象的非功能需求(non-functional requirements or quality attribute),要達到此需求,首先先定義『什麼東西需要被擴充』。藉由將『需要被擴充的功能寫成 stories 』並『逐一完成這些 stories』,一個具有擴充性的軟體架構就完成了。這些 stories 給『具有擴充性的軟體架構』規範了一個 context,在此 context 底下去實現此軟體架構才有意義。有點類似 UP (Unified Process)談的 use case driven 的概念,只是在 Scrum 中改成 story driven。

至於第一個問題,一個 story 如果太大在 sprint 快結尾時才發現做不完該怎麼辦?幾個比較可行的方法包含:
  • 將這個 story 移到下一個 sprint 繼續做(在目前的 sprint 中,這個 story 就不算完成,也不用 demo)。
  • 如果這個 story 就只有這個 story 那怎麼辦?
    • 承認這個 sprint 失敗,並檢討原因,是因為 sprint planning meeting 將 story 估的太大,還是 sprint 進行中發生什麼意外(bugs 太多,員工被抓去開會,支援其他案子等等)...
    • 如果這個 story 可以被細分,那麼看看這個 sprint 完成的內容可否完整的自成一個 story,如果可以那麼沒做完的另外寫一個 story 到下一個 sprint 繼續。
  • 就算是這個 sprint 有很多 stories,而你認為這個未完成的 story 可以被切割,你還是可以 demo 已經完成的內容,並且將沒做完的需求另外寫一個 story 到下一個 sprint 繼續。
理想上 story 沒做完就是沒做完,應該移到下一個 sprint 繼續做。但是有時候這個 story 已經完成的部份的確是可以被單獨 demo 的,那麼倒不一定要強制整個 story 移到下個 sprint。例如,某個 story 原本要同時支援 Windows 與 Linux 平台,但是 sprint 快結束時 Linux 平台的支援還有一點問題。你可以選擇把整個 story 都不要 demo,也可以選擇把這個 story 切割成 (1) for Windows  平台, (2) for Linux  平台,這個 sprint 就可以先 demo 已經完成的 Windows 平台功能(請不要說為什麼一開始的時候不直接把這個 story 拆成兩個...千金難買早知道啊...)。


***

採用 Scrum 遇到『問題』的時後,不是說『老子(老娘)想怎麼樣,就怎麼樣』,Teddy 建議可以視情況所需偷偷地『逆練九陰真經』,但是不是鼓勵鄉民們『亂練九陰真經』,到時候練壞身體不要怪 Teddy... 只好善用你的健保卡...XD

***


友藏內心獨白:為什麼開會的時候常常想學電視上表演那種『從椅子上跌下來』的橋段。

2011年3月22日 星期二

Scrum 之逆練九陰真經

March 21 22:42~ March 22 00:21

話說 Teddy 兩個多禮拜前因為多嘴在 Facebook 上和某人多聊了兩句,最後居然糊里糊塗的答應要去某個活動分享 Scrum 導入經驗...今天沒什麼料,就來談一下 Teddy 準備分享的某個 topic --『逆練九陰真經:不完美的 Scrum』。

鄉民們應該都看過『射鵰英雄傳』,話說郭靖與洪七公被 吸毒 西毒歐陽峰困在一艘船上,歐陽峰逼郭靖把九陰真經默寫出來,郭靖當然是不肯,但礙於形勢所逼,最後洪七公想到一個辦法,要郭靖寫一本『九陰假經』給歐陽峰。由於世界上只有郭靖懂九陰真經,所以他把經書裡面的招式亂寫,歐陽峰也看不出來。

最後歐陽峰練了郭靖所寫的『九陰假經』,雖然是『九陰假經』,但是歐陽峰的武功還是大有進步,只不過代價是走火入魔,整個人變得神智不清。

以上所說和 Scrum 有何關係?鄉民們如果有上過 Certified ScrumMaster 課程,或是有看過 Scrum 相關書籍,應該會注意到 Scrum 有提到『Product Owner 和 Scrum Master 絕對不可以是同一人』這一點規範。其他 Scrum 團隊不應有的現象還包含『某個團隊宣稱採用 Scrum 但實際上在 daily scrum 時還是每一個 team member 都向 Scrum Master 報告』或是『採行 Scrum 一定 最好要有高層支持』等等。有些人甚至會很嚴格的說,如果沒有遵循 Scrum 的精神或規範,那你不可以說你的團隊採用 Scrum,只能說是 『Scrum minus』 或是『死窟窿』。

要求 Scrum 團隊要嚴格依循 Scrum 或是 agile 精神的原意應該是怕很多人『掛羊頭賣狗肉』,好比某些國家,明啊明是獨裁統治,卻偏偏要說自己是民主國家,這樣可不行。但是,如果標準放得太高,一定要做到『美國』或是『西歐』那種程度才算是民主國家,那很多國家就只能算是『民主 minus 國家』。

Teddy 相信在台灣很多聽過 Scrum 的鄉民們可能都曾經有一股想要在自己的專案中採用 Scrum 的衝動,但是,一開始可能先卡在 Scrum 框架所要求的『基本條件』上面。試想一下你在一家硬體公司開發軟體(寫驅動程式或是搭配硬體的應用軟體),公司的主管幾乎都是硬體出身的,也不懂軟體開發。有一天你這個小蘿菠頭興沖沖的跑去跟老闆講『我們來 rum Scrum 吧』!下場會是(請選擇...):

  1. 巴林與利比亞:二話不說,直接派兵亂槍打死。
  2. 中國:連想的機會都沒有...至少保住性命...XD。
  3. 埃及:抗議-->亂槍-->沒死算你命大-->改變。
  4. 突尼西亞:抗議-->抗議-->改變。
  5. Teddy 共和國:不用等鄉民開口,已經採用 Scrum。
Teddy 大膽猜測一下,大概前三者的比例比較會高一點,但是,鄉民們因此就要放棄 民主制度 Scrum 嗎?ㄟ... 要看你有多不怕死,總之,明的不行,咱們可以來暗的。民國成立之後,不是有所謂的『軍政,訓政,憲政,扁政』分三個時期來實施民主制度嗎?鄉民們比歐陽峰還要有優勢,因為歐陽峰不知道什麼是『九陰真經』,只能傻傻的『逆練九陰真經』。鄉民們則是在『知道什麼是九陰真經(了解 Scrum 與 agile 精神)』的情況下,暫時逼不得已『逆練九陰真經』,所以走火入魔的風險稍微小了那麼一咪咪(路人甲:最後還不是走火入魔...XD)。

***

舉個例子,Product Owner 是 Scrum 裡面相當重要的一個角色,負責定義需求(撰寫 stories),對外負責整個產品的成敗。但是,如果一個專案沒有 Product Owner 怎麼辦?

路人甲:怎麼可能沒有?

ㄟ,沒有去找一個不就得了(老梗內心獨白:身份證掉了怎麼辦?撿起來不就好了...),應該是說,沒有『專任的 Product Owner』或是說『沒有對於 problem domain 很有經驗的 Product Owner』。講這樣鄉民們應該就懂了。很多軟體開發,都是『老闆有個念頭』-->『員工做到禿頭』。也就是說,很多所謂『新產品開發』不見得公司都可以找到『有經驗的 Product Owner』來帶領。那怎辦辦,案子還是要做啊,薪水還是要照領啊,總不能跟老闆說『找不到 Product Owner 請換題目』,或是『等你找到 Product Owner 我再來開工』。

那怎麼辦?說實話,很難辦,最後只能使出以下幾個爛招:
  • 別人的需求,就是最好的需求:一字曰之
  • 在爛蘋果裡面挑一個比較不爛的:找一個團隊中最有 sense 的人來當 Product Owner,加上。
  • 三個臭皮匠:專案一開始的時候把大家找來一起研究要『抄』的對象並研究從何抄起。
這樣能做出好產品嗎?Teddy 不保證,但是至少能讓你暫時繼續有薪水可領...XD

***

總之,逆練九陰真經是很危險滴,非不得已不要輕易嘗試。君不見,很多獨裁者年輕的時候也是改革派,也做了很多對國家有益的事,只不過掌握權力久了之後不免就腐敗了(走火入魔)。記得,暫時『逆練九陰真經』或可增加功力,等情況好轉就要想辦法改邪歸正,以免有傷身體。


***
友藏內心獨白:這算是哪門子的 Scrum...

2011年3月17日 星期四

Toolmaker

March 17 22:01~22:51

Teddy 當年還在唸書的時候,雖然主要的研究題目從 e-learning pattern languages (不要問這是什麼....)--> design by contract --> exception handling ,但是在這個過程中,Teddy 不小心接觸到到 Eclipse 與 continuous integration 這兩個領域,又不小心和好幾屆的學弟妹們,在 Eclipse 上面開發了好幾個 plug-ins 以及一個原本叫做 JCIS (Java Continuous Integration System)的持續整合工具(最近改名叫做 ezIntegrate)。

剛開始有些學生會覺的,念研究所『只是』開發工具而不是做什麼『艱深的研究』,好像有點遜掉了。此時 Teddy 博學的指導教授講了一個激勵人心的故事:

在遠古部落時代,人類社會中有三種重要的角色:
  • 巫師(shaman or wizard):在科學還不發達的時代,巫師的身份絕對是在部落中排名第一的『大當家』(酋長除外)。巫師可以卜卦,算命,治病,功能無可取代。
  • 護火者(Firekeeper): 人類懂得用火之後,生活型態因此改變,例如吃熟食,夜晚可以行動。此外,火還可以用來取暖與防止野獸接近,也可以作為攻擊武器,用途多多。因此,在部落中 firekeeper 的重要性使其成為『二當家』。
  • 工具製造者(Toolmaker):人類開始製造工具之後,漸漸拉大了人類與野獸間的差距。赤手空拳打不贏老虎(PS:又不是每一個人都是武松),沒關係,找 toolmaker 做一把箭遠遠地射死你。要喝水,住在河邊又不安全,怎麼辦?沒關係,爸爸買給你 找 toolmaker 做一個陶罐拿來裝水。Toolmaker 的重要性使其成為『三當家』。 
鄉民們,你說『開發工具』重不重要?

***

關於上面這個故事 Teddy 不知道學弟妹們聽進去了多少,不過 Teddy 倒是獲益不少。為了在 Eclipse 上開發 plug-ins,Teddy 學了許多 Eclipse plug-ins architecture 與 patterns(請參考 Contributing to eclipse: Principles, Patterns, and Plug-Ins),有沒有用?非常有用,了解了 Eclipse 的設計之後,嘿..嘿..嘿...興之所至,要當『海盜』也好,要當『山寨』也罷,誰也攔不了你 (Teddy 內心獨白:別人的設計,就是最好的設計)。

另外,為了開發這個 JCIS,Teddy 從原本完全不知道什麼是『持續整合』,慢慢也變成了半個持續整合專家了(雖然 Teddy 還是沒寫過什麼偉大的 ant scripts... XD)。有沒有用?非常有用。

對於做軟體的人來講,有機會『開發支援軟體開發的工具』(有點繞口),是一個了解『軟體開發領域(software development domain)』的好機會。你可能在修『軟體工程』課程的時候學到很多軟體開發領域的知識,但是課程時間有限,為了涵蓋廣度難免就犧牲了深度,而且學生通常『忘性比記性好』,上完課之後很快就忘記了。如果是需要開發支援軟體開發的工具那就不同喔,就和一般的軟體專案一樣,非得從『需求分析』開始做起。等軟體開發出來了,就應該要成為那個領域的 domain expert。念個碩士班如果能夠成為某個領域的專家也算是 C/P 值很高的投資了。

***

友藏內心獨白:講是這樣講,不過自己人開發出來的工具送給你用你敢用嗎...XD

2011年3月16日 星期三

Redundancy

March 16 22:42~23:45

這次日本福島第一核電廠發生爆炸與輻射線外洩事件,引起了全世界的關切。台電急忙出來說明,台灣的核電廠比福島第一核電廠多一部緊急柴油發電機(每部核能機組配備兩台柴油發電機,外加一部備用機,一共五台,10 秒內可供電),2 部氣渦輪發電機(10 分鐘可供電)。此外,核一廠還有 10 萬噸,核二廠有 4 萬噸深水池,可經用來降溫或滅火。

容錯(fault tolerance)的一個最基本的方法就是 redundancy,A 計畫失敗換 B 計畫, B 計畫失敗換 C 計畫,C 計畫再失敗就...雙腳開開,準備投胎...XD。總之,設計一個容錯系統必須依據人們對於『錯誤發生的機率,嚴重性,與可承受性』的不同,來決定要準備多少套『備案』。

講到這邊鄉民們會想,噯呀,當初福島第一核電廠如果設計成『可以防止 10 級地震』那就 OK 了啊,因為地球上還沒有紀錄過超過 10 級的地震...或是準備個 10 台緊急柴油發電機,外加一個翡翠水庫大小的深水池,以及『原子能研究所』所使用的『防護罩』,就不會有今天的問題發生了。姑且不論這樣的『設計』是否有可能被實做出來。就算可以,蓋一座這樣的核電廠可能需要 100 兆新台幣...你出錢嗎?

***

鏡頭轉到軟體開發,從 software process 的角度來看,一個軟體專案會『失敗』有很多原因,好的 process 會想辦法從多種角度來避免這些錯誤發生。例如,defects (或是 bugs)對於軟體開發而言是最直接可被觀察到的錯誤,一個 defects 太多的專案要成功也很難,光是接客戶抱怨的電話就什麼事都不用做了。Agile methods,像是 XP 就採取多重手段來避免 defects 的發生(Extreme Programming Explained, 2nd, p. 31),例如:
  • Pair programming:簡單的數學:兩個腦袋 + 四隻眼睛 > 一個腦袋 + 兩隻眼睛。採用 pair programming 通常可以的到較佳的設計與較低的錯誤率。
  • Continuous integration:衛生署提醒您:定期做健康檢查,早期發現,早期治療。Kent Beck 提醒您:導入持續整合,早期發現整合錯誤,早期修復。
  • Sitting together:開發人員都坐在一起(在同一個房間),萬一有一個 defect 你沒看到,可能會『不小心』被你的同事找出來。
  • Real customer involvement:開發軟體最可悲的一件事情,莫過於軟體做好了,設計的很漂亮,品質也很好,但是卻不是客戶要的。把錯誤的需求做的很漂亮,還是錯誤的需求,白搭。所以讓 real customer 參與軟體的開發,或是至少和開發團隊有很密切的互動,將可大幅減少這個問題。
  • Daily deployment:平常家裡亂的跟豬窩一樣,突然明天有客人要來家裡,今天晚上才熬夜打掃也來不及。平常都把家裡整理得很乾淨,便可隨時都歡迎朋友到訪。軟體也是一樣,如果是在準備 release 之前才開始考慮『軟體佈署』的問題,那麼很多 defects 此時才會出現而且時間很緊迫可能會來不及在 release 之前修復完成。如果可以『每天都讓開發中的軟體保持可佈署的狀態』,那麼就可以將軟體的品質保持在一定的水準。
有些軟體開發人員終其一生在尋找『銀子彈』,希望能有某種單一方法能夠將 defects 一槍斃命,很可惜這種特效藥還沒被發明。Kent Beck 說:

You can't solve the defect problem with a single practice. It is too complex, with too many facets, and it will never be solved completely. What you hope to achieve is few enough defects to maintain trust both within the team and with the customer.

***

友藏內心獨白:『小三』算不算是一種 redundancy ?



2011年3月15日 星期二

改行寫網路小說算了 (2)

March 15 22:31~23:15

故事一

在某次產品即將發表前的會議當中:

聖上:咱們的『雲端殺豬系統』客戶試用後反應如何啊?

產品經理:啟奏萬歲,有台灣的客戶反應,既然能夠在『雲端殺豬』,何不利用已經殺好的豬,順便加上『雲端燉東坡肉』與『雲端煮滷肉飯』功能,這樣一定大賣的啦。

行銷經理:皇上聖明,根據微臣的調查,『東坡肉』與『滷肉飯』不只在台灣,在中國都有很大的市場,的確是不可忽視的兩項功能。

聖上:看起來這兩項功能真的是不可少喔....工部侍郎 九品工程師,這兩個功能要多久才能加到『雲端殺豬系統』中?

九品工程師:如果『東坡肉』要燉的嫩,『滷肉飯』煮的香,依奴才看要最少也要 6 個月的時間。

聖上:大膽,六個月後那些番邦們早就 打過來了 推出類似產品了... 朕限你 2 個月之內完成,否則依軍法處置。

九品工程師:奴才領旨,吾皇萬歲,萬歲,萬萬歲。

聖上:退朝。

眾臣:吾皇萬歲,萬歲,萬萬歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲.......

***

九品工程師:喂,『醫靈肆』人力銀行嗎,請幫我找 1~2 個會煮『東坡肉』與『滷肉飯』的廚師,這是急件,請在 2 周內找到合適的人才。

醫靈肆:請問該工作的職稱是?

九品工程師:資深雲端廚師。

***
故事二

在某次產品即將發表前的會議當中:

聖上:咱們的『超級柴油汽車』客戶試用後反應如何啊?

產品經理:啟奏萬歲,咱們的『超級柴油汽車』扭力大,爬坡強,客戶反應非常好。但是現在因為『節能減碳』的意識高漲,有很多客戶反應,如果我們的『超級柴油汽車』可以具備『純電力發動』的功能的話,這樣一定 打騙 打遍天下無敵手的啦。

行銷經理:皇上聖明,根據微臣的調查,『純電動車』已經是世界趨勢,在世界各國都有很大的市場,的確是不可忽視的一項功能。


聖上:看起來這一項功能真的是不可少喔....九品工程師,把咱們的『超級柴油汽車』加上『純電力發動』這個功能要多久才時間啊?

九品工程師:啟奏聖上,14 天便可辦成。

聖上:啊,14 天?!好,若能如期完成後朕升你為工部尚書。

九品工程師:奴才領旨,吾皇萬歲,萬歲,萬萬歲。

聖上:退朝。

眾臣:吾皇萬歲,萬歲,萬萬歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲歲.......

***

九品工程師:喂,『瘋甜汽車』嗎?我要買一台 XXX ...有現貨嗎?

瘋甜汽車:很抱歉,因為日本工廠遭遇地震與海嘯,暫時停工,所以沒有現貨。

九品工程師:頑皮,頑皮,推一推....XD

九品工程師:喂,『醫靈肆』人力銀行嗎,我要應徵 YY 公司的『資深雲端廚師』工作。.

***
友藏內心獨白:http://teddy-chen-tw.blogspot.com/2010/06/blog-post_12.html

2011年3月14日 星期一

我不能 run Scrum,因為我家人不同意

March 14 20:40~22:17

在完美的世界裡,Scrum 是這樣玩滴:
  • Product Owner 對於專案所要處理的 problem domain 有多年的經驗,經常與客戶互動並且熟悉競爭對手的產品。Product Owner 腦袋清楚,說話條理分明,懂得事情的輕重緩急,文筆流暢,寫的『一手好 stories』。Product Owner 很有 guts,對外承擔專案成敗的責任,絕對不會把失敗歸咎於 team members。
  • Scrum Master 熟悉 agile methods 與各種 agile practices 的精神,個性樂觀,有很強大的『正面力量』,就算是遭遇到挫折也能夠從失敗中學習並鼓勵隊友。Scrum Master 是一隻很稱職的『看門狗』與『牧羊犬』,保護 team members 不受不相關的人,事,物打擾,而且當 team members 偏移 Scrum 精神(or agile 精神)時可以適時地引導他們回到正軌。Scrum Master 知道如何幫助團隊逐步與持續地改善軟體開發流程。
  • Team members 有著追求卓越的企圖心,有勇氣,誠實,積極主動,樂於互相協助幫忙。Team members 相信管理的最高境界就是『自我管理』,並深信採用 agile methods 來開發軟體將有助於達到自我管理的境界。
以上敘述,了解 Scrum 的鄉民們應該都已經知道了,也希望有一天能夠成為這『理想團隊』的一員。很可惜現實世界是很殘酷的,就好像雖然棒球選手人人都想進入大聯盟『洋基隊』嘗一嘗一秒鐘幾十萬上下的感覺,但是可能偏偏只有『國民隊』對你有興趣,更慘的可能只能到小聯盟或是留在『簽賭聯盟』...XD

***

總之,人生最慘的事之一,莫過於你認識了一位美如天仙或是俊如潘安的女/男朋友,但卻因為『家人反對』或『社會觀感』,最後不能長相廝守。Scrum 也一樣,鄉民們可能不小心知道了 Scrum 這個『東東』,覺的用 Scrum 來開發軟體真是太讚了啦,但是卻因為『父母或是家人反對』(大,小老闆反對或是與不符合公司文化),而導致無緣繼續交往,殘念。

有哪麼嚴重嗎...你說....

當然有,尤其是如果鄉民們是那種『在硬體公司寫應用程式的人』,那就更慘,因為在台灣絕大多數的硬體公司,不管老闆公開說軟體如何重要又如何重要,開發軟體的人永遠都只是『配角中的配角』。想偷偷娶個『門不當,戶不對』的太太(就是 Scrum 啦),門都沒有。

舉幾個最簡單的例子:
  • 老闆說:蝦米是 『死窟窿』?
  • 某大頭說:我不管你們採用什麼 engineering practices,公司有公司的『制度』要遵守,我建議你(Scrum Master)先搞懂公司的『制度』。
  • 這個專案是公司很創新的一個計畫,要做『雲端殺豬系統』,目前世界上沒有人開發過,所以找不到有經驗的 Product Owner 。
  • 既然沒有合適的 Product Owner ,不然你就來當這個 Product Owner 好了。
  • Scrum Master 和老闆吵架當場離職走人,或是
  • Scrum Master 從看門狗『進化』成哈巴狗。
  • Scrum Master 說:什麼是 agile?
  • Scrum Master 說:我叫你先做這個 task 你還不聽! 
  • Product Owner 說:我不管,這些功能三個月全部給我做完。
  • Product Owner 說:客戶試用過我們的『雲端殺豬系統』(其實連 login 都沒有),他們建議要加上『雲端燉東坡肉功能』才要考慮購買。
  • (Sprint 進行到一半) Product Owner 說:A 客戶急著『雲端煮滷肉飯功能』,只要做出來就要買 500 套,趕快三天內做給他。
  • Team Member 說:我昨天在寫程式,今天準備繼續寫程式,沒有遇到問題。
  • Team Member 說:你(Scrum Master)又沒有告訴我這個 task 要先做...
  • Team Member 說:你(Product Owner)需求又沒寫清楚...
  • Team Member 說:為什麼要叫我寫 unit test?
  • 要花多少時間才可以把員工從 cubicle 中拉出來改成『排排坐』?
  • 公司可以接受 Scrum team 的人沒有個別考績這件事嗎?
  • XX主管:人家都用 14" 的 notebook 寫程式,你寫什麼程式要用到 22" 的螢幕?
  • XX主管:別的工程師都買一台兩萬八的 notebook,你們為什麼要用到四萬的?不准!
  • XX主管:用無線鍵盤,滑鼠寫程式會比較快嗎?
  • XX主管:你寫什麼程式要用到 8G RAM?
  • 硬體部門都有沒專屬會議室了,不可能給軟體部門專用的會議室。
***

前幾天日本發生了芮氏地震規模 9.0 的超級大地震並且引發大海嘯與核電廠危機,很多人都在談日本人對於災害應變的規劃做的真是好,要是這麼大的地震發生在台灣,老早就......

是『方法的問題嗎』?是日本人不肯把災害應變規劃跟我們分享嗎?還是我們『不肯被分享』?光有『好對象(好方法)』,『父母觀念不改』,『社會文化不進步』,梁山泊與祝英台,羅密歐與茱麗葉,小龍女和楊過的故事還是會繼續發生滴。

***

友藏內心獨白:『危大路 屁』對白-- Is it good to drink...麥共家綴(別說這麼多),喝看看就知道...

2011年3月12日 星期六

傻的願意相信

March 12 16:33~18:02

Teddy 當年還在唸書的時候當過兩年研究所 OOAD (物件導向分析語設計)課程的助教,其中一項最主要的工作就是 review 學生的作業。老師一共用過兩本教科書,分別是 Craig Larman 所寫得 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (好長的書名)以及 Michael Blaha 和 James Rumbaugh 所寫的 Object-Oriented Modeling and Design with UML。每年的作業都很相似,基本上讓學生自己選一個題目(自行決定 1 人 1 組或是 2-3 人1 組),題目也可以自己決定(找不到題目的人可以跟老師索取參考題目),內容大小以能夠在一學期完成 2 - 4 個 use cases 為限。雖然這門課叫做 OOAD,可是每一位修課的學生不是只有寫寫 use cases,畫畫 UML diagrams 而已,而是包含 coding 和 testing,最後把系統做出來(套用『吃掉你自己的狗食』這個原理,自己的設計自己實做出來才會知道自己設計的有多爛...XD),所以修這門課還滿花時間的。

由於題目是學生自己挑的,因此助教在改作業時就有點辛苦了,因為:
  • 要先弄懂學生所挑題目的那個 domain 
  • 要看學生寫的不清不楚的 use cases 然後還要告訴他們為什麼這樣寫不好
  • Conceptual model 和 design model 也要幫忙看
作業改到後來感覺好像是助教在幫學生做題目...XD...基本上就只有 coding 和 testing 的細節比較沒關注到,其他關於需求分析與系統設計的內容 Teddy 在自己能力範圍內算是盡心盡力幫忙 review 了。有時候還會讓學生們覺的這個學長(就是 Teddy)太『雞蛋裡挑骨頭了吧』,設計本來不就是『這樣也可能,那樣也行』嗎,反正最後我程式寫得出來,軟體可以跑就好了,學長你幹麼管那麼多?

說實話當年 Teddy 內心覺的這些『刁民』真是不知好歹,能找到 Teddy 來幫你們 review  算是你們上輩子燒好香,居然還敢有『悖逆之心』,不好好給我回去重寫作業還在這裡做垂死的掙扎,希望 Teddy 被你們說服....(Teddy 內心獨白:等你們練成了絕地武士的催眠功夫再說吧)

其實基本上這門課的作業其實滿簡單的:
  • 寫出 problem statement 並畫出 context diagram
  • 畫出 use case diagram 並寫出 use cases
  • 畫出系統架構圖
  • 畫出 Conceptual diagram showing concepts with association and
    attributes
  • 畫出 System sequence diagram 並寫出 contracts
  • 畫出 Design class diagram with associations
  • 說明一個設計中最重要的 class
  • 列出 test cases 並說明其中一個最重要的 test method
  • 程式畫面
分四次把上面所列的這些東西在最後學期結束時都學會了,也就及格了。很多學生其實不太能夠適應,或者是說『不相信這一套方法可以 work』,總是有些『自認聰明』的人,覺的自己對於開發軟體『很有經驗』,不必拘泥於書上所講得方法。但是也就是因為如此,這些人很有可能修完課之後,還是對於所謂『OOAD 』方法不了解。

 ***

對於『OOAD 』方法不了解有什麼大不了的,還不是活得好好地。沒錯,說實話 Teddy 現在開發軟體也沒有按照書本中所描述的步驟一步一步慢慢來,但是由於 Teddy 曾經用力花時間去了解這套方法,因此當遇到自己不熟悉的領域,無法靠『直覺』來設計系統的時候,這些在 OOAD 課程所學到的方法就變成一種『參考模式』,用來解決不熟悉問題的參考模式。

Teddy 的指導教授在課堂上常常告訴學生要『傻的願意相信』書上教的方法,自己要先『願意相信』這是可以 work 的方法,嘗試照著去做,而不要在學會之前就先急著去否定這些方法。聽起來好像很簡單,但是要咱們『聰明的台灣人』傻傻的一步一步按照規矩辦事,說真的還真是不太容易。

回到 Teddy 上一篇的主題 『Ten-Minute Build 』,如果今天 Teddy 跑去跟別人講,你的專案要達到 Ten-Minute Build 的要求喔,Teddy 可能會被當作瘋子,因為根本沒人相信。對方可能會說,哎喲,這都是『書本上的說法啦』,你們不懂業界的實況,所以.........

不知道為什麼,Teddy 對於某些人所講的話就特別相信,Kent Beck 就是其中一位,因此當 Teddy 遇到『build 時間太長』這個問題時,就到書上看看 Kent Beck 怎麼說,嗯,他說『Ten-Minute Build 』,Teddy 就先『姑且信之』,於是 Teddy 開始思考一連串所謂的『流程改善』,包括了:
  • 更新 build server。
  • 挑選現有可快速執行的 test cases。
  • 讓 test cases 執行的更快。
  • 想辦法找出此次異動的程式,並只執行受影響的 test cases。
  • .......(其他)

總之這個『Ten-Minute Build 』就是努力的目標就對了,如果繼續抱持著『不相信』的心態,那麼就只會一直維持現狀。基本上 Teddy 所知道的軟體工程知識應該不會比任何一個資工科系畢業的研究生要多太多,很多都是修完軟體工程這門課之後就有的常識,但是 Teddy 『傻的願意相信』的決心可能比很多鄉民要來的強,也許就是這一點小小的信仰驅動著 Teddy 把『理論』慢慢變成『食物 實務』。

 ***

鄉民們可能三不五時會聽到什麼 agile methods,scrum,continuous integration,pair programming,automatic acceptance testing,incremental design,shared code 等等一堆有的沒的名詞,如果真的把它們當成『名詞』,那就真的與你無緣。如果把這些當成『動詞』,也許多多少少能『撈到一些好處』。

想當年 Teddy 聽到 GOMS (請參考 歪批 GOMS (1) )這個作法,第一時間也是覺的『這麼扯的方法怎麼可能用在真實世界的軟體專案?』,但是一旦花點時間去了解之後,身邊又多了一把『小扁鑽』可以使用,偶爾拿出來應付一些特殊場合還是不錯用滴。

 ***

友藏內心獨白:這可能就是日本地震後隆起的柏油路居然比台灣的道路還要平坦的原因...XD...每次想到路平專案 Teddy 就想笑...苦笑...

2011年3月10日 星期四

Ten-Minute Build

March 10 21:06~22:45

和 Teddy 差不多年紀的鄉民們應該還記得當年 SOS (大,小 S)紅遍大江南北的『十分鐘的戀愛 』這首歌:


(下課)十分鐘的戀愛 雖然有一點短暫
你的笑填滿我 心中所有的遺憾
(下課)十分鐘的感情 我將全部屬於你
多希望能夠永遠不分離

可惜做軟體的人沒那麼好命,平平是 10 分鐘,人家可以拿來談戀愛,咱們只能拿來 build 軟體...XD

***

話說當年 Teddy 在讀 Extreme Programming Explained: Embrace Change 這本書的時後,看到第 49 頁寫著某一個 XP 的 primary practices:


Ten-Minute Build
Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.


當時 Teddy 看到這裡其實沒什麼特別的感覺,喔,10 分鐘將整個軟體 build 完畢並跑完全部的測試...了解,收到....轉身後繼續過自己的日子....

好幾個月前聽指導教授說起某開發『倒航 導航軟體』的公司,因為 build 一次軟體要花很久(幾個小時吧)的時間,而且全公司就只有『一個人』知道要如何 build  這個軟體,所以經常會發生 programmers 應觀眾要求『私底下』先把軟體拿給客戶使用(這個客戶是公司內部的員工,需要用這個軟體來建地圖景點資料)。但是曾經發生過員工已經用『私底下版本』的軟體花了幾百個『人/時』來建地圖資料,但是就在『那個人』心血來潮去 build 一下軟體的時候,發現 build 失敗,軟體需要修改,因此導致之前所建立的地圖料要全部重新輸入的情形。

由於這是發生在別人身上的慘劇,聽的人哈哈一笑,總覺的『哪有那麼扯的事』也就沒放在心上,一直到最近 Teddy 聽學弟們提起 build 某個軟體所發生的問題,才慢慢體會到 Ten-Minute Build 這件事情的重要。實驗室有一個軟體全部重新 build 一次需要 15 分鐘左右。鄉民們可能會想『15 分鐘和 10 分鐘差不多啊,已經很不錯了』。錯,因為這 15 分鐘只是去 build 這個軟體並產生安裝程式所需的時間,並沒有跑『test cases』。要是真的去跑 test cases(用 JUnit 寫的 unit tests),可能會超過 2 小時以上。

其實這裡面有很多可以『改善』的地方:
  • 花錢:沒錯,最快的方法就是花錢升級 build server。實驗室的的 build server 的記憶體只有 1 G ,CPU 2.4 GHZ,把記憶體升級到 2G 速度馬上提昇....... 30 秒......有點少...沒關係,如果可以把 build server 升級成新的 i7 電腦應該會快很多。
  • 調整 Build Script:把 build script 寫得聰明一點,例如如果某個 sub-project 以及它所相依的其他 sub-project 如果都沒有異動就不需要重新 build ,或是只測試有異動的程式碼。
  • 調整要執行的 test cases:雖然大家都說『用 JUnit 寫自動化單元測試』,但是嚴格講起來大部分的人所寫的『自動化單元測試』其實都不是『單元測試』,而是大小不一的『整合測試』。因為真正的單元測試要達到『test in Isolation 』,這樣才不會因為『別人帶賽』而導致 test 失敗;而且這樣的單元測試也才能跑得快。所以,在每次 build 的時候,可以先把那些『真正的單元測試』挑出來跑,看看能不能把整個時間控制在 10 分鐘。
  • 電腦上晚班:在人腦下班之後,設定時間自動將整個軟體全部 build 一次並且將那些需要耗時執行的測試案例拿出來跑,這樣可以確定至少每天都有完整 build 一次整個軟體且將全部的測試案例執行完畢
再想想之前上 Certified ScrumMaster 時 Bas 所說的話:『很多專案都因為測試設備不足而導致開發速度無法提昇』,這是一個很簡單的道理,但是否每個老闆都有這樣的認知,願意投入資源在改善『建構』與『測試』的環境就很難講了。

***

友藏內心獨白:該是換電腦的時候了。

2011年3月8日 星期二

這不是 bug,這是功能

March 08 21:38~23:17

Teddy 很小的時候(小學還是國中的時候) 有一天晚上無意中打開收音機,聽到電台在播放『魏龍豪』和『吳兆南』的相聲段子。這相聲是很老的段子,內容和魏龍豪與吳兆南後來重新錄製的不太相同,現在想買也都找不到了,好懷念啊。雖然相聲內容夾雜了很多『北京方言』,並不能 100% 聽得懂,不過當時 Teddy 就覺的怎麼講話可以講得這麼有趣,做人可以做的如此的耍無賴,反正最後結尾時只要加上一句『您別挨罵了』就可以哈哈一笑一筆帶過。從此之後 Teddy 就喜歡上了相聲這個傳統藝術。

但是一直到長大出社會工作之後 Teddy 才逐漸意識到除了『逗觀眾開心』之外,『耍嘴皮』的真正重要性。例如當有人『木工,軟工,傻傻分不清楚 』時,要知道如何當場糾正這種不正確的觀念。『耍嘴皮』到了一個極致,可以顛倒是非,明明是系統的 bugs,你也可以講成這是『系統功能』,講到讓使用者懷疑起自己的智商是否太低而自己先下跪道歉認錯。這種能力,只要看過『烏龍派出所』裡面的『兩津勘吉』唬爛功夫的人應該就能夠了解。

最近 Teddy 見識到一個『行銷手法』就是將『這不是 bug,這是功能』的精神發揮到極致,不得不讓人佩服,講出來跟鄉民們分享一下。話說 Teddy 已經用了四年多的 Mio A701 手機最近常常電話講不到幾分鐘突然就整個關機,明明剛剛電池還顯示有 70% 的容量,怎麼說沒電就沒電。再加上這隻手機之前曾經被 Teddy 摔過,所以螢幕顯示有點怪怪的,常常會整個顏色偏掉變成有點粉紅色的樣子。所以 Teddy 大約在一個多禮拜前上網查了一下 『A去踢西』的新款手機『滴賽兒 HD』的評價,看到兩派的意見:

贊成派:『滴賽兒 HD』真是太強了,有 4.3 吋TFT大螢幕,1G CPU,800 萬畫素相機。

反對派:『滴賽兒 HD』的電池容量太小了啦,4.3 吋TFT大螢幕 + 1G CPU 卻只配被 1200 mAh 的電池,不是一下子就沒電了。

贊成派:『A去踢西』的技術很好啦,採用新一代的 CPU 雖然頻率提高但是更省電喔,所以1200 mAh 的電池容量用起來不會比前一代的『滴賽兒 』1500 mAh 還要差。

反對派:騙肖A,4.3 吋TFT不用吃電喔?很多用過的人都說『滴賽兒 HD』比『滴賽兒 』還沒有『擋頭』。

贊成派:那有什麼關係,人家『A去踢西』可是很貼心的,現在買『滴賽兒 HD』還免費贈送
內含 5000 mAh 電池蕊的行動電源喔,怎樣,5000 mAh,沒話說了吧。

反對派:我花錢買一隻手機不就是應該能夠讓我至少可以撐過一天再充電嗎?4.3 吋TFT的手機已經夠『大隻』了,我為了用這隻手機出門還要隨身帶著一個差不多大小的『行動電源』,現在是怎樣,我口袋太多沒東西可放是嗎?而且講電話講到一半快沒電還要把『行動電源』拿出來使用,電話尾巴接著一個大大的行動電源這能看嗎?

贊成派:哪樓上的這一位是喜歡吃『蘋果派』的人士嗎?看你一直在雞蛋裡挑骨頭,講『A去踢西』的話壞(Teddy 內心獨白:開始搞『省籍情節』)。
***

看完網路上的討論之後 Teddy 內心一驚,恍然大悟,『A去踢西』還真厲害啊,難怪股價可以破 xxxx。如果鄉民們是『A去踢西』的高層,公司的新手機『滴賽兒 HD』因為不明原因電池只能搭配 1200 mAh。因為要趕著上市所以也沒辦法只好硬著頭皮推出,可是只要使用者一買回家就會發現好像吃電太兇了,大大降低方便性,那怎麼辦?!


鄉民們千萬不要『傻傻的』拿出『工程師』的性格,『砍掉重練』,那就完蛋了。反正本來賣一隻手機毛利就很高,那就想辦法『把缺點轉換成賣點』,打出『幾月幾日之前購買就贈送行動電源』的促銷口號不就得了。佩服,佩服,難怪很多公司都那麼重視 marketing... 什麼都可以賣,什麼都不奇怪,把你的錢弄到我的口袋才厲害...XD


工程師們,生命要顧,卡早睡卡有眠,出了事有 marketing 頂著,怕什麼。


***

友藏內心獨白:如果有那種『買一個 D賽 送 4 顆蘋果』的活動 Teddy 應該會參加喔。

2011年3月6日 星期日

HCI 之博士熱愛的算式

March 06 10:57~13:15

幾個禮拜前在 Kay 的推薦之下 Teddy 讀了『博士熱愛的算式』這本書,內容敘述某位數學博士在 1975 年發生的車禍中傷了腦部,他保有車禍發生前的記憶,但在那之後他的記憶只剩下 80 分鐘,時間一到自動 reset。

由於博士『生活無法自理』,所以不用入監服刑,發生車禍之後博士就由他的大嫂(博士的哥哥已經過世)照料。大嫂幫博士請了一位管家照顧他,但是由於博士的記憶只剩下 80 分鐘,所以這位管家對博士而言每隔 80 分鐘都是一位『新人』。博士每天都穿著一件舊的西裝,他在西裝上身上夾滿了『小紙片』,用以彌補他的記憶只有 80 分鐘的缺陷。在眾多的小紙片中,其中有一張畫著管家的素描並註明她是管家這一點事實。

這是電影版的海報(網路上抓的),請注意博士身上的小紙片。關於這一點 Teddy 頗有意見,因為在電影中只是隨便敷衍的夾了幾張紙,可是從小說的敘述中覺的西裝上應該是『夾滿紙片』才對。此外,電影中的博士看起來也太年輕了一點(小說中的博士應該是有點駝背之類的),而管家也長得太可愛了吧,感覺有點像女僕而不是管家...XD



有人說這本書是『數學科普小說』(這是什麼東東?),Teddy 數學極爛所以並不想要介紹這本書和數學有關的內容,因此關於本書的背景說明到此就夠了。 今天的重點還是要延續 『Designing for Error (3):knowledge in the world and in the head 』這個主題,談談 knowledge in the world and in the head 。

***



上面這張圖節錄自 e-Learning and the Science of Instruction 這本書第 35 頁,原本是在解釋地球人如何學習知識的心路歷程,在這邊借來說明人機互動的設計原則。概念其實很簡單:
  • 人的記憶體區分為『long-term memory』和『working memory』。Long-term memory 類似電腦的硬碟(永久記憶體,關機之後不會消失)容量大但是存取速度慢,而 working memory 類似 RAM (揮發性記憶體,停電或關機之後資料會消失)容量小但是存取速度快。
  • Working memory 的容量是有限制的(請不要說你家的電腦有 512 GB 的 RAM,就算是 512 GB RAM 和硬碟相比也還是『有限』...)。一般常聽到的『7 +- 2 原則』(人的短期記憶可以記住 7 +- 2 個東西)就是指 working memory 的大小(Teddy 內心獨白:還真小)。
  • 視覺和聽覺的資料經過眼睛和耳朵接收之後進入 working memory。
  • Working memory 的資料經過處理之後儲存到 long-term memory ,變成人的 mental models 的一部分。
知道這幾點就差不多了,現在回頭看看一個 HCI 設計原則:不要讓我花腦筋
 
假設使用者在執行『員工個人資料維護系統』,在該系統的畫面上有兩個按鈕,分別是『存檔』與『列印』這兩個功能。鄉民們是設計這個系統的 programmer,當初你為了『code reuse』,把所有執行成功的訊息寫成一個公用對話盒,所以當使用者執行『存檔』或是『列印』功能的時候,畫面都會出現相同的『執行成功』這個訊息。

問題來了,畫面上有『存檔』與『列印』這兩個功能,但是不管執行那一個功能所顯示的訊息都一樣,都是『執行成功』,那萬一使用者恍神要存檔卻不小心按成列印,而程式卻又告訴使用者『執行成功』,那怎麼辦?

切,鄉民們會說,這有什麼好大驚小怪的,又不是飛航系統,按錯又不會死人。但是想一下:
  • 使用者以為存檔完成但是卻是把資料印到『公用印表機』而不自知,所以使用者也不會去印表機前拿資料。如果這些員工個人資料有包含薪水或是退休金提撥(可以反推薪水)等資料被其他人拿走,那就不太好了。
  • 使用者以為資料已經存檔完成,此時使用者電腦突然當機。下次使用者再進入『員工個人資料維護系統』之後,發現自己的資料怎麼還是舊的?會以為軟體功能有問題或是被駭客入侵而回報一個 bug,結果查了老半天才發現是自己的 腦袋有問題 操作疏失。
所以,如果有好好應用 put the required knowledge in the world 這個原則,那麼這個訊息就要改成『存檔成功』和『列印成功』。不要把『請自己記住你剛剛執行了什麼功能,按了什麼按鈕』的責任丟到使用者的身上(Don't require all the knowledge to be in the head.)。

因為 working memory 容量有限,所以如果沒有善用 put the required knowledge in the world 這個原則所設計出來的介面會增加使用者小腦袋的負擔。更慘的是,有些使用者介面操作的習慣和人們一般的認知不同或是相反,這種介面還會增加使用者的 mental loading,每次操作這種『與自己認知不同』的功能時都要『花腦筋』想一下。大部份的人應該都同意『花腦筋』是一件很累人的事情,所以看『夜市人生』與『海綿寶寶』的觀眾群才會遠大於看『Discovery』的人...XD。總之,需要讓使用者經常『花腦筋』的介面用久了會有種『身心具疲』的感覺,而且容易出錯。舉個例子,在台灣開車駕駛座在左邊,對駕駛而言這已經是一種『習慣』,但是如果要右駕的國家例如日本或是英國開車,雖然同樣都是開車,所需要技能基本上是一樣的,但是剛開始開車的時候通常會很緊張,時時提醒自己轉彎的時候方向不要搞錯(增加 mental loading),使得原本很輕鬆的開車之旅變成很『用力』的開車之旅。

再舉個例子,Teddy 平常工作的時候用到兩台電腦,透過 KVM 來共用一組鍵盤,螢幕,和滑鼠。這個 KVM 可以透過 Scroll Lock + Scroll Lock + [1, 2, 3, 4] 來切換到不同的電腦(這是一個 4 ports 的  KVM),但是很奇怪的一點,有時候 (不是每一次)Teddy 按下 Alt + Tab 的時候,KVM  也會切換到不同的電腦。由於 Teddy 老早就習慣用 Alt + Tab 來切換不同的應用程式(Windows 和 Linux 上都是用這組熱鍵),但是這個該死的 KVM 不知為什麼有時候會把 Alt + Tab 當成是要切換到不同的電腦的信號,Teddy 讀了手冊也看不到 KVM 有提到這一點,也不知道這是 KVM 的 bug 還是功能。總之每次當 Teddy 反射性的要按下 Alt + Tab 切換應用程式的時候,就被迫要『動一下腦筋』提醒自己改用其他方式切換應用程式。有時候忘了還是使用 Alt + Tab ,就要再手動切換回剛剛正在操作的那台電腦,次數發生多了還真是挺不爽的。

***

回到博士熱愛的算式,出車禍之後博士已經失去增加 long-term memory  資料的能力,而且他的 working memory (short-term memory)每隔 80 分鐘就會消失(每隔 80 分鐘重新開機),怎麼辦?沒有辦法 put the required knowledge in the head 那只好 put the required knowledge in the world(寫在小紙條上),日子還是過的下去。


***

友藏內心獨白:要買到一台好用的 KVM 還真難,不是無線滑鼠不能用就是切換熱鍵有問題。

花博吃破產

March 05 23:13~ 06 00:37

今天是 Teddy 第三次去花博,嚴格講起來是第四次,不過上禮拜六那一次到了新生園區門口看到排隊入園的人嚇了一大跳後來決定不入園了,所以那次就不算(廢話,又沒進去當然不算)。

時間有點晚,直接講重點:

入園方式

由於上禮拜見識到新生園區入園的龐大陣仗,此次改由員山園區入園(之前去過還滿快的)。約早上 8:30 左右到達員山站,人已經滿多的。不過 9 點開放入園之後幾分鐘之內就進園區了,之後邊小跑步邊走到美術園區去拿故事館預約券,拿到 16:30 分的。然後走 花枝 花之隧道(今天一共走了四次)到新生園區去拿養生館預約券,拿到  10:00 的。這個養生館預約券真是超好拿的,幾乎不用排隊馬上拿到。附註說明,真相館和名人館 Teddy 第二次逛花博已經去過了,而夢想館則是完全放棄,所以可以拿的預約券今天全部拿完。


 快 9 點的時候 Teddy 往後一看,天啊,後面好多人在排隊啊,早個 30 分鐘到還是很有用的。

 入口處有原住民朋友的表演


行程表

養生館附近亂逛 --> 養生館(盆栽很好看)-->青青步道(排隊約 10-20 分鐘,view 很棒)--> 隨便亂逛 -->花茶殿吃午餐(人很多要先找位置,簡餐 150 元附一杯飲料,湯自取,還算 OK)--> 隨便亂逛 & 休息 -->美術館喝下午茶 (坐在凸出來的位置,屋頂是玻璃沒有遮陽,冷氣也不冷,差點中暑)--> 跑去美術館內休息 --> 故事館 (很多古董家具,小而美,館內不可拍照) --> 台北故事茶坊吃晚餐(東西好吃但是有點貴,服務很好加收 1 成服務費) --> 美術館看莫內畫展...的紀念品販賣區... --> 未來館 & 天使生活館  --> 回家

這張是晚上照的,Teddy 就是坐在凸出來那一塊吃下午茶,當時可是有小太陽滴


不信的話看這張照片就知道了,花博地圖另類用法



重要資訊

  • 早上看到排隊進未來館的人超多,看來至少都要等 1 小時以上。後來 Teddy 不小心偷聽到某位現場鄉民對他朋友說:『等到晚上 7 - 8 點來都不用排隊,1 分鐘就可以入場』。嘿嘿,打聽到重要資訊,懶的排隊的 Teddy 當然是等到晚上再來。
  • 美術館週六入館看一般展覽不用錢(這一點之前 Teddy 就知道了)
  • 台北故事館的『楊桃』已經熟透了,有些都掉下來了。
  • 在台北故事館旁的台北故事茶坊好像是亞都麗緻經營的。
  • Teddy 在台北故事茶坊刷卡結帳之後,對方還對 Teddy 說:『陳先生,謝謝』之類的話。 耶,他怎麼知道 Teddy 是陳先生...很簡單啊,因為信用卡上面有寫啊。這不是重點,重點是 Teddy 覺的台北故事茶坊的員工滿專業的,在一些小地方都留意到顧客的需要或是給顧客一些小小的感動(Teddy 也是略懂 one-to-one marketing 滴)。

還想再去

雖然台北故事茶坊對於 Teddy 這種窮忙族而言是有點昂貴(請看帳單),但是用餐環境真的滿好的,東西也好吃,服務又棒。所以,如果哪一天鄉民們突然想要奢侈一下,這個餐廳還不錯。

請注意這份菜單,有放菜色的照片,有達到『knowledge in the world』的要求喔。


心好痛


可以看到台北故事館



Kay 單點的松露拌麵


晚餐套餐的麵包

套餐前菜:桂花梅香鮮蟹盅

套餐例湯:玉米濃湯

套餐主菜:慢燉奶油野菇梅花排

套餐飲料:冰紅茶

套餐飲料:烤布雷

晚上的故事館(左方)打燈之後還滿漂亮的,右邊就是台北故事茶坊

***

友藏內心獨白:去看花博怎麼沒有花的照片?

2011年3月3日 星期四

Designing for Error (5):execution and evaluation

March 03 21:39~10:52

終於到了 Designing for Error 這個系列最後一篇(希望是),不知道有沒有鄉民已經等在 電視機 電腦前面等著收看這一集的實況轉播,每天寫也是會累滴。

Teddy 記得在『美味關係』這部電影裡面,女主角之一的『茱莉鮑爾』立志用一年的時間,每天都要按照『掌握法國烹飪藝術』這本食譜上的菜單親自做菜,並把做菜的心得發表在自己的部落格上。等 Teddy 自己開始認真寫『搞笑談軟工』之後才發現,這怎麼可能,每天要『擠料』出來可是很傷腦細胞的一件事。就算是腦細胞撐的下去,每天打那麼多字,手腕,手肘和肩膀也會受不了(路人甲:Teddy 你好弱喔...)。

言歸正傳,今天要談的是 The Psychology of Everyday Things (p. 140)對於 Designing for Error 的總結,一共有三個重點,今天談第三個重點: 

Narrow the gulfs of execution and evaluation. Make things visible, both for execution and evaluation. On the execution side, make the options readily available. On the evaluation side, make the results of each action apparent. Make it possible to determine the system state readily, easily, and accurately, and in a form consistent with the person's goals, intentions, and expectations.

這一點應該是很容易理解的(雖然並不見得容易做到),舉的例子先。假設你想要趕流行學人家『霸凌同 事』(PS:叔叔有練過,小朋友不可以學喔),於是有一天上班你帶了一根棍子到公司,遠遠看到被霸凌對象迎面而來,此時你高高舉起手上的棍子往對方頭上猛 K 下去。以上動作叫做 execution,你事先擬定了一個霸凌同事的『目標 (goal)』,為了達到此目標,你選擇了用『棍子猛 K 對方』的個作法(method),當看到對方之後,你採行一連串的行動(operators)以便達到此目標。啊,一不小心又 GOMS 上身了...

K 完一棒之後就沒事了嗎?當然不是,因為在採取行動(execution)之後你還必須要評估一下行動是否成功(evaluation)。按照常理推斷,對方被你 K 了一棒之後,應該要一邊用手摸著被 K 的地方,同時發出一聲慘叫外加大聲重複背誦三字經。如果這些事件都發生了,你就可以確定此次的霸凌成功,否則就是失敗。

***

On the execution side, make the options readily available. On the evaluation side, make the results of each action apparent 是避免使用者操作錯誤相當有用的方法。翻成白話文就是,在設計介面時,對於使用者可以操作的功能有哪些選項要清楚的表達出來。例如,如果一個檯燈用的是『省電燈泡』,只有『開』和『關』的功能(不能調亮度),那麼這個檯燈的開關就應該設計成只能『開』和『關』。


採用 on/off 開關

execution side(開關) :           evaluation side(電燈):
on                                                            亮
off                                                            暗
 
如果開關設計成可以調整亮度(鎢絲燈泡)的那種旋鈕開關,那麼就會很奇怪了。為什麼奇怪?因為:

採用旋鈕開關開關


execution side(開關) :           evaluation side(電燈):
往右轉到最底                                            亮
往左轉到最底                                            暗
非上述兩個狀態                                         沒反應

就沒有達到 make the results of each action apparent 這一點要求,也就是說使用者明啊明就有做了某些動作,但是卻沒有觀察到任何反應。以剛剛霸凌的例子來講,原本 K 了一棒就要快閃,受害者痛一下也就沒事了,但是萬一好死不死這個受害者硬撐不喊出聲音來,你可能以為沒 K 到或是 K 的太輕,於是卯起來連續 K 了 100 下,一直到受害者真的不可能再有任何反應為止....這是很恐怖滴...所以....伊...想哭不要硬撐。
 
***

Execution and evaluation 的例子很多,平常經常看到的 progress bar 就是讓使用者知道他剛剛執行的動作(execution)的狀態(evaluation)。或是當使用者按下『確定交易』的按鈕之後,系統回覆『交易成功』也算。想一想,如果一個系統只有 execution(提供使用者操作否個功能的介面)而沒有 evaluation,這樣的系統是很難被正確使用的。

Teddy 最近就遇到一個慘痛的經驗,Teddy 公司和家裡的電腦都安裝 Ubuntu 作業系統,因為工作的需要經常會用到 Skype 來 聊天 談公事和傳輸檔案。還好 Skype 有提供 Ubuntu 版本,雖然有一些小問題,不過大致還堪用。

有用過 Skepe 的人都知道當你傳輸檔案給對方的時候,Skype 會跳出一個『檔案傳輸對話盒』(如下圖所示),讓你知道目前傳輸檔案的進度。不知道為什麼,在 Teddy 的電腦上有時候這個『檔案傳輸對話盒』就是不會出現。明明對方都已經接收到檔案了,Teddy 還以為檔案沒有傳出去(因為沒有得到任何 feedback 所以無法 evaluate 剛剛的檔案傳輸動作是否有正確執行)。有一次同事就問 Teddy,同一的檔案幹麼連續傳 10 幾次給他,此時 Teddy 才發現這個問題。



***

節目到這邊已經接近尾聲,鄉民們應該會發現其實這些 Designing for Error 的方法都很簡單,看起來也沒什麼學問。沒錯,這本書好就好在這裡...因為大部分都看的懂,所以看完之後有『自我感覺非常良好』。但是別忘了『知易行難』的道理,意思懂了不代表應用到實際設計上的時候都還記得這些道理。好里加在好心的 Teddy 把這些重點幫鄉民們記錄下來(鄉民甲:有重點嗎?!),上班上到腦袋空空的時候來逛一下,久而久之就不會忘記了。


***

友藏內心獨白:K 人的例子會不會太暴力一點...

2011年3月2日 星期三

Designing for Error (4):constraints, forcing functions, and natural mappings

March 02 22:27~23:49


The Psychology of Everyday Things (p. 140)對於 Designing for Error 的總結,一共有三個重點,今天談第二個重點: 


Use the power of nature and artificial constraints: physical, logical, semantic, and cultural. Use forcing functions and natural mappings.

利用強加『限制(constraints)』的方式來避免使用者犯錯是一個常見的作法。什麼叫做強加限制?最簡單的一個例子,『時速限制』。因為怕開車開太快容易發生車禍(等於產生 errors),因此政府對不同的路段設計不同的時速限制,這就是 constraints。Constraints 聽起來雖然感覺是一個『負面』的字,因為它限制了使用者『任意使用』某物品的自由,但是往好的方面想,它也減少了使用者犯錯的可能。

路人甲:但是還是很多人超速啊!?

Teddy:自然有法律會去制裁他。
 
不知道鄉民們去 ATM 領錢的時後有沒有注意到,當選完要領的金額數目之後,ATM 會問你『是否要繼續交易』,如果選否,則 ATM 會把提款卡會先退出來。除非你把提款卡拿走,否則 ATM 是不會把錢吐出來的。相信大部分的人不會忘記要拿錢 只會忘記拿帳單,因此這種順序上的限制(先拿卡再拿錢)可以避免使用者忘記拿走提款卡的機率。想一想,如果反過來,先拿錢再拿卡,應該會有很多人一拿到錢太高興了就把提款卡給忘了。
 
***

看到這裡鄉民們應該會問,什麼是 forcing functions?依據書上的解釋(p. 132):

Forcing functions are a form of physical constraint: situations in which the actions are constrained so that failure at one stage prevents the next step from happening. 

書上介紹有三種 forcing functions (p. 135):
  • Interlock:An interlock forces operations to take place in proper sequence。舉例說明之,如果使用者在微波爐啟動的時候不小心把微波爐的門打開,那麼微波外洩可是很危險滴,據江湖傳言輕則導致不孕(開爐自宮)或是變成盲劍客,重則有生命危險。因此,微波爐就被設計成『只要門一打開就停止運轉』,或是說『只有在門關起來的時候才可以運轉』。回頭再讀一次 interlock 的定義:一個 interlock 強制某些操作只能在特定的順序之下才可發生。『先關門-->後啟動』就是一種『特定順序』,如果違反此順序(限制)則該操作(啟動微波爐)就沒有作用。鄉民們使用微波爐的時候不知道有沒有想到如果沒有這個 interlock 可是『祝恐怖』滴...搞不好微波爐就變成:「好微波爐!微波爐的奧妙之處,在於它可以藏在民居之中,隨手可得,還可以假裝做菜或是加熱食物來隱藏殺機,就算被警察抓了也告不了你,真不愧為七大武器之首!」(Teddy 內心獨白:萬一停電不就沒搞頭了...XD)
  • Lockin:A lockin keeps an operation active, preventing someone from prematurely stopping it。想像一下你正在使用 Microsoft Word,文件編輯到一半突然不小心『手ㄎㄟˊ』 去按到『關閉』功能。萬一 Word 真的傻傻的就直接離開,不帶走一片雲彩,那麼你剛剛所打的那一堆資料就真的是『悄悄的來,又悄悄的走』。還好文書編輯軟體都針對『如果有尚未存檔的文件,在結束程式之前必須要讓使用者再次確認』的機制,也就是 lockin 所要達到的 keeps an operation active, preventing someone from prematurely stopping it(讓 Word 繼續活著,除非使用者確定不儲存未存檔的文件)。
  • Lockout:A lockout device is one that prevents someone from entering a place that is dangerous, or prevents an event from occurring. 鄉民們應該有看過類似『惡靈古堡』這類的電影,就是某個研究病毒的機構,有一天突然不小心病毒外洩,此時電腦自動『關門放狗』(放下安全門),不讓任何人進入受到污染的區域(prevents someone from entering a place that is dangerous)。當然,萬一不幸你是那一個處在污染區域的人,那你就被『lockin』關禁閉直到變成 薑絲 僵屍才出得來...XD
***

最後談談 natural mappings,舉一個最簡單的例子,假設鄉民們家裡有五盞電燈,位置排列如下。
 
電燈1     電燈2     電燈3     電燈4     電燈5   
 
如果電燈開關排列的位置和電燈的位置一樣(如下所示),那麼開關電燈的時候就不容易搞錯。為什麼,因為控制端與被控端有著 natural mapping
 
開關1     開關2     開關3    開關4     開關5

但是,如果開關排列的位置長成這樣子:

開關3     開關5     開關1    開關2     開關4
 
那麼每次開電燈都要搞得像是『樂透開獎一樣』,能猜中還真不容易。

***

友藏內心獨白:電影裡面還真的有用微波爐來殺人的情節,難道是破壞了 interlock?


2011年3月1日 星期二

Designing for Error (3):knowledge in the world and in the head

March 01 21:16~22:36


今天談一下 The Psychology of Everyday Things (p. 140)對於 Designing for Error 的總結,一共有三個重點,分三次介紹。 


第一個重點:


Put the required knowledge in the world. Don't require all the knowledge to be in the head. Yet do allow for more efficient operation when the user has learned the operations, has gotten the knowledge in the head.

相信鄉民們都有到餐館點餐的經驗,不管是中文或是英文的菜單,有時候光從『菜名』還真不知道這道菜的『組成份子』是什麼東東。什麼『貓耳朵』,『螞蟻上樹』,『青龍皮皮挫』,沒吃過的人還以為這菜裡面真的有『貓』『螞蟻』和『青龍』。但是,如果菜單上面有照片,再加上適當的文字說明那麼就比較容易了解。所以這本書建議在設計使用者介面(任何物品)要 put the required knowledge in the world,以上面這個例子,菜單的照片,文字是了解這些奇怪菜名的 required knowledge,因此要將這些資料放在菜單上面(the world, 你要操作的那件物品)。如果在待操作的物品上(菜單)缺少這些資訊,那麼除非客戶的腦袋中(the head)已經有了這些點菜的必要知識,否則點錯菜是必然的。


當然,對於經常上館子的老饕,不需要看菜單也能點菜。因此把每道菜的照片和說明放在菜單上並不會限制老饕點菜的速度 (do allow for more efficient operation when the user has learned the operations)。

在這邊穿插一個真人真事,話說某人到美國出差,放假的時候和同事出去玩。到了用餐時間,到某間餐廳點餐,由於大家都看不懂菜單,於是某人想到一個安全的點菜方法,就是不同種類的餐點都各點一份。當他點好菜之後,服務生面有菜菜色的和他再次確認。結果,最後上了四道菜... 全部都是『湯』。因為某人點了四道套餐所附的湯。

要怪誰?依照 The Psychology of Everyday Things 的思考邏輯,當然不能苛責某人啊,要怪就怪餐廳的菜單設計的太爛了啦,不 user friendly。
 
***

再舉一個軟體的例子,Microsoft Word 和 OpenOffice 都有一個『選擇性貼上』的功能,可以把,例如從網頁或是其他文章段落中所 copy 下來的文字以『未格式化文字(純文字)』的方式複製到 Word 或是 OpenOffice 中(這個功能 Teddy 經常使用)。為了做到『put the required knowledge in the world』,這些軟體允許使用者透過 Edit-->Past Special... 的方式來執行此功能。同時,為了 『do allow for more efficient operation when the user has learned the operations』,OpenOffice 支援 Ctrl+Shift+V 這組熱鍵執行『選擇性貼上』的功能。很可惜的是,Teddy 在 Microsoft Word 中反而找不到這相對應的熱鍵,所以單就這個功能來看,Word 並沒有做到『do allow for more efficient operation when the user has learned the operations』這一點。


Teddy 用 『歪批 GOMS』所介紹的方法來分析一下在 Word 中要執行此功能所需要的步驟:

method 1:在 Word 中用滑鼠執行選擇性貼上

  • 移動滑鼠到『編輯』menu 上
  • 按下滑鼠左鍵
  • 移動滑鼠到『選擇性貼上』這個 item
  • 放開滑鼠左鍵 (此時 Word 彈出一個選擇性貼上對話盒)
  • 移動滑鼠到選擇性貼上對話盒上的『未格式化文字』上
  • 按下滑鼠左鍵
  • 放開滑鼠左鍵
  • 移動滑鼠到確定按鈕上
  • 按下滑鼠左鍵
  • 放開滑鼠左鍵
需要 10 個 operators

Word 主畫面

選擇性貼上對話盒(Word 畫面)


如果在 OpenOffice 上用熱鍵就簡單多了。

method 2:在 OpenOffice 中用熱鍵執行選擇性貼上

  • 按下 Ctrl+Shift+V
  • 放開 Ctrl+Shift+V


只需要 2 個 operators,就算是把 Ctrl, Shift, V 當成 3 個 operators,按下與放開這三個鍵也只需要 6 個 operators,比在 Word 中用滑鼠還少 4 個 operators。當你在編寫文章而需要經常使用『選擇性貼上』這個功能的時候,你就會發現『do allow for more efficient operation when the user has learned the operations』這一點的重要性了
 
OpenOffice 主畫面

 ***

友藏內心獨白:這麼一來,是不是說如果介面設計的好,就算是『使用者的腦袋裝大...便當一個只要50塊...』也沒有關係嘍?!