以敏捷為信念，依據組織需求調整SCRUM方法，除了專注還是專注，打造兼具品質與速度的研發團隊

1. SEAN CHANG
運用敏捷開發方法與思維
打造高效研發團隊
sean666666@gmail.com
http://sean666666.blogspot.tw/

2. 人月神話
• 專案管理經典書籍
• 每多一倍人力，雖然可以加
快20%的時間，但也導致增
加6倍的缺陷
• 因為經驗無法快速傳承、人
越多溝通成本越高

4. 人月神話 CHAP 7：巴別塔為什麼失敗
起初天下的人只有一種語言，使用一種話。
他們在東方一帶流浪的時候來到巴比倫平原，在那裏定居。他們彼此商量：
「來吧！我們來做磚頭，把磚頭燒硬。」於是他們用磚頭來建造，又用柏油
砌磚。他們說：「來吧！我們來建造一座城，城裏要有塔，高入雲霄，好來
顯揚我們自己的名，免得我們被分散到世界各地。」
於是，上主下來，要看看這群人建造的城和塔。他說：「他們是同一個民族，
講同一種話；但這只是一個開始，以後他們可以為所欲為了。來吧！我們下
去攪亂他們的語言，使他們彼此無法溝通。」
於是上主把他們分散到全世界，他們就停止造城的工程。
因此這座城叫做巴別；因為上主在那地方攪亂了人類的語言，把他們分散到
世界各地。
<創世紀> 第11章：1~8節

6. • 瀑布式(Waterfall)開發流程，將軟體開發分成幾個階段
– 制定計畫
– 需求分析
– 系統設計
– 程式撰寫
– 驗證測試
– 運轉維護
• 每個階段必須等到上一個結束後才會進行，個階段間提
供大量文件，協助水平與垂直追溯。
WATERFALL MODEL

7. • 優點
– 將軟體研發流程規範化，遵循需求分析、系統設計、
程式撰寫、系統測試、維運建置切割各流程階段的工
作內容，有效分工合作
– 一間落實CMMI軟體成熟度檢驗的軟體開發公司，尤
其保證品質
– 較適合大型且不允許容錯的系統，Ex：航太業、金融
業
• 缺點
– 需要大量文件描述各階段的產出與介面交付內容
– 開發時程長，無法及時以最短時間進入市場驗證商業
模式可行性，不利於新創公司
瀑布式開發優缺點

9. 敏捷 AGILE 開發開始嶄露頭角

10. • 敏捷軟體開發（Agile software development）一詞其
實從1990年代開始受到關注，是一種應對快速變化需求
的軟體開發方法。
• 具體名稱、理念、過程、術語都不盡相同，相對於「非
敏捷」，更強調程式設計師團隊與業務專家之間的緊密
協作、面對面的溝通（優於文書）、頻繁交付新版軟體、
緊湊而自我組織型的團隊、快速適應需求變化撰寫程式
碼和團隊組織方法，也更注重軟體開發過程中人的作用。
• 2001年，一群宅宅軟體大師們在美國一處優閒的滑雪勝地
聚在一起，發表敏捷宣言。
敏捷開發

11. 藉著親自並協助他人進行軟體開發，
我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力，我們已建立以下價值觀:
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
也就是說，雖然右側項目有其價值，
但我們更重視左側項目。
敏捷開發宣言
資料來源：HTTP://AGILEMANIFESTO.ORG/
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Manifesto for Agile Software Development

12. 敏捷開發12大原則
資料來源：HTTP://AGILEMANIFESTO.ORG/
1. 我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。
2. 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的
競爭優勢。
3. 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
4. 業務人員與開發者必須在專案全程中天天一起工作。
5. 以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工
作。
6. 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間效率最高且效果最佳的方法。
7. 可用的軟體是最主要的進度量測方法。
8. 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的
步調。
9. 持續追求優越的技術與優良的設計，以強化敏捷性。
10.精簡──或最大化未完成工作量之技藝──是不可或缺的。
11.最佳的架構、需求與設計皆來自於能自我組織的團隊。
12.團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為。

