開下去就對了

Jan. 20 21:31~22:39

2009 年 10 月 Teddy 去上 Certified ScrumMaster 課程的時候，上課的講師 Bas 問了一個問題：『如果你的專案進度落後，在不增加人的情況下，要如何加速？』

若是鄉民們有讀過『人月神話 （The Mythical Man-Month）』這本書，就會知道『在一個延遲的專案中，加入更多的人，只會使得專案更加延遲』這個道理，所以 Bas 好心的在問題中加了『不增加人』的限制。

上課的學員們也不是省油的燈，大家七嘴八舌講了一堆方法，Teddy 只依稀記得幾個：

• 外包...這和增加人手不是一樣？
• 減少需求...問題是客戶不准啊...
• 假裝進度正常...用『馬扁』的也行喔！
• 加班...這是一定要的啦...不過，只有短期效果...長期加班只會讓效率更差...

最後 Bas 講了一個很簡單的方法，只要『口袋夠深』就可以，這個方法就是『花錢』。不過這錢可不能亂花，像是『發展國際一流大學及頂尖研究中心計劃』（是誰想得那麼繞口的名稱，又是一個 A Name without Quality 的最佳範例），一下子就把『五年五百億』花光光 還嫌不夠。或是『八年八百億治水計劃』一樣，不把錢當錢看（把錢當選票看）。這都是失敗的範例。

那錢要如何花才能改善專案進度落後的問題呢？方法很簡單，就是朝著『改善開發與測試環境』開始。

• 很多專案因為被拿來當作測試環境的電腦只有一台，因此 programmers 要等待這個共用的測試資源。Teddy 親身的體驗，在絕大多數的情況下，增加測試設備可以立即有效改善開發進度。
• 買大螢幕（至少 22 吋 16 比 10 的液晶螢幕），好用滑鼠與鍵盤給 programmers。螢幕不要買太爛的牌子，看久了眼睛會酸。
• 買高級的電腦給 programmers 寫程式，記憶體『能加多大就加多大』。吸管要多粗有多粗，冰塊要多大有多大，差不多就是這個精神。
• 給 programmers 用大桌子。
• 如果口袋再深一點，最好能有超高級『人體工學椅子』可以坐。不過，一張椅子至少也要一萬新台幣以上...一般正常的公司實在是敗不下去。

以上所說絕對不是勸敗文，也不是幫政府鼓勵消費。因為整個軟體開發專案的成本，絕大部分都是花費在人員的『薪水』上面，和那些動不動就要幾百上千億的『高科技工廠』比起來，軟開發的設備費只能算是九牛一毛。只要少少的投資，便可有效利用最昂貴的『人力』成本，鄉民們您說划不划算。

很可惜，很多『老闆』並不懂這一點，總是想著能省則省：

• 大家『公家用』一台測試電腦就好了啦，幹麼每人一台，又不是隨時都在測試（Teddy 內心獨白：會這樣講，就知道這個老闆沒在寫程式）。
• 螢幕不要用太大啦，對眼睛不好。（Teddy 內心獨白：讓我瞎了吧！）
• 你跑什麼程式需要用到 8G 的記憶體嗎...（Teddy 內心獨白：這是爽度問題）
• 又不是要『辦桌』，寫程式桌子用那麼大幹麼？（Teddy 內心獨白：桌子太小容易打翻咖啡）
• 開什麼玩笑，一張椅子要一萬？我睡覺用的床都不用一萬。（Teddy 內心獨白：人家體質特殊需要特別照顧啊）

***

前一陣子 Teddy 申請了兩台 32G SSD 當作跨平台測試機器的硬碟。因為需要從 DRBL Server 上載入不同的 OS Images（不懂的鄉民請參考『土炮跨平台自動化功能測試環境 』），為了加快測試速度，所以改用 SSD。因為 Teddy 從來沒用過 SSD，所以先買個兩台 漱漱口 試一下，結果真的挺方便的。後來 一時衝動 經過仔細分析，當下決定幫每一個 team member 都申請一台 64G 支援 SMART 功能的 SSD，今天剛拿到，真是 太爽了 太方便了。以後要安裝，備份，還原測試的 OS images 就可以省下不少時間。

算一算最近一個月為了測試花了快十萬...不知道何時會被罵...可是... Teddy 還有好多東西想申請啊...好歹再來個 4G DDR3 ECC RAM * 20 條還差不多...

***

友藏內心獨白：Scrum Master 快變成採購人員了。

演講題目

Jan. 19 22:03~22:58

一個多禮拜前的某個下午，突然接到王教授的電話，要 Teddy 下學期到電子系大學部專題演講課程給個 talk。對於只剩 『1.25天』特休假的 Teddy 而言，心中實在是千百個.....，但是以王教授德高望重的身份，人家找你就是看得起你，給你面子，所以 Teddy 當然是欣然答應了。


後來 Teddy 查了一下去年演講者的資料，哇靠...近一點，怎麼演講者都是某某『教授』，『副總裁』，『董事長』，『理事長』，『執行長』，『製作人』（連這個也 有），『總經理』，『技術總監』，最後居然還有『立法委員』。切，Teddy 只是個小蘿蔔頭，身份落差也太大了吧（好歹也要等到 Teddy 變成5億探長之類的再說吧...有那麼一天嗎？）。突然有點後悔答應王教授。

後來仔細一想，對了，因為王教授之前聽過 Teddy 分享 Scrum 的經驗，當時 Teddy 看到王教授一直在笑，肯定是欣賞 Teddy 的搞笑功力。既然成就比不上人家，那就以『搞笑』取勝好了。（Teddy  內心獨白：怎麼覺的快變成小丸子裡面的『野口』了... 七刀...）


王教授要求演講者先把演講題目與演講的時間寄給他，此時 Teddy 心中浮出理想題目的第一名：『老闆，軟體不是這樣開發滴』，此為  Teddy 2010 年的得意之作，用這個內容當作演講題目再加以擴充一定很讚的啦。

正當 Teddy 沈醉在自我感覺良好的氣忿之中，卻被 Kay 痛罵了一頓。『這個題目不行啦，你是去講給學生聽又不是講給老闆聽』。其實講給誰聽都可以，不過對於一個『與國同壽』的學校而言，這樣過於俏皮的題目的確不太合適（Teddy  內心獨白：難道要當眾脫褲子...XD）。

好吧，那就改個四平八穩的題目：『軟體開發與軟體工程』（學生甲：好無聊的題目）。宣導一下『軟體開發需要軟體工程』這個觀念。

