Project GATE 的敏捷實踐之路

贊助廠商AgileCommunity.tw

Project GATE的敏捷實踐之路

蕭存喻 Richard Hsiao

AgileCommunity.tw

⾃自我介紹• 蕭存喻 Richard Hsiao

• 交通⼤大學資科⼯工所博⼠士• 專⻑⾧長: 網際網路技術及分散式系統

• 電腦玩家雜誌社特約作家 9年• 遊戲齡：29年

• 相關經驗：• 遊戲橘⼦子集團⼯工程師⾄至研發經理• 六年多之遊戲及引擎開發經驗• NetGames 2014 Program Committee• 近年來特別關注於敏捷軟體開發法的實務

• 導⼊入及團隊帶領約有6年經驗

AgileCommunity.tw

Project GATE背景• 內容:

• ⾏行動裝置上的應⽤用程式專案 • 跨平台、使⽤用雲服務、提供社群平台服務、導⼊入應⽤用程式遊戲化(gamification)

• 團隊組成: • ⼀一個預計⾃自集團內部切分出的新創團隊

• 向執⾏行⻑⾧長團隊提案通過的社群平台app • 在專案執⾏行⾯面及技術選擇上有相當的⾃自主權

AgileCommunity.tw

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


這個專案會冒出什麼樣的⽕火花呢?

草創期擴張期穩健期


3C 問題，⼀一個也沒少Communication Collaboration Coordination

AgileCommunity.tw

第⼀一步解決程序正義的問題 »草創期與擴張期的常⾒見挑戰:

»該聽誰的? 何時? »三個 Product Owners, ⼀一個stakeholder，團隊初期成員⼜又有點像是合夥⼈人，到底聽誰的?

» Acceptance Criteria不明確 » definition of done不清

AgileCommunity.tw

Stakeholder’s Meeting (��)

Refinement workshop

(Week N-2 Friday)

PO meeting Runway Review

(Week N-2 Tuesday)

Sprint Planning (Week N Monday)

Daily Scrum ��11:45AM

Week 2 (Week N+1

Friday)

⽅方式: 強化refinement workshop

AgileCommunity.tw

»強化Refinement workshop的進⾏行要點: 1.於refinement workshop中發表story的設計，讓成員理解並有機會參與調整設計。

2.強化workshop中Acceptance Criteria的訂定以便讓後續planning更順暢

3.⿎鼓勵當場能將設計討論完。

AgileCommunity.tw

第⼆二步建⽴立軟體規格與開發之間的共識» User Stories的撰寫、開發⽂文件撰寫

»常⾒見的挑戰: »價值不夠突顯 »開發⽂文件的撰寫詳細度 »各專業/平台有辦法⼀一同於同個

sprint完成嗎?

AgileCommunity.tw

»⺫⽬目前我們把握的原則為：「價值優先」 1. User Story Title著重描述價值 2.規格細節的⽂文件，寫了有⽤用、有⼈人會看就寫。

3.溝通的平台不限，只要有⼈人覺得可以達到⺫⽬目的就可。 »但規格部份仍要有主要匯集地

»不過，促進團隊有良好的溝通循環及養成⽂文化習慣才是重點。

AgileCommunity.tw

我們的User Stories:

12

AgileCommunity.tw

第三步使專案流程明確並順暢»增設採⽤用看板⽅方法的runway階段:

»其⺫⽬目的有⼆二: 1.解決User Story Grooming階段的不確定性

» 有些發想、設計⼯工作難以在sprint中完全達陣

» ⽀支援型或探索型等，不確定性較多的任務 2.適合量產型任務

» Runway Review是於PO Meeting來進⾏行。

AgileCommunity.tw

Stakeholder’s Meeting (��)

Refinement workshop

(Week N-2 Friday)

PO meeting Runway Review

(Week N-2 Tuesday)

Sprint Planning (Week N Monday)

Daily Scrum ��11:45AM

Week 2 (Week N+1

Friday)

AgileCommunity.tw

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

AgileCommunity.tw

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

AgileCommunity.tw

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

AgileCommunity.tw

»我們學到了什麼? »溝通、團隊適性及磨合在Agile Team裡⾯面⼀一直是個重⼤大的議題。

» Agile Scrum只是個曝險架構，對於看到的問題不能視⽽而不⾒見，需要捥起袖⼦子與團隊⼀一同解決。

