l

2011年4月19日 星期二

答客問 (二)

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

5 則留言:

  1. 作者已經移除這則留言。

    回覆刪除
  2. 作者已經移除這則留言。

    回覆刪除
  3. 請問在挑選task時,可以跨story嗎?或是組員都必需先把一個story完成呢?謝謝

    回覆刪除
  4. To yc.avatars:

    基本上是依循由上而下(先做重要性比較高的story所屬的task),但有時候因為工作相依性的關係,導致重要性比較高的某些task可能無法在目前施工。此時當然可以挑選其他story的task。

    回覆刪除
  5. 謝謝你的回覆,也感謝你寫了這麼棒的一本書!

    回覆刪除