路人甲：耶，這有什麼好宣導的？


Teddy：當然有啊，因為絕大部分的人都不認為『軟體開發需要軟體工程』啊！

路人甲：有這種速？

Teddy：你新人啊！

***

『軟體開發需要軟體工程』這句話『聽起來』感覺是一件很自然的事情，讓 Teddy 換個方式來說明這樣大家就瞭了。

• 行醫需要醫德（那健保怎麼會搞到快破產？）
• 從政需要道德（您剛到地球嗎？）
• 名嘴需要有口德（這是在練習修辭學上的反諷法嗎？）

差不多就是這樣的意思啦，在台灣軟體開發需要的恐怕是『加班，加班，我愛你』，其餘的等三民主義統一中國之後再說吧。學生在校的時候也應該要認識一下社會真實的一面，以免出社會後適應不良，Teddy 真是佛心來的。
 

***

結論：耶，講完之後會不會沒人想來開發軟體啦？也好，少一些人來跟 Teddy 搶飯碗，年紀大了快搶不過這些年輕人了...XD

***

友藏內心獨白：特休假就只剩 5小時啦。

土炮跨平台自動化功能測試環境：補充篇

Jan. 17 22:03~23:02

昨天 Teddy 談到『土炮跨平台自動化功能測試環境』的建置重點，包含。

• 儘早為待測軟體寫安裝/反安裝程式
• 使用 DRBL 從 server 端自動載入執行功能測試案例所需的作業系統
• 用 Robot 作為自動化功能測試框架

不過昨天漏掉了一點，少談了『自動佈署測試框架』 這個問題。假設鄉民們要在 Windows 7 64-bit，Windows 2008 64-bit，Ubuntu 64-bit 與 CentOS 64-bit 上面用 Robot 測試自己開發的軟體，當 OS 裝完之後，至少也要把 Robot 裝上去。 假使鄉民們的軟體需要用到 Firefox 3.5，那這個也要順便裝好。總之，待測軟體本身可以利用待測軟體的安裝程式來佈署，但是其他週邊『哩哩扣扣』的東西就不一定有現成的自動安裝方法。

這有什麼大不了的嗎？安裝測試環境到四個作業系統，頂多花四個小時好不好，有什麼好『自動化』的。是沒錯，但是考量到：

• 如果未來支援的作業系統變多，每次都要花時間安裝很煩。而且有時候要裝好後還要手動作設定，一不小心手ㄎㄟ就有可能做錯。產生 bugs，就是一種浪費。
• 如果鄉民們和 Teddy 一樣，開發的軟體是會認『主機板』的，那麼要需要安裝的 OS images 就很可觀了。這時候，每次都要重複人工佈署測試環境也是一種時間與人力的『浪費』。請參考這一篇 『消除浪費 (3)：Relearning 』。
• 如果開發人員也想要在自己的開發環境中執行一下『功能測試』，那麼又要自己安裝一次測試環境。這位開發人員很可能會因為不熟悉如何安裝而延後測試的時機。這也是一種浪費，請看『消除浪費 (6)：Delays 』。

還記得 Teddy 說的：要建制一個『自動化測試環境』，並且要讓在這個環境中加入一個 acceptance tests 這件事變得很透明且很簡單。現在還要加上一句『人人有測試環境可用』，如此方可達到『人人有功練習』的境界。
 

***

講了這麼多，總之就是要『想辦法』自己把所需要的測試環境看看能不能打包成一個 zip 檔案，然後只要隨便在想要測試的電腦中解開，再執行一個 script 設定一下環境變數這類的事情，就完成了測試環境的佈署了。換句話說，就是要把測試環境變成『綠色軟體』，差不多就是這個意思，這樣大家應該瞭了吧。


每個團隊所使用的測試工具與需要的環境都不一樣，因此 Teddy 也只能講個大概，實際的『苦工』就要靠各位有心的鄉民們自行處理了。

***

在結束本篇之前，Teddy 想提一下 TPS (Toyota Production System) 裡面所提到的『自働化』觀念。簡單的說，很多事情鄉民們以前可能都覺的『這是不可能滴』，但是如果一直思考如何用『自働化』來逐步實現原本認為不可能的事情，那麼這件事最後就有可能變得可行。例如，假設鄉民們的團隊只有 5 個人，被要求要開發支援：

• 所有的 Windows 與 Linux 系列的作業系統。
• IE 8, IE9, Firefox 3.x, Chromium。
• DB2, Oracle, SQL Server, SyBase, Informix, MySQL, H2, HSQL。

如果傻傻的卯起來寫程式，就算是『寫 code 寫到手抽筋』也是白搭。但是如果可以想想：

• 如何簡化跨平台軟體『開發』的困難？
• 如何簡化跨平台軟體『測試』的困難？
• 如何同時支援不同的瀏覽器？
• 如何同時支援不同的關聯式資料庫？

漸漸的，答案可能就會浮出。

路人甲：那答案是什麼？

Teddy：你有付顧問費嗎...XD

同樣的，如果團隊中沒有『專門的測試人員』，這並不表示團隊的測試就『被允許』可以做的比較差。『土炮』雖然沒有『洋槍洋炮』那麼厲害，不過就好像武林高手一樣，功夫到了一定境界，樹葉都可以殺人....(路人甲內心獨白：希望被殺的不是自己...)。

***

友藏內心獨白：其實 Teddy 自己也沒動手做過，都是出一張嘴而已。

土炮跨平台自動化功能測試環境

Jan. 16 16:58~18:52

上次 Teddy 談到要落實自動化功能測試需要建制一個『自動化測試環境』，並且要讓在這個環境中加入一個 acceptance tests 這件事變得很透明且很簡單。這樣講還是太抽象，今天趁著天氣冷颼颼宅在家裡，稍微談一下 Teddy 的經驗。首先 Teddy 先做一下背景說明：

• Teddy 在這邊所說的『自動化功能測試』就是對軟體做『end-to-end 的測試』... 有講等於沒講... 基本上就是 (1) 準備一個乾淨的作業系統; (2) 安裝待測程式; (3) 從『使用者介面』測試待測程式的功能。
• 上一點所說的『使用者介面』，除了 GUI 以外，也包含 CLI (command line interface) 或是應用程式所 export 的 access points (例如，透過網路連到待測程式)。
• 該待測程式需要能夠在 Windows 與 Linux 平台執行，所以功能測試也必須要能夠在不同平台上自動執行。
• 該待測程式支援很多資料庫，例如 MySQL, Oracle, SQL Server 等。功能測試必須要涵蓋這些支援的資料庫。
• 自動化功能測試環境每天晚上會自動從 CI (持續整合) 系統下載最新的安裝程式做測試。
• （作業系統平台 + 資料庫 + 待測程式）得到一組待測資料。所有的待測資料整合成一個報表讓開發人員隔天可以方便的知道測試結果。

