Designing for Error (2)

Feb. 27 21:32~22:58

昨天談到 The Psychology of Everyday Things （p. 131）提到的四點 Designing for Error 作法：

• Understand the causes of error and design to minimize those causes.

了解錯誤發生的根本原因，在設計時盡可能避免這些錯誤發生。換句話說，這是 error prevention。一個最簡單的例子，如下圖所示，用行事曆的 UI 讓使用者選擇一個日期，這樣可以避免使用者打出 2011/02/29 這種不存在的日期。這個方法方法聽起來好像很簡單，如果有點年紀的鄉民們回想一下，在 Web 才剛剛流行的那個年代，透過網頁輸入『日期』的資料，大多還是只提供一個 text box 讓使用者自行輸入類似『2011/02/29』的期，或是三 text box 讓使用者自行輸入年，月，日。這種作法持續了一段時間，後來才有用 javascript 做的行事曆元件可用。所以，雖然『Understand the causes of error and design to minimize those causes』可以算是常識，但是在設計使用者介面時常常因為種種原因很容易被忽略。

• Make it possible to reverse actions- to "undo" then - or make it harder to do what cannot be reversed. 

既然犯錯是難免的，如果有『月光寶盒』或是『時光機』可以回到過去『修正』自己所犯的錯誤，修正之後錯誤就不存在啦。換句話說，這是 error recovery。最常見的例子就是文書編輯軟體都有提供的無限次數 undo 功能，因為有了這個功能，使用者可以『無罣礙的（放心的）』編輯文件，反正萬一改錯了，只要 undo 就可以回到上一個狀態了。如果人生也能有 control+z 該多好。

如果有些操作和人生一樣是無法 undo 那該怎麼辦？例如，鄉民們使用網路 ATM『轉帳』，網路 ATM 軟體人總不可能提供 undo 功能，讓鄉民們們在『不小時把錢轉給詐騙集團時』可按下 undo 按鈕吧。雖然這個功能聽起來很不錯，不過『轉帳』是不可逆也不可以 undo 的，而且不小心轉錯會『很傷』，因此，當使用者執行這類的功能時，軟體都會『再三提醒』，這也是這個作法第二部份所說的 make it harder to do what cannot be reversed。

• Make it easier to discover the errors that do occur, and make them easier to correct.

如果錯誤無法從根本上（在設計的時候）避免，那麼至少要能夠想方法讓『偵測錯誤』與『修復錯誤』變的簡單一點。舉個車子的例子，車子製造商無法用設計的方法『避免』使用者『忘記加油 （對車子而言這沒油了是一種錯誤）』，所以，他們設計了『油量指示表』，而且主動在『油量只剩下 10% 的時候亮紅燈或是發出 BBB 警告聲』（ discover the errors），如果車子有 GPS 此時能夠自動結合 GPS 告訴車主最近的加油站在哪裡那就更棒了（make them easier to correct）。

再舉個軟體的例子，假設鄉民們正使用 Eclipse 用 Java 在寫程式。大家都知道，『寫程式是一件超級容易犯錯的工作』，Eclipse 的設計者如何幫助使用者（就是你）來 discover the errors 而且 make them easier to correct？人家想出了 quick fix 這個超讚的功能。以下圖的程式範例為例，Eclipse 偵測到一個語法錯誤（main method 遇到一個 checked exception 但是沒有 catch 或是 declare 這個 checked exception），在錯誤發生的那一行的左邊顯示了一個小X icon 稱之為 marker（以上是 easier to discover）。接下來是 easier to correct 的作法，當使用者按下這個小X icon 之後，Eclipse 顯示建議修改方案（resolution），使用者點選合適的修改方案 Eclipse 便自動幫忙修復這個錯誤。

當年 Teddy 曾經研究過 Eclipse 的 quick fix 機制，大體上就是：

• 利用 visitor 去拜訪 Eclipse JDT （Java Development Tools）所建立的 AST (Abstract Syntax Tree)。Error detection 的邏輯就是寫在 visitor 裡面，plug-in 的開發者可以自行擴充新的 visitor 以便加入自己的錯誤檢查邏輯。
• 當發現錯誤時，產生一個 麵包屑 marker 用以標示錯誤發生的『位置』（程式行號）。
• 針對不同種類的 marker，plug-in 開發者提供自定的 resolution（解決方案）以協助使用者排除錯誤。由於 marker 是 plug-in 開發者依據『自訂檢查錯誤邏輯』所產生的一個『錯誤標記』，因此如果此錯誤『存在可能的解決方案』的話，plug-in 開發者自然可以事先提供 resolution 來協助使用者排除問題。當然，有時後這些 resolution 並不一定合用，需要使用者自己動手修改。

說真的，對於使用者而言，如果一個軟體系統有提供這種 quick fix 的貼心功能，真的是很方便。不過，要設計出這樣的功能是需要多耗費一點精神滴，對於各位加班加到暴肝的鄉民們而言，沒事應該不太想嘗試吧（Teddy 內心獨白：要向上提昇啊...）。

 

• Change the attitude toward errors. Think of an object's user as attempting to do a task, getting there by imperfect approximations. Don't think of the users as making errors; think of the actions as approximations of what is desired.

最後這一點用書上的一段話來解釋並做本篇結尾 (p. 131)：

