談到「敏捷開發」很多人就會聯想到 Scrum。的確 Scrum 是敏捷管理產品開發的架構之一，它能幫助團隊解決複雜、困難的問題，同時提升開發速度，創造更多的價值。
Scrum 這個詞則是源自於橄欖球 (Rugby) 中的術語：
A scrum (short for scrummage) is a method of restarting play in rugby that involves players packing closely together
文字與圖片來源：Wikipedia
就像圖片那樣，指的是重新發球時選手會排成陣列緊密靠在一起，在裡頭進行搶球。
Scrum 的精神
1986 年，兩位日本教授竹內弘高與野中郁次郎，在哈佛商業評論發表了「The New New Product Development Game」文章以及關於新的產品開發管理研究。
在文中他們提到，有別於過去「大隊接力」般的開發團隊，新的開發團隊就好像橄欖球隊一樣，從比賽的最一開始「一起努力」到最後，在團隊內部成員們「不斷地互相傳球」，同時整個團隊在賽場上又是「隨時變化進攻策略」、「一步步向前推進」直到達陣。
和敏捷精神一樣，Scrum 並不是某個人在某個特別的時間點發明出來的，早在 Scrum 這個詞出來之前，已有許多團隊嘗試執行這種新的管理方式，而如今你看到的 Scrum，更是過去團隊的努力與經驗累積。
現在就讓我們來介紹如何將 Scrum 應用在軟體產品的開發上。
如何用 Scrum 管理專案？
Scrum 是一個全面的產品開發架構。從團隊組合、協助模式、到文件的格式，都有清楚的設計目的與描述。
在 Scrum 中，通常以 1-4 週為一個開發週期，這個週期稱作 sprint，也就是快速衝刺的意思。在一個 sprint 當中，開發團隊必須要在限定的時間之內，完成計畫目標。
透過每一次的 sprint，開發團隊將快速發布可運作的產品去測試市場反應，收集關於產品的回饋，然後持續調整產品的開發方向，最終目標是打造最能滿足客戶需求的產品。
接下來，我們帶你一一認識 Scrum 架構中的人物角色、物件與流程。
Scrum 的人物、物件、與流程
圖片來源：Scrum.org
人物角色
在 Scrum 裡，有三個主要的角色：
1. 產品擁有者 (Product Owner)
Product owner 代表客戶參與開發流程，確保開發團隊的產品符合客戶需求。
Product owner 負責規劃使用者故事，並與開發團隊討論，決定產品功能開發的優先順序。在開發過程中，協助開發團隊釐清產品需求，同時，product owner 也負責整合客戶的意見、使用者的回饋，做為未來改善產品的基礎。
2. Scrum Master
Scrum Master 負責確保開發團隊依照 Scrum 的方式進行產品開發，並排除任何會影響 Scrum 流程的障礙，協助改善開發流程。Scrum Master 不是以「領導者」的姿態帶領專案，而是 Scrum 規則的「執行者」。
3. 開發團隊 (Development Team)
開發團隊負責開發與交付產品。開發團隊為跨領域團隊，可由設計師、工程師等不同的專業人士所組成。
以上這三個角色是 Scrum 裡的有權限做事的人，其他與專案相關但沒有實際參與的角色被統稱為 Stakeholder（利益關係者），可能是客戶、使用者或任何人，至多只能觀察產品並給意見，不能干擾開發過程及決策。
文物 (artifacts)
在執行 Scrum 時，需要準備一系列文件 (英文稱為 artifacts)。不同的團隊會根據他們的開發環境跟習慣選擇不同的文件，一般來說會包括以下幾種：
1. 使用者故事 (user stories)
由 Product owner 負責規劃，做為以使用者為核心的開發基礎。
2. Task-board
由開發團隊根據使用者故事，列出所有需要被完成的任務，然後分配給開發團隊的成員。
3. Product backlog
Product backlog 為產品待辦清單，包含了所有需要被完成的使用者故事。Product owner 會決定開發的優先順序。
4. Sprint backlog
Sprint backlog 為衝刺待辦清單，列出開發團隊需要在一個 sprint 裡完成的開發目標。
5. Burndown chart
Scrum 團隊在開發過程中，會每日追蹤進度，將未完成 Task 的剩餘工時加總起來，再依照日期紀錄下來，然後跟專案一開始的時程計劃作比較，便能得到一張長得像這樣的 burndown chart：
圖片來源：eLearning Industry
在上圖，淺藍色線是計專案一開始時預估的時程，單純把 task 的總時數除以專案的天數。綠色線是實際進度紀錄。這兩條線幾乎是不可能一樣的。製作 burndown chart 的目的，是讓團隊了解這個 Sprint 的進度狀況，以及還有多少小時的 Task 要完成。如果進度受到嚴重的阻礙，團隊就要及早作出應對和調整。
活動
衝刺規劃會議 (Sprint Planning Meeting)
在每個 sprint 開始的第一天，團隊全體成員都需要參與這個會議，討論這次 sprint 的開發目標。Product owner 決定開發的優先順序，而開發團隊可以決定要完成多少的開發量。
圖片來源：Shutterstock
每日衝刺會議 (Daily Scrum)
在 sprint 當中的每一天，都得召開衝刺會議，約 10- 15 分鐘，由 Scrum Master 主持，確保會議時間不會過長與失焦。為了簡短會議時間、讓大家保持專注，通常會站著開會，因此也稱作 stand-up meeting。
在會議中，開發團隊成員須報告三件事：
- 昨天完成的工作
- 今天準備要做的工作
- 是否遇到任何阻礙，需要請求幫忙？
衝刺檢視會議 (Sprint Review Meeting)
在 sprint 的最後一天舉辦，除團隊所有人需要參加之外，也可邀請 stakeholders 參與。開發團隊將展示開發「成果」並讓 product owner 驗收，團隊藉此檢視產品是否需要調整。
衝刺自省會議 (Sprint Retrospective Meeting)
在 sprint 結束後召開，跟 sprint review meeting 不同的地方是，這個會議回顧與檢視 Scrum 開發「流程」，看看是否有需要改善的地方。
Scrum 的核心價值
在介紹完 Scrum 的架構之後，最後我們來看看執行 Scrum 所需要的核心價值：
1. 專注
在 sprint 期間，Scrum Master 會協助排除所有的外在干擾，因此開發團隊必須心無旁騖地全力開發產品，發揮最大的潛能。
2. 勇氣
在 Scrum 中以團隊為單位，為了共同完成目標，團隊成員之間會互相學習、支持，會比單打獨鬥的開發者更有勇氣面對困難的挑戰。
3. 開放
跨領域的成員在同一個團隊裡面一起工作，而非分散在企業大樓的不同角落，促成了開放溝通、學習的機會，讓產品開發更為順利。
4. 承諾
為了完成目標， Scrum 團隊裡面的成員都要有很強的自主性，承諾完成被分配的任務，才能推動一起團隊前進。
5. 尊重
所有成員一同分享團隊的成功與失敗，因此得尊重彼此不同的意見，並互相給予協助，才能共同完成目標。
Scrum 中的敏捷精神
Scrum 在許多方面體現了敏捷精神，在流程上，強調快速發布可運作的產品，以及持續收集回饋並改善；在團隊上，強調每位成員須具備積極的心態與承諾，在相互尊重下以開放的溝通提升產品開發效率。
在下一個單元裡，我們將談到適合 Scrum 的使用情境，以及你可以如何在未來的專案中使用 Scrum。
雖然 Scrum 有較為完整的架構，但一樣有其適合使用情境以及局限性，我們列出了一些常見的陷阱讓你觀摩：
Scrum 適合的使用情境
產品需求不明確
當產品需求不明確時，團隊可以透過 Scrum 快速發布產品、盡快驗證需求，並能夠與客戶、利益關係者緊密合作。
產品需要快速迭代
Scrum 的框架可以容納不同專業的成員緊密合作，像是使用者體驗研究員、介面設計師、程式開發者、行銷人員等，並且有定期的共同會議聚焦團隊方向。
Scrum 不適合的使用情境
團隊成員分處多地
由於 Scrum 流程強調團隊的密切合作與即時溝通，若有成員採取遠距工作的方式，那麼就容易降低團隊溝通的效率，或造成資訊不對稱。
團隊成員習慣被動等待指令
Scrum 強調團隊合作，專案依賴每一位成員的積極性與解決問題的能力。若有成員不夠積極主動，那麼就會降低 Scrum 的整體效果。
開發過程需大量依賴外在資源
當開發團隊無法獨立完成產品開發，得依賴較多外在資源或條件時，就難以執行 Scrum。
使用 Scrum 時常見的問題
Sprint 目標設定太高
設定困難的目標，可以驅使 Scrum 團隊發揮最大潛力，而偶爾無法達到目標也是可以接受的。但如果時常無法達成目標，那麼就要進一步去思考，目標是不是真的太困難了，又或者是否需要調整團隊組成。
會議失焦
每天的衝刺會議的重點在於凝聚團隊、排除困難，若流於流水帳式的報告，那麼就會失去它的意義。
無法排除的外在阻礙
在執行 sprint 的時候，Scrum Master 會協助排除外在影響因素，但實際上有時候可能會出現緊急狀況，無法等到下一次的衝刺規劃會議才排入開發。團隊可能需要做合適的調整 ，譬如指派一名「救兵」在 sprint 進行中處理緊急狀況，以因應快速變化的狀況。
團隊成員疲乏
最後，在 sprint 時間限制的壓力下，加上高度專注，雖然產能會大大提升，但也容易導致團隊成員身心的疲累。所以在使用 Scrum 高速開發的同時，也要緊密注意團隊的狀況。
Kanban
透過 Scrum，你可能對於「敏捷」的精神有了更深一些的暸解。除了應用在管理團隊工作流程的 Scrum 之外，我們還要向你介紹另一個非常實用且常見的工具——Kanban，它除了有助於將敏捷精神導入產品開發流程之外，也能被應用在你的日常生活中呢！
Kanban 方法，是一個不斷改進生產流程、減少資源浪費的管理方法。而 Kanban 這個詞，是源自於日文 かんばん（看板）。
Kanban 方法的六大原則
- 視覺化作業流程
- 限制半成品（WIP）的數量
- 監控與管理作業流程
- 建立明確的規則
- 建立良好的訊息回饋路徑
- 團隊間相互合作，帶著實驗精神展開持續的改善
適合的使用Kanban的情境
有明確的產品開發階段
在進行開發以前，你必須先定義好看板中的各個欄位，像是 To Do、Design、Programming、Testing、Deploy、Done 等等。所以這就代表，開發團隊已經很明確知道開發流程，並且不會隨意更動。
線性前進的產品開發階段
根據 Kanban 的使用規則，使用者故事只能由左邊移動至右邊，而由右邊至左邊的反向移動是不被允許的。若一個團隊的工作模式沒有明確線性的開發流程，產品需要透過不同的參與者，多次來回進行開發、討論、調整，那麼 Kanban 方法可能就不能提供幫助。
使用 Kanban 可能遇到的問題
有時候團隊覺得 Kanban 方法沒有效果，可能的問題在於：
- 看板並沒有真實呈現實際的開發流程
- 卡片的資訊與位置並沒有及時更新
- 沒有遵守 Kanban 的實作原則，像是隨意移動卡片、或是沒有遵守 WIP 的數量限制
最糟的情況，就是團隊成員並沒有瞭解 Kanban 的精神，不思考如何減少浪費提升效率，不主動協助其他成員，不持續改進追求卓越。
不過，所有工具都是人設計出來的，Kanban 也不是一個完全鎖死、不得被改變與修正的方法。你會發現許多的團隊為了因應自己本身的開發條件與狀況，在使用 Kanban 方法時做了不同的調整。最重要的，還是發揮敏捷精神，適時調整團隊之間合作的方法，持續追求進步。
ALPHA Camp 的 Simple Twitter 專案實戰
Simple Twitter 專案是【全端網路開發課程】的最後一項里程碑，呼應到「模擬實戰」的設計理念，在此專案中，你會需要運用敏捷開發「綜合運用全部所學，在多人協作下，交付出符合需求的 app」。
成功關鍵在於：
- 在任務導向的情境中，體驗實務的「軟體開發流程」
- 透過小組分工來完成任務，克服多人協作下的任務調度與程式碼管理
