前兩天，我們介紹了 DevOps 與敏捷開發，在 DevOps 中，我們可以較輕易的描繪 DevOps 流程的輪廓與方法，那關於敏捷開發，是否有常見的開發方法呢?

在敏捷開發的方法中，最受歡迎也最常被拿來比較的便是 Scrum 與 Kanban。

這裡先和讀者們說聲抱歉，因為孤單威廉大學剛好念的是工業工程管理，在這一段時間的研究中，發現當年熟悉的豐田式生產管理與軟體開發中的 Kanban，竟有著如此有趣的關聯，然而礙於時間與篇幅關係，今天就先和大家分享 Scrum 框架與主流的實踐方式。

而關於 Kanban 的介紹，承諾未來額外寫一篇向大家介紹 Kanban 從生產管理到軟體開發的演化，同時也挖出將近十年前在工廠擔任 IE 實習生的 Kanban 照片與大家分享。

What is Scrum

Scrum 其實是橄欖球運動中的爭球動作，而後取其精神，比喻開發團隊共同衝刺並達成目標，而產品也會像那顆球一樣，在團隊內相互合作傳遞，最終達到目標。

今天的介紹來源會以 Ken Schwaber & Jeff Sutherland 所發表的 The Scrum Guide 為主，同時附上部分個人的經驗提供參考。首先，Scrum 只是敏捷式開發中一種輕量化的實踐框架，當我們聽到這一類的說明時，也意味著在執行 Scrum 的精神與價值觀才是最核心的部分。

Scrum Values

Commitment, Focus, Openness, Respect, and Courag

Scrum 的成員需要具備以上幾個態度，換言之，成員需對自行負責的項目具備責任感，在承諾的時間內完成承諾的事、並勇於表達自身的看法，尊重團隊成員的意見，共同達成目標。

Scrum Team

通常，Scrum 團隊會包含三種角色:

• 開發團隊 (Developers): 致力於打造任何可交付成果的成員，負責評估與實踐、測試，通常是工程師們。
• 產品負責人 (Product Owner): 通常是 PM，負責建立目標，規劃時程並交付於團隊實作，同時也掌握資源分配。
• 敏捷教練 (Scrum Master): 通常是對 Scrum 有一定知識或實踐經驗的人，負責確保 Scrum 能夠被正確且順利的執行。

Scrum Event

Scrum 的實踐，會需要 Scrum Master 致力營造一個流程氛圍，在 Scrum 流程中，會以 Sprint (或稱衝刺) 作為時間的單位(通常是兩周)，每個 Sprint 內會包含幾個 Scrum 的流程，也代表每一個 Sprint 結束時，團隊都會完成一些可交付的東西。

Sprint 包含的流程分別為:

1. 衝刺計畫 (Sprint Planning): 在每個 Sprint 的開始，產品負責人會與開發團隊召開會議，說明這次要達成的目標與價值，並決定在這周期內要完成的事項，進行梳理與分配(Backlog refinement)。
2. Daily Scrum: 在衝刺計畫開始後的每一天，Scrum 成員需要每天在相同的時間與地點進行快速的會議 (通常會站著，目的是提升效率)，內容包含匯報工作進度，以及相互問問題，其目的是讓每個成員都能掌握最新的訊息，並即時給予協助。
3. 成果展示 (Sprint Review): 當 Sprint 結束時，Scrum 團隊會展示開發的成果，並與客戶討論以獲得回饋 (避免 "這不是我要的 !" 在最後才發生)。
4. 衝刺回顧 (Sprint Retrospective): Scrum 團隊共同檢視與回顧這次 Sprint 內的優缺點，改善並將 KnowHow 建立為 KM (Knowledge Management)，供下次改進 (以及未來其他專案的參考)。
5. 重新開啟新一輪的 Sprint。

Scrum Artifacts

Scrum 之中有幾個典型產物，分別為:

• 產品待辦清單 (Product Backlog): 是開發中已知的需求清單，會由 Product Owner 新增並排定優先順序 (常在成果展示後新增)
• 衝刺代辦清單 (Sprint Backlog): Scrum 團隊從 Product Backlog 取出在這一輪的 Sprint 要完成的清單
• 可交付的產品增量 (Increment): 可由顧客與團隊共同定義，通常是可執行的產品

其中我特別喜歡 Increment 這個單字，在 Scrum Guide 中有提到:

每個 Increment 都是之前的 Increments 經驗證後累積而成的

我們時常聽到開發團隊抱怨客戶不斷地更改需求，這時便可以觀察與反思，那些需求最終是否真的有使產品 "增量" 或提升價值? 如昨天的老闆不滿意飛機外觀的顏色，不斷地提出修改。

DevOps 與 Scrum 的共舞

說到這裡，大家是否能想像 DevOps 與 Scrum 之間能擦出怎樣的火花? 這裡簡單的舉一個例子:

每一次的 Sprint 開始時，開發團隊制定這一次要完成的需求與計畫，並在 Git 的主分支上開立一條 Feature 臨時分支(後續講解 Gitflow 時會補充)，且每天例行審視討論；

當 PG 完成開發後，PM 將分支合併到主分支中，並觸發自動化測試、編譯與發佈到 UAT 環境，團隊再邀請客戶共同審視成果 (可能是直接打開網站讓用戶操作)、檢討並擬定下一個 Sprint 的目標，不斷循環至專案結束。

今日總結

Scrum 是敏捷開發中的實踐框架，採用迭代的方式不斷達成可交付的產品增量
Scrum 以 Sprint 做為一個時間單位，過程的三個 Artifacts 會隨之迭代更新

終於，我們花了三天的時間介紹 DevOps、敏捷開發與 Scrum，明天，我們將正式規劃 ColorCodeTag 專案，並且創建 User Story。

另外 Ken Schwaber & Jeff Sutherland 在 The Scrum Guide 有特別提到，他們刻意的將 Scrum 框架留白，讓開發團隊能夠針對不同的情況，以不同的技術、流程及方法去實踐；也就是說其實上述的方法在不違背核心精神下，都是能夠調整應對的，例如 Daily Scrum 不一定要是 Stand Up Meeting，只要能達到高效與專注的目的即可。