When someone makes an error, there usually is good reason for it. If it was a mistake, the information available was probably incomplete or misleading. The decision was probably sensible at the time. If it was a slip, it was probably due to poor design or distraction. Errors are usually understandable and logical, once you think through their causes. Don't punish the person for making errors. Don't take offense. But most of all, don't ignore it. Try to design the system to allow for errors. Realize that normal behavior isn't always accurate. Design so that errors are easy to discover and corrections are possible.


以上四點以及上面這一段文字念個幾十次對於 designing for error 就會慢慢有 fu 了...

***

友藏內心獨白：好久沒翻這本書了，都快忘了這本書寫得有多好。

HCI 分類開張: Designing for Error (1)

Feb. 26 22:24~23:36

雖然不是 HCI 專家，但前兩篇（窮人 HCI 設計入門 ，歪批 GOMS (1) ） Teddy 剛好談到這個主題，剛剛在『擠料』的時候，就想那乾脆把 Teddy 所知有限的 HCI 『小扁鑽』介紹給鄉民們好了，順便幫 Teddy 的部落格建一個 HCI 分類，把前兩篇文章從『軟工』移到『HCI』這個分類。

***

今天談談『使用者犯錯』這個問題（大哥內心獨白：我犯了全天下男人都會犯的錯誤），1-2 年前在 Discovery 上看到一個節目，討論英國某航空公司發生空難的案例。內容大概是該航空公司的某架飛機駕駛艙前方（或側面，有點忘了）的『玻璃』在飛機飛行中突然整片飛出去，導致飛機在高空中失壓。事後調查結果發現，該飛機在前天晚上才剛剛執行過一次例行的保養。為了避免『金屬疲乏』，技師才全部更換過用來鎖住玻璃的『螺絲』。最後的調查結果發現，是這些『螺絲』出了問題，因為它們的『size』不合... 小了一號（可能只差了 0.01 公分之類的）。

為甚麼『螺絲』會小一號？是買到『山寨版螺絲』嗎，還是用到『瑕疵品』，亦或是原廠裝貨的時候搞錯了尺寸？。都不是，原因是因為技師沒有依照『標準流程』拿取『螺絲』。『標準流程』規定要跟換螺絲時，要先去翻閱技術資料，確認飛機型號與其所使用螺絲的產品編號，然後在到領料處依據個產品編號來找出所要更換的螺絲。

如果這件事情發生在寶島台灣，鄉民們認為應該如何『處置』這位技師？

• 人肉搜索，把他的祖宗八代的資料全部公佈在網路上。
• 偷懶不按標準流程做事，危害飛安，抓起來槍斃...XD。
• 找一群名嘴在政論節目中連續痛罵他三天，並開放『當事人澄清專線』讓他 call in 為自己辯解，之後在繼續狠批他的辯解。

還好這個事件是發生在英國，這位技師安然保存住性命。言歸正傳，為什麼技師不依據『標準流程』辦事，經過後續的調查發現：

• 該技師已經有多次換過同型飛機的『螺絲』的經驗，因此他自認為不需要在逐一確認詳細的飛機型號與螺絲編號。
• 該技師平常的工作量相當大，而且當天已經工作超時了（hT嘻，看到沒，工作超時是很危險滴）。在更換那架飛機螺絲的時候（當天最後一項工作），已經是深夜了，他想儘快完成後回家。
• 因此，技師就把舊的螺絲拆下，拿到庫房去，用『肉眼』比對找出大小一樣的螺絲。沒想到這些新的螺絲肉眼看起來雖然和舊的一樣，但是實際上卻小了一點點。
• 原本這一點點的差異並不會造成問題，巧就巧在飛機駕駛艙前方鎖住玻璃的那塊金屬已經有一個肉眼看不到的細小裂縫，在高空因為壓力，溫度等問題，最後造成整片玻璃脫落。

最後，航空公司並沒有特別懲罰該名技師，反而是檢討公司原本維修飛機的流程，來避免問題再次發生。

***

路人甲：這和 hT嘻 HCI 有何關係？

想一下，身為 developers，當有人向你回報說：『客戶操作我們的軟體，出現了 xxx 錯誤...』，你的典型反應可能是：『客戶不會用啦，都沒在看使用手冊的』，『這個地方我上次就告訴他要注意了啊，怎麼又犯錯了』。這些當然是很方便的回答，不用改任何軟體，反正就是客戶白爛就對了，叫他們回家深切反省並好好 讀書 讀手冊。也許有些情況下的確是如此，但如果總是以這樣的心態來思考客戶的問題那麼軟體就不可能『進步』（Teddy  內心獨白：使用手冊有寫這句話最近 Teddy 也常常掛在嘴邊...XD）。

軟體（或任何設計）應該要 Designing for Error，具體的作法在 The Psychology of Everyday Things （p. 131）這本書有提到。

• Understand the causes of error and design to minimize those causes.
• Make it possible to reverse actions- to "undo" then - or make it harder to do what cannot be reversed.
• Make it easier to discover the errors that do occur, and make them easier to correct.
• Change the attitude toward errors. Think of an object's user as attempting to do a task, getting there by imperfect approximations. Don't think of the users as making errors; think of the actions as approximations of what is desired.