13. 敏捷是一種概念、信念、思想
需要具體的
方法、
制度、
工具
來推行

15. SCRUM
Let’s SCRUM

16. • Scrum是一種敏捷軟體開發的方法學，用於疊代式
(Iteration)增量模型(Incremental Model)軟體開發過
程。
簡單說 SCRUM

18. • Stackholder：出錢的客戶，提出需求
• Product Owner(PO)：產品經理，負責把客戶需求轉
換成系統功能，撰寫User Story、Product Backlog交
給研發團隊
• SCRUM Master(SM)：團隊運行SCRUM的教練，負
責研發執行過程進度掌握、排除資源障礙
• Development Team：開發團隊，最好的架構為4-9
人為一作戰單位(業界實際經驗)
SCRUM 角色組成

19. • Sprint：開發交付週期(Iteration)，也可以理解為衝刺階段，根據專
案或產品需求會做調整，通常為14-30天為一個Sprint。
• Planning Meeting：在每次Sprint開始前，所有SCRUM成員一起制
定該Sprint要執行哪些User Story，並將Story的開發細節釐清，預
估(estimate)每一項Task的工時。
• Daily Standing Meeting：每日會議，Master帶領Team進行每日檢
討會議，每個人員說明昨日完成、今日完成、待協助事項。
• Retrospective Meeting：Sprint結束的檢討會議，檢視該次衝刺成
果，並且檢討與精進團隊的SCRUM調整事項。
• DEMO / Review Meeting：DEMO Sprint成果給PO或是
Stackholder，除了確保工作目標沒有偏差外，整個SCRUM成員也
可以了解整個專案執行狀況。
SCRUM 會議類型

20. SCRUM 運作流程圖

21. USER STORY
• 從客戶面向角度撰寫
• 一項清楚的User Story應
該要包含
– [WHO]角色(role)
– [WHAT]要做什麼事情(action)
– [HOW]帶給開發單位的效益
(buniness value)
• 清楚的User Story可以提
昇討論的品質與溝通合作
• 越口語、清晰的描述越好，
方便客戶理解、工程師開
發功能
我是：不喜歡出門逛街的宅宅
我想要：在網路上購買各式各樣的物品
價值：開發線上網路購物系統，可賺取
1

22. • User Story = n * Task
• Task由程式設計師自己撰寫，也才能預估(estimate)所需
研發時間
• 預估工作會在每次Sprint開始的Planning Meeting進行
• 建議Task最長不要超過13個小時，超過代表工作顆粒度
太大，可能是工作切割不夠仔細，或需求尚未釐清
• 手機APP有許多Poker直接下載使用
預估 ESTIMATE

23. • Kanban(看板)是一種協助敏捷開發的視覺化方法，
通常會跟SCRUM產出的Backlog/Task結合運用
• Kanban將Backlog的最新狀態張貼在團隊的工作
環境，狀態基本上包含待辦、資源等待、開發中、
待測試、已測試、已完成(可自由調整)等工作階
段，利用便利貼移動區間的方式清楚呈現整體專
案開發情況。
• 可手工製作，網路上亦有免費資源可以使用，Ex:
Trello
KANBAN

24. 實體看板線上看板

25. • WIP(Work In Progress)：工作半成品
• 在SCRUM中，完成一萬個半成品比不上完成一個User
Story，因為只有完整的User Story才能交付客戶
• Kanban是各階段的WIP的照妖鏡，SM務必密切關懷
WIP
WIP=4 WIP=3

26. 這樣就夠了嗎？

27. • 將程式碼編譯、單元測試、包版佈署、系統建置、功能
測試、程式碼分析、資料庫整合完全自動化，透過排程
每日/每半日/當有新程式碼被嵌入就做一次CI，然後將結
果寄送給成員檢視。
持續整合 CONTINUOUS INTEGRATION (CI)