»建⽴立適切的敏捷⽂文化並找尋到合適的⼈人員會事半功倍。


⾏行動應⽤用之驗收測試驅動開發

AgileCommunity.tw

»機緣: 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

BDD的測試框架的架構⽰示意

Business Facing(Gherkin)

Technology Facing

AgileCommunity.tw

»只是，現實是殘酷的: 「初次懈逅想像總是⽐比較美好」 »原本希望達成的⺫⽬目的:

1.期望透過Gherkin易懂的優勢，讓團隊中⼈人⼈人都可寫UAT描述.

2. Quality Engineer專⼼心建構step definition (reuse steps去加速架起UAT防護網)

3.有效利⽤用⾃自動化測試的優勢

AgileCommunity.tw

»⺫⽬目前達成的現狀 »使⽤用cucumber去驅動測試iOS與

Android平台的App » Gherkin與Ruby Library的部份共⽤用。

»主司smoke test及每⽇日的integration test

AgileCommunity.tw

»進⾏行過程中不盡理想的部份: » the cucumber book上提到的⼀一個也沒少:

» flickering scenario » brittle features » slow features » bored stakeholders

AgileCommunity.tw

»我們學到了什麼? »勿對於UAT⾃自動化想的太過美好

» test code 進度趕不及、穩定度不⾜足 »測試內功是重點 »敏捷測試的⽅方向選擇團隊需有共識 »不要輕忽進⾏行⾃自動化所需要的時間

»每次app features⼤大改版、OS改版及伴隨的⼯工具改版都會消秏不少團隊時間再次步⼊入穩定期。


持續整合與發佈的實踐之路

AgileCommunity.tw

»第⼀一階段：「形成共識」 »採⽤用⽐比以往更重視中的開發模式，並由cruise control.net切換導⼊入Jenkins

»不知不覺中整個project就進⼊入了trunk-based development的開發⽅方式。

»團隊形成共識: DoD包含了unit tested. iOS, android兩平台均有可以安裝的實機版本，可透過CI觸發建置、測試完，進⾏行下載安裝

AgileCommunity.tw

»維繫trunk-based development的關鍵: »形成⽂文化及養成習慣 »突顯trunk build success 與 fail 的狀態

» Build Success (previous is fail): » Final Fantasy Combat Victory Melody

» Build Fail: »南⽅方公園的精典台詞: 我的天，阿尼⼜又掛掉了~


speaker photo

»總結: 以有樂趣的⽅方式讓團隊成員確實感受到CI的整合是⼀一件團隊注重的事。

雖然我很不起眼但團隊絕不會忘了我的存在!!!

AgileCommunity.tw

iOS Project的單元測試狀況

AgileCommunity.tw

»第⼆二階段：「縮短反饋時間」 »切分出 debug, release stage，進⾏行參數、圖素⺫⽬目錄結構整理並進⾏行美術Assets的輸出的⾃自動化。 »先由較有經驗的總監們進⾏行

scripting撰寫及⺫⽬目錄定義 »透過coding dojo將知識分享給成員

»使得企畫與美術可以⾃自⾏行建置版本，確認圖素、AI、遊戲參數在實機上是正確的。

AgileCommunity.tw

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

PO決定是否發佈publish。

AgileCommunity.tw

» Project GATE的釋出stage安排(C.I.⾃自動化)

Debug Release Trial Publish Operation

背景企畫與美術測試⽤用環境

程式開發中版本

Iteration polish/

review版本

可公開的候選版本營運⽤用

功⽤用

企畫與美術測試之⽤用，如：A.I. 參數. UI 元素

供整合測試之⽤用

團隊測試、展⽰示之⽤用

送審/上架/對外展⽰示之

⽤用對外營運

⺫⽬目前費時 20 Min ~ 1 Hours <20 Mins <10 Mins <10 Mins ???


總結

AgileCommunity.tw

»我們學到了什麼 »以提昇敏捷性⽂文化為最終指導原則，⽽而不是只要求依循敏捷實踐，⽅方有最佳效果(being agile, not doing agile) »建⽴立敏捷⽂文化、環境與共識 »建⽴立符合程序正義的管道 »⿎鼓勵團隊嘗試並從中學習

» “開始”永遠不嫌晚，累積的進步是相當顯著的。


交流時間

Project GATE 的敏捷實踐之路

Engineering

Transcript of Project GATE 的敏捷實踐之路