明天要早起，有人在催 Teddy 準備就寢了，就先寫到這裡，明日繼續。重點是，心態轉變，『問題（錯誤）』也可能變成改善的好朋友。

***

友藏內心獨白：不思考問題發生的原因並從根本加以改善，直接把犯錯的人弊了還是無法根絕問題。總不能把 2千300萬人都弊了吧...XD

歪批 GOMS (1)

Feb. 24 22:25~23:46

昨天在『窮人 HCI 設計入門 』提到了使用 patterns 來設計與分析使用者介面的方法，剛剛在『擠料』的時候，突然想到了好幾年前曾經看過某篇介紹用 GOMS (Goals, Operators, Methods, and Selection rules) 來分析使用者介面設計好壞的 paper。由於年代過於久遠那篇 paper 到底跑去哪裡 Teddy 一時也找不到，只好匆匆到 Wikipedia 上面惡補一下。

先說明一下這四個名詞：

• Goals: 使用者想要達成的目標，例如，一個文書處理器（word 或是小作家）的使用者，想要『列印文件』。『列印文件』這件事就是使用者的 goal。
• Operators: 使用者為了達成某項 goal 所需要執行的（單一最小） action （動作），以『列印文件』而言，使用者所需要的 operator 可能包含了:
• move mouse
• click mouse left button
• release mouse left button
• Methods: 為了達到 goal 所執行的一連串 operators 就稱為一個 method。一個系統同時間可能會提供好幾種不同的 methods  來達成同一個 goal。以列印文件為例，
• Method 1: 用滑鼠透過 tool bar 來列印文件
• 移動滑鼠到 tool bar 上面 Print 這個 icon 上
  
• 按下滑鼠左鍵
• 放開滑鼠左鍵
•  Method 2: 用滑鼠透過 menu 來列印文件
• 移動滑鼠到 file menu
• 按下滑鼠左鍵
• 移動滑鼠到 print item
• 按下滑鼠左鍵
• 放開滑鼠左鍵
•  Method 3: 用鍵盤透過 menu 來列印文件
• 按下 alt-f
• 放開 alt-f
• 按下 p
• Selection rules: 如果同時存在一種以上的 method 都可以達成相同的 goal，則我們透過 selection rule 來描述在何種情況下應該選用哪種 method 會比較合適。

由於 GOMS 所描述的最小單位是 operator （按下鍵盤上的一個 key，移動一次滑鼠都算一個 operator），因此我們只要很簡單的去『加總』某個 method 所包含的 operators 就可以比較出用該 method 來達成某個 goal 是否合適，或是還有沒有改善的空間。

***

 再舉個例子，看一下 Teddy 家裡 Firefox 所顯示的『印列對話盒』：

從這個畫面可以看出來 Teddy 有三個印表機設定（實際上有兩台印表機），由於『印列對話盒』會記住 Teddy 的預設印表機，因此當 Teddy 要透過這個畫面列印文件的時候，只需要：

method 1：

• 移動滑鼠到『列印』按鈕上
  
• 按下滑鼠左鍵
• 放開滑鼠左鍵

或是 method 2：

• 按下 alt + p
• 放開 alt + p

但是，如果 『印列對話盒』沒有記住 Teddy 的預設印表機，那結果就變成：

method 1：

• 移動滑鼠到預設印表機上
• 按下滑鼠左鍵
• 放開滑鼠左鍵
• 移動滑鼠到『列印』按鈕上
  
• 按下滑鼠左鍵
• 放開滑鼠左鍵

硬是多了三個 operators

或是 method 2：

• 按下 tab 讓 focus 移到選擇印表機的這個 UI 元件
• 放開 tab
• 按下『方向鍵』（向上或向下） 移到所要選擇的印表機上
• 放開『方向鍵』
• 按下 alt + p
• 放開 alt + p

活生生又是多了四個 operators

***

路人甲：一定要玩到這麼『龜』嗎！連一次滑鼠移動或是按一個按鍵都要計較。

沒錯，就是要『斤斤計較』。通常 developers 可能只有在開發軟體的時候會使用自己所開發的軟體，在那之後就很少會用到。但是，你的客戶很可能是每天都要用好幾個小時以上。就算是使用者為了達到某個 goal （例如，新增一筆客戶資料）只增加三次不必要的 operators（例如，移動滑鼠，按下滑鼠右鍵，放開滑鼠右鍵），萬一這個使用者一天要新增 100 筆客戶資料，那他就活該倒楣要多操作 3 * 100 = 300 operators。

這還只是為了完成一個 goal 而已，一整天下來如果要完成 N 個 goals，這個倒楣的使用者不腰酸背痛才有有鬼。長久下來，不到 35 歲就需要去看復健科門診了。

很多使用者介面，雖然好像只是『沒有把 cursor 移到預設的位置』，『沒有設定正確的 tab order』，『沒有 focus 在正確的 UI 元件上』這種小事，對於經常使用該軟體的使用者而言卻是大事。Teddy 還記得第一次跟 Kay 借用 iPhone 來玩，那種『增一分太肥，少一分太廋（恰到好處）』的感覺，不禁發出『為什麼人家的使用者介面可以設計的那麼好用』的感嘆。相較起使用 學弟 某人設計的軟體，卻發出了『為什麼用完之後 Teddy 的手肘那麼的酸痛』的感嘆... XD。

