答客問 (二)

April 19 22:23~23:18

經過一天的沈澱 Teddy 突然又想到當天客人問的兩個問題，剛好今天也沒什麼料可以寫，就來講一下這兩個問題。

人客丁：在 Daily Scrum 的時候你會分派 task 嗎？

Teddy：會...每天...XD... 嗯嗯... 這樣講起來好像 Teddy 假 Scrum 之名行獨裁之實。其實應該說，2/3 的時間不會（因為不需要），其他 1/3 的時間不知為什麼有些比較重要但卻賣相不好的 tasks 就是沒有人認領。這些 tasks 包括：

• Acceptance testing：因為團隊中都是 programmers，像 acceptance testing 這種『苦力』的工作認領度就比較低一點。
• Review：這一類的 tasks 也是屬於比較冷門的工作，要在一團麵線中理出個頭緒也是挺花腦筋的。
• 寫使用手冊：這...別說是英文的手冊，就算是中文的手冊大部分的 programmers 也不喜歡寫。寫『文章』畢竟和寫程式不同，所以這一點 Teddy 是可以體諒的。寫文件本來就應該要找 technical writers... 但是...別想太多...還是自己包了吧。
•  古怪型：有一些『古怪』的 task 大家也都不想去認領，至於哪些屬於『古怪』的 tasks 就要看情況而定。例如，要去釐清一個不知名原因的 issue 就屬於『古怪』的 task。

通常 Scrum Master 只要堅持一個簡單的原則，就不需要『分派』tasks，這個原則就是『重要性高的 story 所屬的 tasks 要先做』，由於沒辦法『柿子挑軟的吃（task 挑喜歡的做）』，這樣子大家被逼的沒辦法就只好去領取那些『不討喜』的 tasks。萬一有些 tasks 就是有意無意被忽略，那麼 Scrum Master 也應該用比較婉轉的方式來提醒：

• 這裡有一個比較重要的 task 還沒做，有沒有誰要認領的？這種說法很類似『這裡有一隻流浪貓/流浪狗快要餓死了，有沒有那位善心人士願意認領回家照顧？』，如此可激起 programmers 的惻隱之心...。使出此招有 60% ~ 70% 以上的機會可以成功將冷門 tasks 推銷出去。
• 如果第一招不行，那只能用點名的方法（一次點兩位以上）。這個 tasks 『工程師甲』 或是『工程師乙』你們那一位可以幫忙認領？
• 如果上面兩招都不行，那就只能看看誰今天還沒有 task 或是誰最合適做這個無人認領的 task，然後直接問：『工程師X，你能不能認領這個 task？ 』。
• 如果還是不行，那大家就撐在那裡（開不完的 daily scrum....），看看最後誰受不了跳出來認領。

依 Teddy 印象所及，還有沒動用到第四招的機會。

***

下一位是人客戊關於 GUI Testing 的問題，原本的問題 Teddy 記不得了，大意是說 GUI testing 很容易出錯，是不是應該用類似 unit test 的方式來測試 UI。

Teddy 猜測這位人客應該是有看過 MVP (Model View Presenter) 相關的資料，所以才會問這樣的問題。以 Teddy 本身的經驗：

• 要把軟體的 UI 都套用 MVP 似乎不是那麼容易，如果只是為了『讓 UI 自動化測試變得很漂亮』而套用 MVP 可能（短期）會讓軟體開發的進度變慢。
• 如果是開發 Web AP，用類似 Selenium 的工具透過  UI layer 來做自動化功能測試還是有一定的必要性。至少不用管軟體是否套用什麼 patterns，而且只要稍微學一下立即可以上手（說實話，Teddy 自己是沒寫過...都是同事在寫...Teddy 只負責做 monkey testing...）。

***

以上就是 Teddy 想到的兩個問題。最後再補充一點，昨天 Teddy 奉送一篇免費的『敏捷式例外處理』paper，今天突然想到還有一篇和例外處理有關的 paper，『A Scenario-Based Approach for Modeling Abnormal Behaviors of Dependable Software Systems』，在此也提供給鄉民參考。據 Teddy 的指導教授說，這篇 paper 有某位台灣 『國際大嘴巴』公司的『老先生』很喜歡，至於是什麼原因 Teddy 也不知道，閒閒沒事的鄉民參考一下給點意見。

***

友藏內心獨白：明天該不會又想到其他客人問的問題吧...XD