Keynote speech of Agile Tour Taipei 2014.

1. Project GATE的敏捷實踐之路
蕭存喻 Richard Hsiao
AgileCommunity.tw 贊 助 廠 商

2. ⾃自我介紹
• 蕭存喻 Richard Hsiao
• 交通⼤大學 資科⼯工所 博⼠士
• 專⻑⾧長: 網際網路技術 及 分散式系統
• 電腦玩家雜誌社 特約作家 9年
• 遊戲齡：29年
• 相關經驗：
• 遊戲橘⼦子集團 ⼯工程師 ⾄至 研發經理
• 六年多之遊戲及引擎開發經驗
• NetGames 2014 Program Committee
• 近年來特別關注於敏捷軟體開發法的實務
• 導⼊入及團隊帶領約有6年經驗
AgileCommunity.tw

3. Project GATE背景
• 內容:
• ⾏行動裝置上的應⽤用程式專案
• 跨平台、使⽤用雲服務、提供社群平台服務、
導⼊入應⽤用程式遊戲化(gamification)
• 團隊組成:
• ⼀一個預計⾃自集團內部切分出的新創團隊
• 向執⾏行⻑⾧長團隊提案通過的社群平台app
• 在專案執⾏行⾯面及技術選擇上有相當的⾃自主權
AgileCommunity.tw

4. Project GATE背景
• 隨著專案的執⾏行，由10⼈人左右的團隊開始，⾄至
⼆二年後的今天，已經到達25⼈人。
AgileCommunity.tw

5. 這個專案會冒出什麼樣的⽕火花呢?
草創期
擴張期
穩健期
AgileCommunity.tw 贊 助 廠 商

6. 3C 問題，⼀一個也沒少
Communication
Collaboration
Coordination
AgileCommunity.tw 贊 助 廠 商

7. 第⼀一步 解決程序正義的問題
» 草創期與擴張期的常⾒見挑戰:
» 該聽 誰的? 何時?
» 三個 Product Owners,
⼀一個stakeholder，
團隊初期成員⼜又有點像是合夥⼈人，
到底聽誰的?
» Acceptance Criteria不明確
» definition of done不清
AgileCommunity.tw

8. ⽅方式: 強化refinement workshop
Stakeholder’s
Meeting
()
AgileCommunity.tw
Refinement
workshop
(Week N-2 Friday)
PO meeting
Runway Review
(Week N-2 Tuesday)
Daily Scrum
11:45AM
Sprint Planning
(Week N Monday)
Week 2
(Week N+1
Friday)

9. » 強化Refinement workshop的進⾏行要點:
1. 於refinement workshop中發表story
的設計，讓成員理解並有機會參與調
整設計。
2. 強化workshop中Acceptance Criteria
的訂定以便讓後續planning更順暢
3. ⿎鼓勵當場能將設計討論完。
AgileCommunity.tw

10. 第⼆二步 建⽴立軟體規格與開發之間
的共識
» User Stories的撰寫、開發⽂文件撰寫
» 常⾒見的挑戰:
» 價值不夠突顯
» 開發⽂文件的撰寫詳細度
» 各專業/平台有辦法⼀一同於同個
sprint完成嗎?
AgileCommunity.tw

11. » ⺫⽬目前我們把握的原則為：「價值優先」
1. User Story Title著重描述價值
2. 規格細節的⽂文件，寫了有⽤用、有⼈人會
看就寫。
3. 溝通的平台 不限，只要有⼈人覺得可以
達到⺫⽬目的就可。
» 但規格部份仍要有主要匯集地
» 不過，促進團隊有良好的溝通循環及養
成⽂文化習慣才是重點。
AgileCommunity.tw

12. 我們的User Stories:
AgileCommunity.tw
12

13. 第三步 使專案流程明確並順暢
» 增設採⽤用看板⽅方法的runway階段:
» 其⺫⽬目的有⼆二:
1. 解決User Story Grooming階段的不確定性
» 有些發想、設計⼯工作難以在sprint中完全達
陣
» ⽀支援型或探索型 等，不確定性較多的任務
2. 適合 量產型任務
» Runway Review是於PO Meeting來進⾏行。
AgileCommunity.tw

14. Stakeholder’s
Meeting
()
AgileCommunity.tw
Refinement
workshop
(Week N-2 Friday)
PO meeting
Runway Review
(Week N-2 Tuesday)
Daily Scrum
11:45AM
Sprint Planning
(Week N Monday)
Week 2
(Week N+1
Friday)

15. » 當然並⾮非這麼⼀一來就順利了
» Hugh Lead/Cycle Time
AgileCommunity.tw

16. » 團隊後來也曾做些嘗試
» sprint N 撥出部份的時間(40%)的時間
進⾏行兩個軟體特⾊色的討論及設計，
Sprint N+1, N+2全⼒力衝刺完成。
» 偶爾為之可，⻑⾧長期下來會爆肝。
AgileCommunity.tw

17. » Project GATE團隊的真實運作狀況(縮時
影⽚片):
» daily scrum
» daily development
» review meeting
AgileCommunity.tw

18. » 我們學到了什麼?
» 溝通、團隊適性及磨合在Agile Team
裡⾯面⼀一直是個重⼤大的議題。
» Agile Scrum只是個曝險架構，對於看
到的問題不能視⽽而不⾒見，需要捥起袖
⼦子與團隊⼀一同解決。
» 建⽴立適切的敏捷⽂文化並找尋到合適的
⼈人員會事半功倍。
AgileCommunity.tw