***

程式寫得再美，使用者不會去幫你做 code review，看不到你的『內在美』，所以還是賣不出去。介面設計的好，使用者用起來很爽，就有賣點了。也許這樣講不盡公平，你會說介面設計的好但是玩兩分鐘就當機了啊。但是，至少你的客戶願意花兩分鐘來玩。介面設計的爛，客戶可能只願意花『一眼』，連動手都省了。

***

友藏內心獨白：Programmers 除了寫程式以外還是要懂一些 HCI 設計方法，『小扁鑽』還是有需要滴，捅人自捅兩相宜。

窮人 HCI 設計入門

Feb. 23 21:01~22:35

如果鄉民們和 Teddy 一樣都是 programmers 的話，在開發軟體的時候一定會遇到一個問題：『使用者介面要如何設計？』平平都是做手機的，人家 Apple 的 iPhone 使用者介面就設計的那麼好，而我們的卻那麼...鳥...（這一句要用唱的：人家的介面是真正的介面，我們的介面是人家不要的我們把它撿起來...）。你可能會不服氣的說，人家 Apple 或其他國際級的大公司，都有專門研究『人機介面』或是『使用者介面』的人，設計的好是應該的。好吧，有鑑於台灣都是『中小企業』居多的這個特性，想要和這些『財閥』相比是很難滴，但是軟體還是要寫啊，就算不是要賣錢的，只是給公司內部使用的系統，軟體介面不好用也是會常常被使用者念個不停甚至被恥笑。

Teddy 相信這個問題一定困擾著不少的 programmers，因為你可以把程式寫得很好，但是卻不一定知道要如何把『使用者介面設計的很好（容易）使用』。有些開發團隊雖然有所謂『設計介面』或是『做網頁的人』，這些人雖然可以把『畫面做出來』，但卻不一定具備設計容易使用介面的知識與能力。從軟體開發的角度來看，研究這個問題的領域叫做『人機互動』（Human-Computer Interaction, HCI） 或是『人機介面』（Human-Computer Interface, HCI）。由於台灣人常常抱持著『先研究不傷身體，再講求藥效 先讓軟體可以動起來，再研究好不好使用』的心態，因此在人力不足的情況下，軟體的介面設計的工作常常落到 developers 的身上。而 developers （不要看別人，就是你啦）在缺少對於 HCI 相關訓練的情況下，要設計出『有質感又超級貼心的介面』的機會大概比中統一發票特獎的機率還要低一點。

假設你是 team leader，由於上輩子燒好香，在你的團隊中擁有所謂『做網頁的人或是設計UI 的人』，你是否常常會覺的這些人的『網頁（UI）設計的不夠好』但是卻因為自己缺少 HCI 的知識而經常有『就算想開罵卻不知從何罵起』的遺憾（友藏內心獨白：讓恁爸來罵一定可以罵到『牽絲』）。來來來，有以上困擾的鄉民們，今天 Teddy 介紹這一帖藥，服用後只要『光呼吸就可以達到減肥的效果』，保證一週內最少可廋 5 公斤...XD

藥方就是 Jenifer Tidwell 的...知道這個作者的人會以為 Teddy 要介紹 Designing Interfaces 這本書，答錯。這本書太厚了，看不下去（而且要錢）。這邊有免費的 paper  可看：

COMMON GROUND: A Pattern Language for Human-Computer Interface Design

這篇 paper 顧名思義就是要介紹好幾個 HCI 的 patterns。可能是 Teddy 看  patterns 看習慣了，總覺的 Jenifer Tidwell  的這篇 paper 寫得比 Designing Interfaces 這本書要容易閱讀。 Jenifer Tidwell  在 paper 中將她所提出來的 HCI patterns 分了好幾的類別，每一個 pattern  的內容就請鄉民們自己花時間去看（Teddy 可以幫鄉民們們省錢但是卻沒辦法幫鄉民們省時間啊），在這邊看一個 Teddy 覺的很有用的分類和其所包含的 patterns 與每一個 pattern 的 solution：

How does the content or available actions unfold before the user?

• Navigable Spaces：Create the illusion that the working surfaces are spaces, or places the user can "go" into and out of. 
• Overview Beside Detail：Show the whole set of objects, or the whole undetailed data set, in one part of the display area, to act as an overview of the content.
• Step-by-Step Instructions: Walk the user through the task one step at a time, giving very clear instructions at each step.
• Small Groups of Related Things: Group the closely-related things together, nesting them in a hierarchy of groups if needed.
• Series of Small Multiples  (unwritten): 歹勢，作者沒寫。
• Hierarchical Set: Show the data in a tree-like structure. 
• Tabular Set: Show the data in a table structure.
• Chart or Graph: Show the data plotted against time or some other variable. Plot it together with other variables for further comparison
• Optional Detail On Demand: Up front, show the user that which is most important and most likely to get used. Details and further options which won't be needed most of the time -- say 20% or less of expected uses -- can be hidden in a separate space or working surface (another dialog, another piece of paper, behind a blank panel). 
• Disabled Irrelevant Things: Disable the things which have become irrelevant.
• Pointer Shows Affordance: Change the affordance of the thing as the pointer moves over it.
• Short Description: Show a short (one sentence or shorter) description of a thing, in close spatial and/or temporal proximity to the thing itself.