『土炮跨平台自動化功能測試環境』的需求差不多就這樣子。也許市面上有什麼類似微軟 VSTS 這種『高檔貨』可以做到，但是 Teddy 這種貧苦人家的小孩實在無福消受，只好自己想辦法。

首先，先不要管測試的問題，先來看看『待測程式』（就是鄉民們所開發的系統啦）。如果可能的話，先幫待測程式寫一個『安裝與反安裝程式』，這一點 Teddy 在 『持續整合樣式：Installation Project 』有介紹，還沒看的快去看一下。這邊做一下重點提醒，安裝程式最好能夠支援 『silent mode』的安裝與反安裝（就是餵給安裝程式一個設定檔就可以不需要地球人的介入便可自動安裝或反安裝鄉民們的軟體），這樣可有助於自動化測試。

***

接著談一下『作業系統』的問題。假設這個跨平台軟體要支援以下四個 OS：

• Windows 7 64-bit
• Windows 2008 64-bit
• Ubuntu 64-bit
• CentOS 64-bit

一個最簡單的方法就是找『四台電腦』分別安裝這四個 OS，但是這樣有一個限制，萬一以後支援的 OS 變多了，例如增加 Windows 2003, Windows XP, Windows Vista 或是要支援 32-bit，那需要的電腦數目不就大增？

另外一個方法就是把所有的 OS 都裝在同一台電腦上面。用軟體把硬碟切成好幾個可以開機的分割區，每一個分割區裝一個 OS，然後『想一個方法』當測試案例執行完畢之後重新開機到『下一個開機磁區』。相信這個方法 99.9999% 的鄉民都想的出來，不過有一些技術上的困難。

• 一個硬碟『好像』不能切太多可以開機的分隔區。
• 就算想辦法可以切出很多『可開機』的分割區，安裝 OS 也要很小心。可能是 Teddy 手ㄎㄟ，常常一不小心把已經安裝好的分隔區給毀了。
• 把分割區的作業系統單獨備份出來之後，要直接 restore 到其他的硬碟來 reuse 好像有點麻煩。
• 最後這一點是最大的問題：如何『自動控制』每次開機要開到哪一個分隔區？如果硬碟裡面安裝的全部都是 Windows 作業系統，或是全部都是 Linux 作業系統，要做到這一點是比較簡單的，只要改 Windows 或 Linux 的開機設定檔案（文字檔案）就可以。但是如果硬碟混裝 Windows 與 Linux 那 Teddy 還沒找到什麼簡單的方法（歡迎知道的鄉民留言告知）。

在某年某月的某一天，Teddy 也忘了在什麼地方，看到了 DRBL 這個免錢的自由軟體，突然有了解決上述問題的靈感。簡單的說，DRBL (包含 PXE 與 Clonezilla) 可以把你的電腦硬碟的 image 存在 DRBL Server 上面，然後當電腦開機的時候（要選網路開機）再從 DRBL Server 上面把已經做好的 image 下載到你的電腦，然後用這份 image 開機。

結論就是，改用 DRBL 之後，就不需要對硬碟切不同的分割區，直接把你需要的 OS 安裝在硬碟上面，然後用 Cloneailla (已經整合到 DRBL 裡面) 把整個硬碟的 image 備份到 DRBL 便可。以這邊談到的例子，要支援 Windows 7 64-bit，Windows 2008 64-bit，Ubuntu 64-bit，與 CentOS 64-bit。先『手動』安裝 Windows 7 64-bit，安裝好後用 Cloneailla 把硬碟備份到 DRBL Server 上面，把這個備份的硬碟 image 取名為 P8QQF-Win7-64bit (P8QQF 是這台電腦主機板的編號)。然後安裝 Windows 2008 64-bit （蓋掉剛剛裝好的 Windows 7 64-bit），裝好後同樣備份為 P8QQF-Win2008-64bit。依此類推，最後做出四個 images。

• P8QQF-Win7-64bit
• P8QQF-Win2008-64bit
• P8QQF-Ubuntu10.10-64bit
• P8QQF-CentOS5.4-64bit

寫到這邊手好冷...XD... 這樣把可以開機的硬碟 images 全部集中到 DRBL Server 管理，以後如果還要支援新的作業系統也很簡單，至少 Teddy 覺的比起切硬碟分割區要容易管理。

不過講到這邊還有一個問題，就是如何『自動控制』每次開機要從 DRBL 上載入哪一份 image？關於這一點就要請有需要的鄉民自行研究一下 DRBL，總之 Teddy 以『學弟的性命擔保』，這絕對是可行的。有問題可以直接問 DRBL 作者，這是台灣人開發的喔（國家高速網路與計算中心），也算是『台灣之光』（Teddy 內心獨白：難得覺的每年繳的稅被拿去做些有意義的事）。

***

接著談一下資料庫的問題，這一點比較簡單。找一台電腦，把待測軟體所支援的資料庫全部裝在這台電腦上就 OK 了。

***

有了『安裝程式』，『作業系統』與『資料庫』，這樣『測試環境』就算是準備的差不多了，接下來要談一下『自動化功能測試』。光是這一點就可以寫一本書了，所以 Teddy 只能提一下自己『有限』經驗。

• 用免錢的 Robot 來當作『自動化功能測試框架』。這個 Robot 真的很好用（Teddy 內心獨白：ㄟ... 雖然 Teddy 從來沒有用 Robot 寫過測試案例，不過 Teddy 的學弟與同事們用的很 happy）。這個 Robot 是 Teddy 的指導教授去上 Bas 的 Certified ScrumMaster 課程時，Bas 推薦的。Teddy 的指導教授回家之後用了一下覺的很好就介紹給學弟與 Teddy。Teddy 偷懶沒花時間試就再介紹給同事...
• 對於提供 Web 介面的軟體，可以用 Selenium 操作瀏覽器來執行 GUI-based 的自動化功能測試。剛好 Robot 有整合 Selenium，所以用起來很方便。
• 用 ant 當作 controller ，每日自動下載最新的安裝程式與測試程式，並啟動整個測試流程。
• 將每一個平台的測試結果存成 xml ，待最後一個測試平台的測試案例執行完畢之後，跑一隻程式把各個平台的測試結果（讀這些 xml files）匯總成一個網頁。