19. ⾏行動應⽤用之驗收測試驅動開發
AgileCommunity.tw 贊 助 廠 商

20. » 機緣:
1. 成員對於Refinement workshop的需求
2. 當CI變成開發⽇日常中的重要⼀一環後，推
⾏行⾃自動化測試的理念就開始浮現。也因
此開始進⾏行 Quality Engineer的招募 及
ATDD 制度的引⼊入與試⾏行。
3. 2013/3/28 的cc Agile Sprint 8 :「BDD
in .NET - TDD 在實務上最後⼀一塊拼
圖」 by Joey Chen(91)
AgileCommunity.tw

21. BDD的測試框架的架構⽰示意
Business Facing
(Gherkin)
Technology Facing
AgileCommunity.tw

22. » 只是，現實是殘酷的:
「初次懈逅 想像總是⽐比較美好」
» 原本希望達成的⺫⽬目的:
1. 期望透過Gherkin易懂的優勢，讓
團隊中⼈人⼈人都可寫UAT描述.
2. Quality Engineer專⼼心建構step
definition (reuse steps去加速架起
UAT防護網)
3. 有效利⽤用⾃自動化測試的優勢
AgileCommunity.tw

23. » ⺫⽬目前達成的現狀
» 使⽤用cucumber去驅動測試iOS與
Android平台的App
» Gherkin與Ruby Library的部份共
⽤用。
» 主司smoke test及每⽇日的integration
test
AgileCommunity.tw

24. » 進⾏行過程中不盡理想的部份:
» the cucumber book上提到的⼀一個也沒少:
» flickering scenario
» brittle features
» slow features
» bored stakeholders
AgileCommunity.tw

25. » 我們學到了什麼?
» 勿對於UAT⾃自動化想的太過美好
» test code 進度趕不及、穩定度不⾜足
» 測試內功是重點
» 敏捷測試的⽅方向選擇團隊需有共識
» 不要輕忽進⾏行⾃自動化所需要的時間
» 每次app features⼤大改版、OS改版
及伴隨的⼯工具改版都會消秏不少團
隊時間再次步⼊入穩定期。
AgileCommunity.tw

26. 持續整合與發佈的實踐之路
AgileCommunity.tw 贊 助 廠 商

27. » 第⼀一階段：「形成共識」
» 採⽤用⽐比以往更重視中的開發模式，並
由cruise control.net切換導⼊入Jenkins
» 不知不覺中整個project就進⼊入了trunk-based
AgileCommunity.tw
development的開發⽅方式。
» 團隊形成共識: DoD包含了unit tested.
iOS, android兩平台均有可以安裝的實
機版本，可透過CI觸發建置、測試
完，進⾏行下載安裝

28. » 維繫trunk-based development的關鍵:
» 形成⽂文化及養成習慣
» 突顯trunk build success 與 fail 的狀態
» Build Success (previous is fail):
» Final Fantasy Combat Victory Melody
» Build Fail:
» 南⽅方公園的精典台詞: 我的天，阿尼⼜又掛掉了~
AgileCommunity.tw

29. 雖然我很不起眼
但團隊絕不會忘了
speaker photo
我的存在!!!
» 總結: 以有樂趣的⽅方式讓團隊成
員確實感受到CI的整合是⼀一件團
隊注重的事。
AgileCommunity.tw 贊 助 廠 商

30. iOS Project的單元測試狀況
AgileCommunity.tw

31. » 第⼆二階段：「縮短反饋時間」
» 切分出 debug, release stage，進⾏行參
數、圖素⺫⽬目錄結構整理並進⾏行美術
Assets的輸出的⾃自動化。
» 先由較有經驗的總監們進⾏行
scripting撰寫及⺫⽬目錄定義
» 透過coding dojo將知識分享給成員
» 使得企畫與美術可以⾃自⾏行建置版本，
確認圖素、AI、遊戲參數在實機上是
正確的。
AgileCommunity.tw

32. » 第三階段：確⽴立「eat own dog food」⽂文化
» 確⽴立五個發佈的stage
» 正式營運環境移往aws
» 每sprint都有polish time
» review/retro之後全team再次試⽤用，由
PO決定是否發佈publish。
AgileCommunity.tw

33. » Project GATE的釋出stage安排(C.I.⾃自動化)
AgileCommunity.tw
Debug Release Trial Publish Operation
背景企畫與美術
測試⽤用環境
程式開發中
版本
Iteration
polish/
review版
本
可公開的候
選版本營運⽤用
功⽤用
企畫與美術
測試之⽤用，
如：A.I.
參數. UI 元
素
供整合測試
之⽤用
團隊測試、
展⽰示之⽤用
送審/上架/
對外展⽰示之
⽤用
對外營運
⺫⽬目前費時 20 Min ~
1 Hours 20 Mins 10 Mins 10 Mins ???

34. 總結
AgileCommunity.tw 贊 助 廠 商

35. » 我們學到了什麼
» 以提昇敏捷性⽂文化為最終指導原則，
⽽而不是只要求依循敏捷實踐，⽅方有最
佳效果(being agile, not doing agile)
» 建⽴立敏捷⽂文化、環境與共識
» 建⽴立符合程序正義的管道
» ⿎鼓勵團隊嘗試並從中學習
» “開始”永遠不嫌晚，累積的進步是相當
顯著的。
AgileCommunity.tw

36. 交流時間
AgileCommunity.tw 贊 助 廠 商