以 Step-by-Step Instructions 為例，這個 pattern 所要解決的問題是：

How can the artifact unfold the possible actions to the user in a way that does not overwhelm or confuse them, but instead guides them to a successful task completion?

也有人把這樣的 pattern 叫做  Wizard，講這個名字大家就瞭了。當各位在設計使用者介面，或是 review 別人設計的介面時，如果了解了這些常用的 HCI patterns，至少就有一種可以用來評估的標準。舉一個最簡單的例子，假設你的程式有一個『Print』的功能，可是使用者的電腦並沒有裝印表機。『照理講』一般正常的地球人在此情況下會把這個『Print』功能（例如畫面上的 Print button）給 disable。但是，恰巧你聘請的是遠從火星來的 programmer，沒有把『Print』功能給 disable。

路人甲：有人這麼白目的嗎？

Teddy：別懷疑...

相信鄉民們都是受過高等教育的地球人，當遇到這樣的火星人一定要用有教養的方式來教育他。

地球人：你是『丁丁』啊... 說溜了嘴...來來來，靠...近一點，先來個愛的抱抱，再讓我教你，這邊應該要套用 Disabled Irrelevant Things 這個 pattern 喔...

火星人：喔...嗯...那泥...原來還有這一招...偶了解啦...（偶是許x美，不是丁丁啦）

地球人：一定要幸福喔...XD

以上...差不多就是這個意思了。

***

不知道鄉民們有沒有注意到，這篇 paper 的標題叫做 COMMON GROUND，看到這裡應該就了解了吧。如果不知道讓 Teddy 說給你聽。在還沒有學習這些 HCI patterns 之前，地球人和火星人在溝通使用者介面上遇到困難。但是，雙方都學習了 HCI patterns 之後，就有一個『共通的基礎』可以相互討論了。

看到這邊一定會有鄉民們想說：『我聽 Teddy 你在哪邊放風吹（風箏）』... 實際上 UI 設計哪有那麼簡單... 是沒那麼簡單，HCI 還包含了很多議題，例如 task analysis 和 usability 以及設計精美的小 icon 。但是在練會絕世武功之前，好歹先買把『小扁鑽』隨身攜帶著，不然是很難在『艋舺 軟體界』立足滴。免錢的加減用一下。

***

友藏內心獨白：有便宜的牛內還不趕快搶。

還少一本書：The Unified Software Development Process

Feb. 22 22:41~ Feb. 23 00:16

昨天介紹了對於了解與實做 CMMI 有助益的 Managing the Software Process 這本書，今天就順便介紹一下 The Unified Software Development Process 這一本。本書的作者也是鼎鼎大名的三巨頭 Ivar Jacobson, Grady Booch, James Rumbaugh。如果說昨天介紹的 Watts S. Humphrey 博士是 CMMI 之父，那麼今天介紹這三位 (Jacobson, Booch, Rumbaugh) 可以說是 UML 之父了。

這邊先澄清一個觀念，就好像常常有人會說：『我們團隊使用 CMMI 流程來開發軟體』這種錯誤觀念（CMMI 並不是一種開發流程，原因請參考昨天內容），也常常會聽到有人說『我們使用 UML 來分析軟體專案』或是『我們使用 UML 來開發軟體』這樣的錯誤說法。哪裡錯了？

• UML 的全名是 Unified Modeling Language，這邊偷用一下 wikipedia 的解釋 『UML includes a set of graphic notation techniques to create visual models of software-intensive systems.』所以常常有人說 UML 『只是』一種『畫圖（講好聽一點就叫做 visual modeling）』的表示法而已。了解這一些標準的『畫圖表示法』，例如 Class diagram, Sequence diagram, Activity diagram, Use case diagram 等等，並不能說你就知道要如何『分析』軟體。就好比知道各種幾何圖形並不表示你知道要如何畫出一幅好的圖畫一樣。這是兩件事情。
• 你可以用 UML 來表達軟體設計，但是你不能用 UML 來『開發軟體』。你可能會不服氣的說，可以啊，書上有說，UML 圖畫好之後按下『Code Generation』就把程式自動產生好了，還可以選要產生 Java, C# 或是 VB.NET 各種不同的語言喔，連一行程式都不用。也許有一天大家真的可以用這種方式來『開發軟體』，但不是今天。

明明是要介紹 Unified Software Development Process (簡稱 Unified Process, UP) 為什麼 Teddy 又扯到 UML... 因為 UP 和 UML 的作者都是同一批人，而且在看 UP 書籍或相關資料的時候，又經常看到一堆有的沒的 UML diagrams ，所以鄉民們很容易就會 UP, UML 傻傻分不清楚。

再幫鄉民們問一個問題，那沒事幹麼學 UP，不是用 SCRUM 或 XP 這種 agile methods 就好了？答案也很簡單：