再補充一點，同一個 Robot 測試案例可以藉由修改『變數』的方式，用來測試不同的資料庫。這樣也解決了測試不同資料庫的問題。Robot 也可以呼叫外部程式，所以透過 CLI 測試待測程式也沒問題。

 

***

結論：以上便是自行打造『跨平台自動化功能測試環境』的方法，完全免費（除了 Windows 和 商業 Database 要錢... XD）。雖然沒有詳細到『按圖施工，保證成功』的地步，不過相信有心人假以時日也可以做的到。

***

友藏內心獨白：當初裝冷氣的時後應該買有暖氣功能的... 無奈經費不足...

PS：補充一點，為什麼不直接把 OS 裝在 VM （用 VMWare 或是  VirtualBox 這種虛擬機器軟體）裡面就好了，還搞什麼 DRBL？殘念，因為 Teddy 開發的軟體是和『硬體相關』，需要直接讀取硬體的資料，裝在 VM 裡面是無法測試到這些與硬體相關的功能滴，因此才需要這麼『厚功夫』。如果鄉民們沒有這樣的問題，那麼用 VM 來取代便可 。21:41

誰 cover 誰

Jan. 14 23:00~ 15 00:12

話說當年 Teddy 在修『軟體測試與驗證』 這門課的時候，老師曾經花了不少時間教導如何判斷測試是否足夠的條件（test adequacy criteria）。總的來講（Teddy 內心獨白：劉老師，Teddy 對不起你。內容忘的差不多了，趕快偷看一下當年的上課投影片）program based structural test adequacy criteria 可分為兩大類：

• control-flow criteria
• data-flow criteria

其中 control-flow criteria 又包含：

• statement coverage
• branch coverage
• condition  coverage
• relation coverage
• branch/condition coverage (BCC)
• compound condition coverage
• modified condition/decision coverage (MC/DC)
• path coverage

而 data-flow criteria 又包含：

• all-paths
• all-du-paths
• all-uses
• all-defs
• all-c-uses
• all-p-uses
• all-c-uses/some-p-uses
• all-p-uses/some-c-uses

正常的人類看到這邊差不多快吐了，如果你以為就只有上面這些 test adequacy criteria 那你就太單純了。所有的分類一定少不了『其他』這一類：

• function coverage
• linear code sequence and jump (LCSAJ) coverage
• call coverage
• object code branch coverage
• race coverage
• weak mutation coverage
• table coverage

套句電視模仿節目的台詞：『台灣媒體這麼多，新聞怎麼報？就亂報嘛！』...『Test adequacy criteria 這麼多，怎麼測？就亂測嘛！』當年 Teddy 聽完這一『拖拉庫』的方法之後心都涼了一半。如果是有規模且上軌道的軟體公司（很抱歉，這種公司好像大部分都不在台灣），上述方法當然是用來評估『測試是否足夠』的重要參考。但是，在寶島台灣，也許 90% 以上的軟體專案人數都在 10 人以下，更別奢望有專屬的測試團隊來協助開發人員測試軟體。所以，假設鄉民們就是這『微型開發團隊的一 元 員』，那您要如何做測試？

Agile methods 有教，要寫 unit tests，做 TDD 或是 ATDD (Acceptance Test Driven Development)。問題是，常常寫了一堆 test cases 全部都通過，此時不禁懷疑這些『測試案例的有效性（能不能真的找到 bugs）』。

除了基本的單元測試以外，另外還有一招 Teddy 覺的是滿有用的，就是當發生 bug 的時候，先寫（後寫也行啦，但是記得一定要寫）一個可以反應出該 bug 的測試案例，等修完 bug 之後這個測試案例就通過了。這樣可以確保已經發生過的 bug 萬一以後再發生的話有測試案例可以抓到它。聽起來很簡單也很有道理，不過說真的要持續做到不太容易。大體上 programmers 都會想趕快看 code 或用 trace 的方式來找出問題。一旦問題解決後，常常會懶的補測試案例。

最近 Teddy 發現，用 Robot 寫 acceptance tests 來確保功能錯誤不再發生是一個不錯的作法。開發團隊可以在每個 sprint 安排一個 story 專門為系統的某個（或某些）功能『補寫』 acceptance tests。至於要寫哪些 acceptance test cases 可以用兩個很簡單的方式：

• 如果有軟體的使用手冊，就依據手冊上面操作軟體的方法來設計 acceptance tests。
• 找出所有使用者或是自己開發軟體時所發現的 bugs，寫 acceptance tests 來確認這些 bugs 已經消失了。

Teddy 認為以上作法對於『微型開發團隊』還滿有用的。不過，要真正落實這一點，有一個先決條件，就是要建制一個『自動化測試環境』，並且要讓在這個環境中加入一個 acceptance tests 這件事變得很透明且很簡單 （這是要花時間滴）。例如，如果要開發跨平台軟體，就要考慮到如何讓這些 acceptance tests 可以『自動的』被佈署到不同的平台上測試；如果要測試 Web 應用程式的介面，則可能要熟悉類似 Selenium 這一類的工具。能夠做到這一點，要持續增加新的 acceptance test cases 就變得比較可行。

結論：空有武林秘笈，沒有弟子來練功也是白搭。

***

友藏內心獨白：與其說把這些 coverage 忘的差不多了，還不如承認當年根本沒學好...XD

好久沒有 Scrum 了

Jan. 12 21:48~23:00

這幾天 Bas Vodde 又來到台灣開 Certified ScrumMaster 課程，據馬路消息表示因為某 Y 公司一口氣報名了 12 人（好深的口袋啊），使得傳統上每次都驚險度過開天窗危機的 Certified ScrumMaster 課程，此次居然破天荒達到 25 人參加的『高標』，真是恭喜老爺，賀喜夫人。

曾經參加過 Bas 課程的人幾天前應該都收到 Bas 寄來的一封信，信中說明 Bas 要在明天（禮拜四）晚上七點舉辦一個聚會，詢問參加意願。這麼冷的天氣，下班還要馬上從上班地點『新北市中和區』趕到聚會地點『舊北市復興南路』，實在有點累人。無奈 Teddy 奉某人之命參加，只好多穿一點衣服外加隨身攜帶一顆暖暖蛋赴會啦（友藏內心獨白：我也是千百個不願意啊）。

有持續在看本部落格的鄉民們應該會發現，最近 Teddy 比較少談 Scrum 或是 agile methods ，並不是 Teddy 已經改行不做軟體跑去賣雞排，而是 Teddy  這半年來大半時間都在處理和 Scrum Master 主業比較無關的工作，包括：