28. • 測試是軟體開發很重要的角色，近年台灣開始認知。
• 測試種類很多，包含小範圍單元測試、大範圍功能測試、
壓力測試、系統上線的運轉測試...
• 測試不是種類越多就越好(工程師默默哭泣)，不是測試覆
蓋範率高就好，質比量重要。
• 好的軟體公司開發人員跟測試人員的比例趨近1:1，不過
近年來流行的DevOps(研發整合維運)就會要求RD要能研
發也要能寫測試。
• 一個好的研發人員也會是個好的測試人員，好的程式碼
或架構一定能自動化測試。
• 測試工具很多，需要版權的MS Test Manager、免費開
源的Selenium，依團隊所需採行，千萬不要只有
Monkey Test。
自動化測試 AUTO TESTING

29. • TDD(Test-Driven Development)：由撰寫測試驅動開發
• 研發團隊由Programmer與Tester組成，Tester不只要會
用工具測試，還要寫測試程式
• 系統規劃初期，專案經理、開發人員、測試人員一起開
會制定系統規格，如此測試人員就可以在第一時間撰寫
測試程式，不會耽誤到研發時程
TDD

30. • Pair Programming 就是兩個工程師為一組寫一份程式，
上班時間除了生理性活動外都是綁在一起工作，。
• 短期來看不符合老闆眼中的經濟效益，但長期來看卻很
適合軟體這種高智力產業
– 摸魚時間減少
– 維護成本降低，不會因為成員請假/離職讓程式碼變孤兒
– 提昇程式碼品質
– 加速開發時間
– 三個臭皮匠，勝過一個諸葛亮
共同編程 PAIR PROGRAMMING

31. • DevOps = Development + Operations
• 將研發與維運緊密結合，打破 IT 分工傳統
• 相當適合網際網路產業
DEVOPS

32. • 將研發過程的系統需求、工作項目、Bug、測試單據電子
化追蹤。
• 非常重要，是團隊共同開發的最佳幫手。
• 單據(Ticket)狀態通常為新建立、處理中、待驗測、已關
閉；由專案負責人指派負責人員，負責人員也可互相轉
發，每次的異動都會由email通知。
• 將程式碼綁定在Ticket上，透過版本控制系統可撈取需要
進行包版編譯的程式碼。
TICKET TRACKING SYSTEM

33. 組織架構 & 公司文化
敏捷思維 & 導入方法

34. 稱職的 PRODUCT OWNER
多與客戶溝通互動，設定明確的任務目標

35. 稱職的 SCRUM MASTER
讓團隊成員專注開發

36. • 核心思想
– 滾石不生苔，除追蹤專案進度外，也讓成員快速口頭進行技術分
享與交流(工程師魂!!)
• 運作原則
– 站著開會；平均一天花15分鐘，最短不到3分鐘
– 有效控制單一成員報告時間，如需深入討論另闢時間
– 建議團隊人員為5~9人，人數太少或太多沒效果
– SM最好有技術能力
– 開會前，SM先把討論議題及可能問題先在腦海中順過一次，千
萬別腦袋空空
– 請有效決策
– 團隊才是主角，SM請勿過度發言
• 邊際效益
– 也許日會可以有效追蹤專案進度，但其實也是一把雙面刃，成員
反過來也可以檢視SM的能力
DAILY STANDING MEETING 執行心得

37. 根據組織文化與型態設定會議類型
• 重新設計適合團隊的Planning Meeting &
Retrospective Meeting
• 團隊每兩週固定開會
– 會議通知信內容包含：開會時間及地點、會議議程(包含同仁
DEMO)、討論事項、追蹤事項、技術分享、會議紀錄者(排班輪
流)、臨時動議(取代原Retrospective Meeting)
– 一場會大約45分鐘可以結束，如有技術分享則會拉長時間
– 確認團隊成員手頭研發進度，安排下一次Sprint的工作項目(取
代原Planning Meeting)
– 會議記錄統一存檔，每次會議檢討前次進度
• 維持團隊研發節奏，請代理人依舊定期主持
• 在符合SCRUM框架又能用最短時間開會，最大化團隊研
發時間

38. 適時向上管理

39. 時常自我檢視

40. 思維 >> 方法

41. Q & A
The presentation material © Copyright Showeet.com
My email: sean666666@gmail.com