• 現實世界中，專案的大小，型態各異，多了解幾種軟體開發流程可以讓自己面對到不同的專案時，有多一點的選擇。就好像一個 programmers 不可能只會一種 programming language 一樣。就算你覺的 Java 是全世界最棒的語言，如果你真的傻傻的一輩子就只會 Java，那是很危險滴。
• 和別人（『兵』）吵架的時候，多知道一點東西比較不會被唬的一愣一愣的。有人說『知識就是力量』，Teddy 說，『知識就是吵架本（吵架的本錢）』。

***

Teddy 的部落格都是『當天現撈的』，常常一不小心寫太晚搞得 Teddy 晚上失眠。接下來以大易輸入法的方式快速介紹一下本書重點。

UP 的三大支柱：

• Use-Case Driven：這一點其實很有趣，如果了解 Scrum 的人把 Use-Case Driven 換成 Story Driven 這樣就可以了解這一點的含意。在 Scrum 中，軟體開發流程是在每一個 sprint 中挑選若干個 story 來開發，最後在第  N 個 sprint 的時候把軟體做完。所以我們也可以說 Scrum 是 story driven (story 『驅動』著 Scrum 流程的每一項活動)。在 UP 中，這樣的精神是很類似的，只是 UP 用來紀錄需求的單位是一個 Use Case。
• Architecture-Centric：這一條解釋起來比較難一點，大體的精神是在軟體開發的『較早階段』，利用先『實做』最重要 5%～10% Use Cases 的機會建構起 software architecture 的『雛型』。日後隨著越來越多的 Use Cases 的內容被釐清與實做，這個 architecture 逐漸『轉大人 成熟』。
• Iterative and Incremental：這一點就比較沒什麼好解釋，UP 和現代主流的軟體開發流程一樣，都是支援 IID 的流程 (Iterative and Incremental Development Process)。

其實這本書的重點 Teddy 已經講完了，了解這三點之後，是很有幫助的。有時候 Teddy 甚至懷疑自己在採行 Scrum 的時候都有被 UP 『附身』而渾然不知的情況。鄉民們仔細想一下，想不起來的 Teddy 再幫各位複習一下，其實 Scrum 這個框架可以很簡單的用下面幾點表示：

• Role：Product Owner, Scrum Master, Team (Developer)
• Activity：Sprint Planning Meeting, Daily Scrum, Sprint Review Meeting, Retrospective Meeting
• Artifact：Story, Sprint Backlog, Sprint Backlog, Task Board, Release Plan

那... 對於要如何『開發軟體（分析，設計，實做，測試，佈署...etc）』Scrum 是沒有規範的。往好的方面來講這樣是『很有彈性』，從壞的方面來講這樣是『太有彈性以至於不知道要怎麼進行』（怎麼評價端看你是汎藍還是汎綠的...XD）。所以，無論是採用哪種流程，基本的『分析與設計能力』還是要有的。不管你使用傳統的『結構化分析與設計』或是目前主流的『物件導向分析與設計』，在不同的流程中都是必備的技能。關於這些分析與設計的技巧，在 Scrum 是不管你的（Scrum 內心獨白：給你彈性啊），在 UP 中就提的比較多。所以，這本書介紹完 Use-Case Driven， Architecture-Centric，Iterative and Incremental 這三個觀念之後，緊接著就介紹 UP 所謂的『core workflows』：

• Requirements Capture
• Capturing the Requirements as Use Cases
• Analysis
• Design
• Implementation
• Test

鄉民可以把這些介紹 『core workflows』的章節當作學習某種『分析與設計方法』。說真的雖然當年 Teddy 為了考資格考不得已將這些『core workflows』很認真的讀了好幾遍，但是到現在早就忘的差不多了。耶，Teddy 還是活的好好地，所以應該.... 沒看也沒關係。Teddy 覺的這本書介紹的 『core workflows』 過於『正規』了一點，光是為了搞懂這些『表示方法』所花的時間與在實做上所帶來的真正好處相比，C/P 值似乎太低了一點。如果要學分析設計方法，還不如直接去看 Crain Larman 的 Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development 這本書就好了（書名還真是長）。

像是書中介紹 Use Case Realization 這個概念，Teddy 曾經聽說有公司在面試工程師的時候還拿來當考題...說真的，現在 Teddy 也答不上來。不過再強調一次，Use-Case Driven， Architecture-Centric，Iterative and Incremental 這三句話一定要熟記，非常有用的觀念。Teddy 在採用 Scrum 開發專案的時候，其實內心裡一直默背這三句『口訣』，尤其是 Architecture-Centric 的精神如果可以掌握，對於避免『不要因為採用逐步成長的開發流程就讓軟體長壞掉』這件事佔有重要的地位（當然 refactoring 與自動化測試也是必須的）。

***

友藏內心獨白：不要以為 Teddy 只會  Scrum 喔... 啊，還是寫太晚了。

還少一本書：Managing the Software Process

Feb. 21 21:28~ 23:41

前一陣子 Teddy 看到一個消息，Watts S. Humphrey 這位軟工界的大師過世了(4 July 1927 - 28 October 2010)，這算是軟工界一個很大的損失 。Humphrey 博士寫了很多軟體工程方面的書籍與論文，對軟工領域可謂貢獻良多。大體上 Humphrey 博士的精神是『一個流程如果無法測量，就無法改善』，因此在他的書中可以看到很多制式的表格，提供軟體開發者一個『測量』的基準。這種精神反應到了極致，就是在軟工界鼎鼎有名的 CMM 以及後來進化版的 CMMI，因此有人稱呼 Humphrey 博士為 CMMI 之父。