• 寫軟體使用手冊。
• 開鑿雪山隧道（解決一個關鍵的技術問題）
• 進京面聖。
• 回 e-mail。
• 測試軟體。
• 填測試設備採購單。

大概就剩下『打怪』還有安排『測試自動化』勉強算和 Scrum Master 的主要工作扯上邊。從 Teddy 2008 年 4 月開始第一個業界 Scrum 軟體專案至今也有兩年八個月的時間了，rum 到現在，對於眾多 agile methods 書本上所提到的一堆重點與原則有些都快忘光光了，以下簡單歸納幾點 Teddy 的心得：

• 除非公司老闆全力支持，否則 Scrum Master 是一個陣亡率很高的 植物 職務。
• 為了不要變成『植物人』，Scrum Master 背後最好有些『靠山』，這樣在『打怪』的時候比較不會綁手綁腳的（Teddy 內心獨白：打怪未捷身先死，常使 Scrum Master 罵三字經 淚滿襟... XD）。
• 『打怪』比帶 team 還要辛苦，不只要『動腦』還要『動口』加上『動手』。
• 開完會之後對於『丁丁是個人才』這句話特別有感覺（丁丁何其多）。
• 雖然不是每一個 developer 都有『追求卓越』的企圖心，適當的提醒與鼓勵還是可以逐漸改善 developer 的工作品質。
• 蹲馬步的功夫還是很重要滴，技術底子不夠什麼都不用說。
• 自動化測試很重要，也很花時間。

總的來講，一個軟體專案或產品開發要成功，取決於：

• 老闆口袋的深度。
• 需求定的好不好。
• 怪獸的數目以及打怪的績效。
• 丁丁對於老闆與專案影響力的高低。
• 團隊技術能力。
• 自動化測試的程度。

結論：好冷啊，打字打到手指都是冰的，收工先。卡早睡卡有眠。

***

友藏內心獨白：Scrum Master 的課程好像少了『打怪練習』與『辨識與管理丁丁』這兩個主題耶！

無笑軟工：跨平台軟體開發的幾種技巧

Jan. 10 22:11~22:47

幾個月前因故要整理跨平台軟體開發方法，這裡所謂的跨平台其實也只是讓軟體能夠在 Windows 與 Linux-based 作業系統上面執行，今天 Teddy 就把腦袋中所知道的作法整理一下。

不同種類的作業系統（例如 Windows 與 Linux）存在本質上的差異性。例如，Windows 與Linux 使用完全不同的圖型應用程式介面（GUI API），要開發同時可執行於這兩個平台的桌面應用程式，便要處理此差異性。甚至相同的作業系統，也會因為版本、位元（32 或 64 位元）、或是安裝更新套件（service pack）而提供不同的功能。例如，GetSystemFirmwareTable 這個 Windows API（讀取 System Management BIOS 相關資訊）只在 Windows Server 2003 SP1 之後的版本以及 Windows XP 64 位元才提供，同樣屬於 Windows XP 作業系統的 32 位元版本就不提供此 API。類似的形況在 Linux 作業系統上也十分常見。由於 Linux 屬於開放原始碼軟體，不同的廠商可自行發佈其專屬的 Linux 版本，例如紅帽公司的 Red Hat Enterprise Linux 以及 Novell 公司的 SUSE Linux Enterprise Server。這些由不同廠商所發布的 Linux 套件，彼此間也存在許多差異性。例如，許多系統設定檔存放的位置並不一致、預設的安裝軟體、函式庫也不盡相同。

除了作業系統的差異性，跨平台軟體可能還需要與不同的外部系統相互合作。例如，假設一個跨平台進銷存系統，需要同時支援商業資料庫系統，例如 Oracle、DB2、SQL Server，以及免費的自由軟體資料庫，例如 MySQL 或 Postgress。最後，軟體的執行環境也是一個需要考量的問題。例如，使用 Java 所開發的應用程式，便須考慮 Java 虛擬機器版本；使用微軟 C++ 通常會使用到 MFC 函式庫，或是需要符合 POSIX 執行環境；若是網頁應用程式，則需考量瀏覽器軟體與版本（IE6、IE7、IE8、Firefox 3.0 等）。

以下介紹幾種常見用以解決平台差異性的設計方法（可同時選用多種方法）：

