Weitere ähnliche Inhalte
Ähnlich wie Project GATE 的敏捷實踐之路 (20)
Mehr von AgileCommunity (11)
Project GATE 的敏捷實踐之路
- 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
- 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
- 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)
- 16. » 團隊後來也曾做些嘗試
» sprint N 撥出部份的時間(40%)的時間
進⾏行兩個軟體特⾊色的討論及設計,
Sprint N+1, N+2全⼒力衝刺完成。
» 偶爾為之可,⻑⾧長期下來會爆肝。
AgileCommunity.tw
- 18. » 我們學到了什麼?
» 溝通、團隊適性及磨合在Agile Team
裡⾯面⼀一直是個重⼤大的議題。
» Agile Scrum只是個曝險架構,對於看
到的問題不能視⽽而不⾒見,需要捥起袖
⼦子與團隊⼀一同解決。
» 建⽴立適切的敏捷⽂文化並找尋到合適的
⼈人員會事半功倍。
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
- 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
- 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
- 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 ???
- 35. » 我們學到了什麼
» 以提昇敏捷性⽂文化為最終指導原則,
⽽而不是只要求依循敏捷實踐,⽅方有最
佳效果(being agile, not doing agile)
» 建⽴立敏捷⽂文化、環境與共識
» 建⽴立符合程序正義的管道
» ⿎鼓勵團隊嘗試並從中學習
» “開始”永遠不嫌晚,累積的進步是相當
顯著的。
AgileCommunity.tw