今天要推薦的這本書就是 Humphrey 博士在 22 年前所寫得 Managing the Software Process 這本書。

路人甲：Teddy 你不是 agile methods 這一國的嗎，怎麼可以『為匪宣傳』？


路人乙：1989 年出版的『舊書』現在還在推薦？

***

還沒開始介紹就有鄉民們看的不爽了，請容 Teddy 娓娓道來。首先，Teddy 並沒有『討厭』或 『反對』CMMI。而且 CMMI 並不是一種『流程』，而是一種『評估流程成熟度』的框架（方法），軟體團隊可以選用任何的流程來達到 CMMI 所要求的評估標準。你可以用 Waterfall，用 RUP ，用 agile methods， 或用吸星大法，只要符合 CMMI 對於每一個流程成熟度等級的要求便可（當然如果要獲得證書是需要花一筆錢滴）。

講的再白話一點，CMMI 就是一種『評鑑標準』，就好像唸國中的時候學校有『整潔競賽』一樣，整潔競賽的評分標準有『地上有沒有垃圾』，『抽屜有沒有髒東西』，『桌椅有沒有對齊』，『黑版有沒有擦乾淨』，『垃圾有沒有倒』，『門窗電燈有沒有關好』，『打掃用具有沒有歸位』等等囉哩八唆的一堆規定。打分數的老師就用這些『評鑑標準』來評量你們班級的『整潔成熟度等級』。至於要如何達到『高整潔成熟度』，則是不會被規範在『評鑑標準』中。有的班級可能會用『排值日生』的方式，有的人會要求『全班留下來打掃』，有些『富二代』的班級可以把打掃工作『外包』，有的班級可能會花錢買 『iRobot』 外加『好神拖』以提昇打掃效率（一個以 xxx 工具支援的自動化打掃流程...XD）。總之不管是黑貓白貓，只要能通過『評鑑標準』的就是好貓。是不是這個意思？就是這個意思。

講了這麼多好像都不是重點... 總之：

(1) 介紹 Managing the Software Process 或是 CMMI 不算為匪宣傳。
(2) 此書雖然已經出版 22 年了，但是如果你是那種『測量的擁護者』，那這本書還是十分值得一看。此外，本書還是有很多軟體工程觀念，作法與名詞介紹，歷久彌新。
(3) 就算你是那種很不爽 CMMI 的人，還是要看。如果不『深入敵營』，如何打探消息並將敵人殲滅。

***

終於要講到書中內容，第一章開宗明義介紹 A Software Maturity Framework

The objectives of software process management are to produce products according to plan while simultaneously improving the organization's capability to produce better products. The basic principles are those of statistical process control....

The basic principle behind statistical control is measurement.

第一章提到了五個 process maturity levels:

• Initial
• Repeatable
• Defined
• Managed
• Optimizing

***

第二章介紹 The Principles of Software Process Change

• Major changes to the software process must start at the top. （就是說老闆要出來鎮壓反對勢力，至少不可以自己帶頭反對...XD）
• Ultimately, everyone must be involved. （就是說最終要把公司上上下下每個人都搞得很累...XD）
• Effective change requires a goal and knowledge of the current process. （減肥前要先拍照『證明』自己胖的跟條豬一樣，這樣減肥成功後才可以拿來跟前男友炫耀...XD）
• Change is continuous. (改善是沒完沒了滴，就是說顧問的錢要一直付下去不可以省...XD)
• Software process changes will not be retained without conscious effort and periodic reinforcement. (這一句也很重要，想一下，連 Scrum  裡面都有若干角色/機制可以呼應這一點。)
• Software process improvement requires investment. （Teddy 內心獨白：這一條的意思應該不是叫大家每次都花個 100 萬新台幣去換個 CMMI Level X 證書吧... XD）

***

有看電視的人都知道，醜女（男）在進行大改造之前，都要被現場來賓狠狠的批評一下。同理可套用在軟體流程改善上。第三章介紹 Software Process Assessment 的幾點原則。

• The need for a process model as a basis for the assessment.
• The requirement for confidentiality.
• Senior management involvement.
• An attitude of respect for the views of the people in the organization being assessed.
• An action orientation.

***

第四章談 The Initial Process，也就是 Level 1。一言以蔽之，Level 1 就是『亂七八糟』。接下來 5-8 章介紹 The Repeatable Process；9-14 章是 The Defined Process；15-16 章是 The Managed Process；17-20 章是 The Optimizing Process。在此列舉幾個大家比較熟悉的內容：

• 第六章 The Project Plan
• 第七章 Software Configuration Management (Part 1)
• 第八章 Software Quality Assurance
• 第十章 Software Inspections
• 第十一章 Software Testing
• 第十二 Software Configuration Management (Part 2)
• 第十七 Defect Prevention
• 第十八 Automating the Software Process

***

總之，這本書用『工程』的方法告訴鄉民們『軟體應該要這樣開發滴』... 不管看完之後是否買帳，多了解一種看法也是不錯的。另外，這本書不會只告訴你要達到 Level x 『應該』做這個，做那個，而且會實際告訴你『實做方法』。如果想導入 CMMI 的人看這本 CMMI: Guidelines for Process Integration and Product Improvement  書看的一頭霧水的時候，不仿先看看 Managing the Software Process。