• 取平台功能的交集：針對所要支援平台的功能，取其交集。此優點為可避免平台之間功能的差異性，但卻限制了應用程式可以使用的平台功能。例如，假設平台A圖形使用者介面具有進階的 3D 半透明效果，但平台B並不支援。則採用平台功能交集設計法的應用程式便無法使用平台A上面的 3D 半透明效果。如此會導致該程式在平台A上只能用基本的圖形介面。
• 取平台功能的聯集：針對所要支援平台的功能，取其聯集。此優點為可避免平台之間功能的差異性，並且不會限制了應用程式可以使用的平台功能。但針對特定平台所不提供的功能，則需要以自行開發軟體加以模擬。以前述例子為例，則採用平台功能聯集設計法的專案必須要在平台B上自行模擬 3D 半透明效果。
• 使用 Platform Factory：套用設計樣式所介紹的 Abstract Factory 樣式，針對特定平台提供特定實作，但對於客戶端程式而言並不需要知道這些屬於特定平台的程式碼，可達到程式的可維護性和擴充性。
• 使用編譯器巨集：在 C 或 C++ 專案中，普遍使用編譯器巨集來達到產生不同平台程式碼的目的。Linux 作業系統本身即是一個最好的範例。
• 使用跨平台語言：使用 Java 或 Python 這類的跨平台程式語言來開發專案。這類的語言通常提供虛擬機器或執行環境來執與平台無關的二進制程式碼（例如Java Bytecode）。跨平台語言通常也伴隨著跨平台函式庫，例如 Java Swing 圖行使用者介面或是Java內建的其他類別庫。跨平台語言所承諾「寫一次，處處可執行」（write once, run anywhere）的優點，理論上可大幅簡化開發跨平台專案的工作。然而實務上，我們經常可發現跨平台語言在不同的平台還是會有不同的行為，因此曾經有人將write once, run anywhere 戲稱為 write once, debug everywhere。由此更可見跨平台專案在其支援的平台中，必須被完整地整合與測試之重要性。
• 使用跨平台函式庫：像 C 或 C++ 這種核心很小的語言，並沒有規範標準的 GUI API。因此，若要使用 C 或 C++ 開發跨平台的 GUI 應用程式，則通常會搭配使用類似 Qt 這種跨平台 GUI 函式庫。即使是 Java 這種跨平台語言，也會因為效率的因素，也有由 IBM 公司所提供的 SWT（Standard Wegit Toolkit）跨平台 GUI 函式庫可使用。其他常見的跨平台函式庫包含 TCP/IP 函式庫、資料庫存取函式庫、XML 檔案操作函式庫等。
• 使用程式產生技術：開發跨平台軟體除了可使用通用程式語言（例如C/C++/Java）之外，另一種方式則是透過定義領域專屬語言（domain specific languages），然後藉由程式產生技術（code generation）來產生可執行於不同平台的程式碼。近年來很流行的 MDA（model driven architecture）即可視為支援跨平台軟體開發的一種方法。採用此技術需定義領域專屬語言，且需要為不同平台撰寫專屬的程式產生器，通常在較特殊的應用領域中才會採用。例如，國內便有軟體廠商使用自行定義的 XML 檔案來撰寫網頁應用程式內容，然後視客戶需要，使用程式產生器技術產生微軟 ASP.NET應用程式或是 Java 的 JSP/Servlet 應用程式，達到跨平台的目的。
• 使用模擬器：Windows 作業系統專屬的應用程式之所以無法執行在 Linux 上，主要是因為 Linux 上沒有提供 Windows API。因此，如果可以在 Linux 上提供Windows API，則專屬於 Windows 的應用程式完全不需修改便可直接在 Linux 上執行（反之亦然）。開放原始碼軟體Wine（http://www.winehq.org/）與Cygwin（http://www.cygwin.com/）便是在 Linux 上實作 Windows API 與在Windows 上提供 Linux API 的兩個例子。
• 使用虛擬機器：採用模擬器雖然可以在不需要原始平台的作業系統中執行應用程式，但是開發一個完整且高效率的模擬器並不容易，而且需要隨著所模擬的作業系統更新而異動。若採用虛擬機器（例如 VMWare、Xen、VirtualBox、Virtual PC）則省去了撰寫模擬器的工作，而且由於虛擬機器可視為介於硬體與作業系統之間的平台，因此可以支援不同作業系統的安裝。例如，我們可以在 Windows XP 上使用 VMWare 安裝Red Hat Enterprise Linux 或是 Windows Server 2008，也可以在 Linux 平台上安裝Winodws XP 或 FreeBSD 等。使用虛擬機器可以讓不具備跨平台功能的軟體在不須修改的前提下執行於異質平台上。然而，透過虛擬機器（或是模擬器）執行應用程式其效率較差，且若應用程式需要存取特殊硬體支援，則可能便無法採用此方法。
• 使用硬體抽象層：微軟的 Windows NT 作業系統在開發之初便考慮到需要執行於不同硬體平台的問題，例如 Intel X86 與 Alpha。為了使作業系統可順利的在不同的硬體執行，微軟在硬體與作業系統之間定義了硬體抽象層（HAL，hardware abstraction layer）。作業系統透過不同硬體平台的硬體抽象層，便可在極小幅度的修改之下，執行於不同的硬體平台。

以上報告完畢，若有疏漏尚請告知。

***

友藏內心獨白：怎麼才 2011 年初就開始『作帳』啦。

持續整合樣式：中文補充說明

Jan. 07 20:40~21:45

去年 12 月底 Teddy 介紹了幾個持續整合樣式（Installation Project ，Single Shared Library Project，剩下的 Patterns ），由於這幾個 patterns 是從 Teddy 與指導教授合寫的英文 paper 直接摘錄出來，所以內容也是英文。考量到許多『中文程度特好』的鄉民們可能不想看番邦的文字，為了推廣這些 patterns，Teddy 就用中文以重點說明的方式再介紹一次（路人甲內心獨白：用中文寫還是 不看 看不懂...XD）。

首先看到樣式分類表：

樣式分類	分類說明	樣式名稱
專案 (Project)	軟體專案為了模組化、派工、可維護性、可整合性等需求，將專案切分為不同類型的子專案。此分類中的樣式說明各種不同類型專案的特點與使用時機。	Interface Project, Cross-Platform Project, Native Project, Single Shared Library Project, Installation Project, Patch Project
建構 (Build)	簡而言之，建構是將軟體原始碼轉換為可執行程式的（一連串）動作。此分類包含跨平台專案持續整合所涵蓋的多種不同建構相關樣式。	Local Private Build, Remote Private Build, Cross-Platform Integration, Integration Workflow
使用持續整合的好習慣	不良的軟體開發習慣會大幅降低持續整合的效益，此分類列出使用持續整合的好習慣。	Single Responsible Person

接著是樣式的說明： 

專案分類樣式 

Interface Project：此樣式主張要嚴格區分『介面專案』與『實作專案』，以增加跨平台系統彈性並隱藏平台相依細節。區分應用軟體介面（interface）與實作是一個常見的軟體設計方法，例如微軟的資料庫存取介面 ODBC 以及 Java 的資料庫存取介面 JDBC 都只有提供介面定義，由不同的資料庫廠商提供專屬的實作。從程式設計的層面來看，物件導向程式開發所倡導的 programming to an interface, not an implementation，以及近幾年廣為流行的 dependence injection 樣式 ，也都符合此精神。對跨平台軟體而言，嚴格區分軟體系統的服務介面與實作程式碼，更可達到隱藏平台相依細節，使得程式更具有擴充性與較佳的維護性。

Cross-Platform Project：此樣式說明如何組織與平台獨立的程式。如果一個跨平台軟體的全部程式碼都是與平台相依沒有可共用的部份，則該軟體開發應被視為多個彼此獨立且不相關的專案。跨平台專案可再被細分為與平台獨立以及與平台相依的子專案，以方便程式開發、派工、整合、與測試等。與平台獨立的專案可扮演控制者（controller）的角色，依據軟體所執行的平台動態呼叫與平台相依的軟體元件。從整合與測試的角度來看，與平台獨立的專案較容易使用虛擬環境來執行整合與測試工作。在將程式碼提交到持續整合系統之前，通常只須搭配 Local Private Build 樣式便可確定其程式可以被成功建構。

Native Project：此樣式說明如何組織與平台相依的程式。與平台相依的程式需要為其準備特定的整合環境，在將程式碼提交到持續整合系統之前，通常需要搭配 Remote Private Build 樣式以確定其程式可以被成功建構。

