English version refer to the 'Team-based' part in this post:
核心概念：將目標拆成多個小任務，以「迭代」方式多次輪迴將之完成
工作流程：
釐清需求 → 制定方向 → 拆分任務 → 多輪迭代 → 驗收成果
需快速應對變化時，常採用此作法
以下用「角色」、「流程」分別解釋，拆解敏捷開發
角色
角鬥士、法師
# 電影「神鬼戰士」英文為 Gladiator，就是角鬥士
- 產品擁有者 (Product Owner, PO)
就是主管啦！
制定計劃方向、列出待辦清單 (backlog)、搞爛事找碴
依據上游需求文件 (或客戶說法)，把大任務拆成各章節 (Epic，直翻史詩)
像打電動一樣，一次破完全遊戲可能很難，但逐章通過就容易很多
- 團隊指導者 (Scrum Master, SM)：
敏捷開發的衝刺「sprint」，也常與「scrum」混用
可簡單理解成短跑、或「敏捷開發」代名詞
Scrum Monster Master 比較像「技術主管」，與工程師對接
會將史詩 (Epic)切成故事 (story)，讓工程師能沿故事線遊玩 (工程師：不好玩)
# 叫「史詩」或許難以想像，實質上就是「章節」
Story 指用戶故事，從用戶角度出發、依 INVEST 原則設計
INVEST：
- 獨立 (Independent)：
每個故事互不依賴，避免動工時權責不清、彼此干擾
若無法完全解耦，則應載明依賴性、規劃優先順序
- 可協商 (Negotiable)：
故事是協商起點，並非最終規格，細節由團隊和 PO 共同決定
在待辦清單準備會 (Backlog Refinement)、衝刺時仍可溝通修改
- 有價值 (Valuable)：
每個故事應對用戶、業務帶來「可衡量的價值」
除非目標能帶來實際價值，否則不應列為獨立故事
E.g. 若僅重構程式碼，可能就不該設為故事
- 可估算 (Estimable)：
團隊應可對故事大小或工作量，做出可靠估算
若無法估算，通常表示「需求不清」或「故事過大、含糊」
# 法律人說法：違反明確性原則
當工作量難以估算，可拆分故事、或用相對估算達成共識
相對估算常用 Planning Poker 處理：
先討論故事的需求、大小、涵蓋的技術量等
之後每個人拿撲克牌，用點數估算任務的工作量
牌面向下暗自決定，等全部人都下好離手
同時開牌！
若牌面都相同，則可視為大夥同意該故事的工作量估算
不同的話，就再討論、進入下一輪出牌
E.g. 大家對「畫面設計」都出 6，「模型訓練」都出 13
則團隊眼中，「模型訓練」的工作量約比「畫面設計」多一倍
- 小巧 (Small)：
故事需夠小，能在一個衝刺內完成 (稍後解釋衝刺)
小故事通關率高，降低卡關風險
跨衝刺的長篇，視為史詩或章節 (Epic)，應再行切分
- 可測試 (Testable)：
故事應有交付標準，i.e. 通關條件
盡量以自動化測試 (單元 / 整合 / 端對端)驗收，且條件應明定
若只有任務內容卻無驗收標準，需求和成果可能會有落差
# 電動都有「擊敗魔王」、「拯救同伴」、「活命多久」，故事當然得跟上
故事決定後，SM 再將 story 切成任務 (task)，分派給每個人負責
Task 即實際工作內容，就像遊戲 NPC 指派給你的一樣
敘述明確、可達成，目標受眾是工程師
# 若描述不明確，那是 Scrum Master 的問題，請打扁他
請容我老圖新用：
Epic 下有多個 Story，Story 下又有複數 Task
Epic
|
|-- Story
|
|-- Task
|-- Task
|-- Story
|
|-- Task
|-- Task
|-- Task
...
除了切分故事，SM 也負責協調團隊合作、監督工項和提供諮詢意見
- 開發者 (Developer)：
開發者 ≈ 工程師，就是實際動工的人
想產出程式碼，當然需要工程師嘍！
# 靠無能主管那張嘴，頂多生出口臭文件
碼農工程師就像工人，負責寫程式碼、執行、測試等
QA、SA 等不限於敏捷開發的角色，就不在此多提
流程
- 當然，先收集需求 - PO
需求確定後，擬出章節 (Epic)
畢竟不知道要做什麼，自然無法下場開發
- 列出待辦清單 (backlog) - SM
即前述「待辦清單準備會 (Backlog Refinement)」
有清單後，就可以切章節 (Epic)成故事 (Story)
幾經討論後，故事又能細分出任務 (task)
- 衝！
Sprint 或 Scrum，短跑、衝刺之意，是敏捷開發精髓
# 主要內容：寫程式、開會、測試
每個任務用一個衝刺完成，通常為期 1~2 週
- 衝刺會議 (sprint planning)
開跑前，得先釐清目標
一旦作戰會議結束，就可以開奔囉！
- 方向確立後，便是開發、測試
- 每日站會 (Daily Stand-up Meeting)
隊員們每天開一次會，時間通常是早上
彼此分享進度、遇到的困難等
特點是開會時都站著，避免歹戲拖棚
# 如果每場會都那樣開，就不信老闆、主管們還熱愛開會
- 回顧 (sprint retrospective)：
每輪衝完後，團隊會進行回顧
評估工作成果、可能的改善空間
簡言之是「良性的檢討大會」
# 理論上是良性，若開成惡性請去檢討主管
- 交付與反饋 (sprint review)：
產品完成後，交付給客戶
順便收集反饋，利於下一輪衝刺參考
# 前期的系統規劃、設計，和後期的品保等不限於敏捷開發，因此沒特別提
產品用迭代方式產生、加上每日開會，因此能快速應對需求變動
結合前期規劃，妥善設計整套系統，可儘量減少麻煩的阻力
# E.g. 主管自己講不清需求，卻怪你東西做不出來
敏捷開發只是常用的一種方法，當然還有其他選擇
每個框架都有各自優劣勢，歡迎不同愛好者交流～