***

友藏內心獨白：Humphrey 博士 2010 年 10 月逝世，而他的最後一本書 Reflections on Management  出版於 April 8, 2010。這豈不是說他老人家到生命的終點都還在寫書... 真是太令人敬佩了。

秀才遇到兵

Feb. 19 22:20~ Feb. 20 00:08

Teddy 發現這幾年陸陸續續所寫的近二百篇文章中，點閱率比較高的像是『600 多個 bugs 要怎麼修？ 』，『老闆，軟體不是這樣開發滴』以及『改行寫網路小說算了』，都有一個共通點，就是隱含著一種『秀才遇到兵，有理說不清』的無奈。相信這種感覺也是許多鄉民們內心小小的吶吼，所以才比較容易引起迴響。至於那些太技術性的文章，就當作 Teddy 自己寫爽的，充充業績之用。


秀才，當然就是咱們這些頑劣不冥的 攻城屍 工程師們，至於兵的『可能性』就很多了：

• 聖上：豈只是『兵』，還且還是『天.....天都準時上班的...大兵』，一句話就可以讓你消失在地球表面，殺傷力 100%。
• 九品芝麻官：天高皇帝遠，聖上殺傷力雖大，但總不會天天都給你一道聖旨，但九品芝麻官（直屬主管）就不同了。運氣好遇到那種每天盯死你的，讓你一想到要上班就憂鬱起來。遇到勤政愛民的九品芝麻官也就算了，但絕大部分都是那種善於揣摩上意，逢迎拍馬，找代罪羔羊的貨色。九品芝麻官在『大清帝國』龐大的官僚體系中多官位雖小，但絕不可小覷。就好比一把只要三塊錢新台幣的『超級小刀』，每天只要被刺一刀縱使你有再多的血也不夠流啊。
• PM ：俗話說『好的 PM 帶你上天堂，不好的 PM 讓你虛工做不完』。有些 PM 好像上班的時候忘了把大腦帶出們，遇到問題只會『轉寄 email』。把客戶的 email 轉給工程師，或是把工程師對於需求的問題直接轉給客戶，似乎已經變成這種 PM 的反射動作（還記得嗎，反射動作是不需要經過大腦思考滴）。如果 email 『轉得好』也就算了，有時候把該給 testers 的 email 要求 programmers 去做，掀起一場無謂的『內鬥』，有這種 PM 國家 公司還需要敵人嗎？殺傷力以『三國人物』來看的話，也算是『張飛』這種等級了。
• 大牌業務：仗著『全公司都是靠我在養』的氣勢，大牌業務要你們這些手無縛雞之力的『秀才』作詩，你就得在『七步之內』吟出一首五言絕句（Teddy 內心獨白：我又不是曹植），叫你畫畫你就得在三分鐘內畫出一幅『春樹秋霜圖』（Teddy 內心獨白：先把秋香拿出來人家才要畫啦...XD）。要小心這些大牌業務都有『密奏之權』，可直達天聽，要是你好膽拒絕他們的要求，下場可是會『暗箭』穿心。
• 同事：雖然『理論上』秀才的同事應該也是秀才啊，可是有時候你的秀才同事可能會『投筆從戎』，一不小心也變成小兵了。
• 顧客：出錢的是大爺，遇到這種『兵』只能當作『清冰』... 加減吃... 就算現在外面溫度只有 攝氏10 度加上細雨綿綿你還是得把這碗『御賜清冰』給它『吞下去』。

但是，從『兵』的角度來看，這些『秀才』才是『不知天高地厚』的人。『兵』叫你作什你就做什麼，那來的那麼多意見。這個也不做，那個也不行，那你俸祿還要不要領？（兵內心獨白：國庫只剩下四百萬兩的壓庫銀了...）

 ***

有一次 Teddy 在和指導教授在討論某個研究題目的時候，他曾經說過類似的話（細節 Teddy 已經忘了，大意如下）：

美國（西方）雖然很強調科學，但是老美內心其實有一種反科學（瞧不起科學）的意識。你看很多老美的電影裡面，壞人在一個高科技的實驗室內正要做出危害全人類的勾當，此時類似『藍波』這種『頭好壯壯』的肌肉猛男在最後一刻及時趕到打倒了壞人。壞人警告肌肉猛男，千萬不要隨便亂碰任何按鈕，否則就會立刻爆炸。眼看剩下倒數 10 秒鐘壞人所設定的炸彈就要啟動了，『頭好壯壯』的肌肉猛男完全不鳥壞人的警告，二話不說，拿起手上的衝鋒槍朝這些『高科技設備』一陣掃射..... 沒事，狀況解除，肌肉猛男再次拯救世界。

 ***

如果把『肌肉猛男』換成『秀才』那就完蛋了，剩下 10 秒哪可能讓『秀才 』在那邊慢慢研究解除炸彈的密碼。有時候 Teddy 也會懷疑，學那麼多有的沒的真的有用嗎？也許真實世界需要的是『肌肉猛男』而不是『秀才』。

友藏內心獨白：這一篇在寫什麼連 Teddy 自己都看不懂...XD