Single Shared Library Project：此樣式說明不同類型的子專案之間如何共享軟體元件或函式庫。此樣式建議將第三方廠商所提供的軟體元件，或是自行開發專案成功建構後所產生的二進制檔案（例如 Windows 上的動態連結函式庫或 Java 的 jar 檔）統一放置到一個二進制函式庫專案中。當不同的專案需要參考到這些元件時，便有一個統一集中處可取得這些檔案，避免不同子專案使用到不同版本的相同元件的問題。當 Installation Project 樣式要產生安裝程式時，也可到此專案中來取得所需的檔案。

Installation Project：此樣式建議為安裝程式單獨建立一個專案，以便簡化製作跨平台專案安裝程式的複雜度。Windows 與 Linux 作業系統的程式安裝模式差異很大。Windows 程式大多採用 GUI 介面，而 Linux 程式則使用文字介面。因此，對跨平台專案而言，應該幫安裝程式單獨建立一個專案用以處理不同平台安裝的問題。

Patch Project：此樣式建議為『補丁』程式單獨建立一個專案，以便製作跨平台軟體更新程式。

建構分類樣式

Local Private Build：此樣式建議開發者將程式碼提交至持續整合系統前，應在本地端自行建構，確定無誤後方可提交。持續整合建構失敗，代表著嚴重的問題，必須受到開發團隊的重視。如果開發者在不確定自己修改的程式是否正確的前提下，就貿然提交程式碼，則很可能經常造成整合失敗（broken build）。由於人們的專注心力有限，大量且過於頻繁的整合失敗事件，最終將導致無人關心而使得持續整合流於形式或荒廢。

Remote Private Build：此樣式是 Local Private Build 的跨平台專案版本。假設某跨平台專案需支援 Windows 與 Linux 作業系統，開發者選定 Windows XP 為其開發平台，也遵守 Local Private Build 樣式，但是因為此 Local Private Build 只在開發者的 Windows XP 平台上被驗證，而沒有在其他（Linux）平台上建構，因此還是可能發生提交程式碼導至整合失敗的事件。因此，若能將 Local Private Build 發布到遠端不同於本地端的平台上建構，則將可降低整合失敗的機率。

Cross-Platform Integration：此樣式建議使用單一持續整合系統來支援跨平台專案建構。由於跨平台專案必須要在不同的平台上執行整合系統活動，因此若採用只支援單一平台的持續整合系統，則我們勢必要在每一個平台上都安裝一套持續整合系統，方可執行整合工作。這將是十分繁雜與耗費時間的工作，而且容易出錯。因此，針對跨平台專案，應挑選支援跨平台專案建構的單一持續整合系統，以簡化持續整合工作。

Integration Workflow：此樣式闡述如何規劃跨平台持續整合流程。持續整合活動可以包含多種不同的建構項目，從最基本的編譯、單元測試、包裝，到較進階的靜態程式碼分析、測試涵蓋率分析等。對跨平台專案而言，每次建構都需要在所有的平台上執行一次建構活動，整個建構流程可能會耗費相當長的時間。過長的建構時間將導致使用者降低執行持續整合的頻率，違反持續整合精神。因此如何規畫整合流程對於跨平台專案更顯重要。

使用持續整合的好習慣樣式

 

Single Responsible Person：此樣式建議專案團隊指定專人接受建構失敗訊息，並由其負責發起後續矯正活動。

***

結論：以上藥方，保證不含防腐劑，搭配 Continuous Integration: Improving Software Quality and Reducing Risk 與 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 二書一併服用，效果更佳 。每日三餐三次，連續服用三個月，保證廋10公斤  保證軟體專案開發『豬』事大吉。

***

友藏內心獨白：李加銅說，笨蛋才看 PTT ，聰明人都看搞笑談軟工... XD。

睡太晚之二

Jan. 05 21:20~23:05

昨天寫完『睡太晚之一』就在睡覺前 Teddy 突然想到『鹿男』這本小說裡面提到的一段對話。

『俗話說，大阪吃破產，京都穿破產，奈良睡破產』

意思是說大阪的人把錢大多花在吃東西上，京都的人把錢大都花在和服上，至於『奈良睡破產』就說來話長。

有去過奈良的人都知道在『奈良公園』，『東大寺』與『春日大社』一帶有很多不怕人的『野生鹿』跑來跑去（聽說有 2 千多頭），追著遊客要『鹿仙貝』吃。這些鹿從古早開始就被視為神鹿。根據『鹿男』小說中的說法，奈良的鹿是『鹿島大明神』的使者，而春日大社祭拜的神就是鹿島大明神。（ PS：對日本人而言『鹿島大明神』有一個很重要的任務，就是採著日本地底下一隻大鯰魚的頭，以免大鯰魚暴動產生大地震）。

在古時候，殺死鹿是死罪，所以，以前的人早上睡醒時，如果發現有鹿死在自家玄關前面，就會怕被懷疑是殺死鹿的嫌疑犯，於是這家人就會偷偷地把鹿的屍體移到別人家門前（Teddy 內心獨白：這是什麼心態！）。被放屍體的這一家睡醒之後也嚇了一跳，趕快再把死鹿移到別人家門前。就這樣 repeat ... until....  各位看官，最後鹿的屍體就出現在類似 Teddy 這種睡到快 9 點才起床而趕不及去參加元旦升旗典禮的人的家門前。哇哩勒，結果貪睡的人就被冠上殺鹿嫌疑，破產了.... 以上就是所謂的『睡破產』（這算是被強迫版的『嫌疑犯X的獻身』嗎？...XD）。

 到處都可以看到賣鹿仙貝的攤販

 東大寺前面鹿也很多

 鹿內心獨白：喂，你沒買鹿仙貝我就擋在這裡不走了

 鹿內心獨白：人家都餓到吃紙了耶，還不買給我，我是神鹿ㄋㄟ。

 鹿內心獨白：再不買給我，我就要使出絕招了喔。

 吃吃吃，不要咬到 Teddy。

  

連紀念品都是鹿

 ***

言歸正傳，話說 Teddy 從大佳河濱公園來到花博新生園區之後，就先去參觀『林安泰古厝』。夜晚的『林安泰古厝』實在是美到不行。

當天晚上的照片 Teddy 都照得不太好，回家從電腦上看才發現

來張全景圖

 這個角度看起來也不錯

 隨便亂拍

從假山往下拍

 
裡面還有很多與植物有關的展覽品

也有喝茶的地方，因為時間太晚 Teddy 還要趕場就無福享用了。

離開『林安泰古厝』不久看到一家星巴克，買了一杯熱的焦糖馬其朵一下暖一下身體。

一棵用塑膠杯作成的耶誕樹

接著看一下戶外景色

 照片拍起來怎麼有點妖氣的感覺

兩隻大鯨魚

 這一張全景照比較看得出大鯨魚的氣勢

 這個是什麼館...忘了.. 有進去裡面看了一下，內容省略

 Teddy 撐到 10:00 要關門了才離開。

捷運站也有景可看喔

這個是 Teddy 從龍山寺捷運站回家必經之地-- 萬華火車站

 

 萬華火車站對面小有名氣的薑母鴨

講完收工。

友藏內心獨白：人家也想吃鹿仙貝啦。

睡太晚之一

Jan. 04 23:15~ Jan. 05 00:14

話說民國 100 年 1 月 1 號那一天，原本計畫到總統府前參加升旗典禮，無奈天氣太冷爬不起來，起床之後只能在電視前面參加升旗典禮... 的重播。沒關係，那就改用 B 計畫，去看花博。可是，已經快九點了，這時候去應該拿不到五大展館的預約券了，想到這裡心就涼了一半。那不然就先用 PS3 看片 DVD 算了... 也好...

中午不小心睡個午覺醒來居然又快3點了，這樣不行，再不出門恐會有生命危險。還好花博的門票有那種晚上 5 點之後入場的『星光票』，只要 150 元，刷悠遊卡還可以打折喔。好吧，就去夜遊花博。

首先搭板南線到忠孝復興站，轉『詐胡線』搭到『劍南站』再轉搭免費公車到大佳河濱公園區。

劍南站對面就是有名的微閣

站牌長這個樣子，要搭花博 5，車上據說有免費的 WiFi

等約 5 分鐘之後公車就來了，是小巴，位子不多。大概 20 分鐘左右來到了大佳河濱公園園區入口。一進園區就看到下面這幾個大字（Teddy 內心獨白：還好去年為了去日本玩，買了有廣角鏡頭又可夜拍的 Sony HX5V 相機）。

到大佳大概是下午 5 點半，這一天還真不是普通的冷。空曠的河濱公園，入夜之後正是體驗傳說中『體感零度』的最佳去處。往遠處望去，印入眼簾的就是下面這一隻稱為『行動巨蛋』的超大毛毛蟲，。

側面

 正面

好像每天都有不同的活動

在裡面某個攤位有一個螢幕播放國父的照片，請注意國父的表情一直在改變

離開巨人毛毛蟲之後，看到很多人在排隊，原來是準備搭船遊河。Teddy 也學人家跑去買票嘗鮮一下。

排隊人潮

全票 120 元一趟來回五公里，也有 2.5 公里的行程（有去無回的）

碼頭還挺漂亮的，船也還 OK

以下是在船上所拍的幾張照片。

下船之後跑去跟花博娃娃照相，看得出來 Teddy 的表情冷到有點僵硬。

後來糊里糊塗『站著』看了一場表演。

看完表演之後在凍傷之前搭免費接駁公車離開大佳園區前往新生園區。

明天待續。


友藏內心獨白：搞笑談軟工快淪落成遊記了。

模式切換

Jan. 03 22:42~ Jan. 04 00:02

鄉民們一定都有這樣的經驗，當聽到一場內容過於高深的演講，或是參加一個無聊的會議，此時腦袋就會不由自主的切換到『省電模式』或是『放空模式』，更強的人甚至可以進入『休眠模式』，除了維持生命跡象所需，其餘活動一律關閉。為了因應生活中各種突發狀況，模式切換已經成為現代人日常生活的一部分。

去年11月底 Teddy 到日本（大阪，奈良，京都）玩了八天七夜，都還沒出國門，可能是因為機場的東西太貴了，一到機場人就不知不覺的自動切換到『浪費 消費模式』，總覺的不在免稅商店買點東西有點對不起國家。到了日本花錢也比較不像在台灣一樣考慮那麼多，旅遊嘛，花起錢來總是比較大方一點，這也是一般遊客的旅行模式。但是，回國時等飛機一到桃園機場，又自動切換回『省錢模式』。對於 Teddy 這種口袋不深的小工程師而言，一年當中難得有幾天可以從『省錢模式』切換到『消費模式』算時難得的放鬆。

奢此模式之清水寺賞夜楓 （PS：冷到靠北...邊走）

 在消費模式下 Teddy 在京都植物園附近吃了生平第一碗生魚片蓋飯，還滿好吃的說

同情模式：奈良公鹿頭上的角好像都被鋸掉了，所以 Teddy 用 YA 幫這隻公鹿找回一點信心

***

但是，對於 programmers 而言，在工作時過於頻繁的模式切換就不一定是好事了。例如，在寫程式的過程中，三不五時被某路人甲中斷，問了一些無厘頭的問題，讓你不得不從『生產力模式』切換到『瞎扯蛋模式』。或是在專案進行的關鍵時刻突然被路人甲在背後捅了一刀，讓團隊從『生產力模式』切換到『防衛模式』。抑或是對於老闆無理的進度要求，讓你不得不從『誠實模式』切換到『唬爛模式』。


總而言之，對於工作上所遇到的這些『怪咖』，Scrum 的解決方法是什麼呢？很簡單，為了保護 programmers 不被這些『怪叔叔』欺負，所以 Scrum 就安排了一個 Scrum Master 這個角色，專門負責『玩 game 打怪』。

千萬不要小看『打怪』這件事，有玩過 game 的人都知道，『打怪』是一件勞心勞力的活動。遇到小咖的還容易應付，可能一個 sprint 花個 2 個小時就可以搞定。萬一身邊的怪是一隻大魔王，搞不好 sprint 裡面的每一個 story 都要有一個『打怪』的 task。而且，通常打完怪之後身心俱疲，要休息好一陣子才可以調整心情去做其他工作。

所以 Teddy 認為 Scrum Master 也應該被列為『高危險工作』，萬一哪一天打怪打得太累了，在回家的路上不小心擋到『歐一歐一』，又不小心把手伸出窗外，那不就糗大了。

***

結論：通常這種『怪』都是打不死的『嘎抓』（蟑螂），只能暫時壓制一下。雖然打不死還是要打，不然會『怪滿為患』。但是要小心自己的『血』還夠不夠，不要怪沒打完自己先掛了。所以還是要找時間適時的從『打怪模式』切換到『休假模式』。

***

友藏內心獨白：知道 Teddy 出國的原因了吧，絕對不是錢太多沒地方花啊！