另外去年十月終於在 Hahow 上把這篇所有內容，附帶實際案例和相關文件，更新並整理成影片，如果讀者想要更完整更清晰的圖片輔助，非常歡迎來觀看我在 Hahow 上的影片哦！
三、Scrum 流程案例演練（包含圖以及細節解釋）
上面文章雖然說明了很多名詞，但「做中學」總是理解最快的，因此，筆者將會提出一個案例，然後跟著上圖的流程一步一步的拆解，帶著大家一起完成一個簡單的 Scrum 敏捷開發流程。(如果有不懂的名詞和內容，可以回溯到上面的說明)
(一) 實際案例
- 專案內容：電子商務系統建置，包含首頁、商品頁面、會員頁面、購物車、結帳頁面、訂單頁面、後台頁面
- 專案時間：預期3個月開發完成
- 專案人數：0.5 位 PO, 1位Scrum Master,2位前端工程師,3位後端工程師
這裡以 Project 簽署完後為出發點，所以了解客戶的需求，接著便進行 Scrum 前的準備。
(二) 事前準備（事前準備後續會再寫一章更詳細的說明怎麼做比較好，才不會開發團隊開發的東西與 PO 和客戶要求的不一樣）
- Items 撰寫：第一個任務就是把原先專案內容定義的系統，根據不同的功能分配到不同的 Item ，Item 內容包含 User Story 或者其他必要的討論
- 規劃開發進度：雖然專案進度寫3個月開發完成，但細節定義之後可能會讓時間提前或延後，所以撰寫完 Item 之後必須要再審視一次預估期間，同時間最好把預計完成的各 Item 先擺到各個 Sprint 中
- Site map：強烈建議把所有規劃完的 Item 用 Site map表示，可以清楚的讓開發團隊知道整個網頁的脈絡，更進一步筆者推薦可以使用 Functional Map 混合(但這一塊牽扯到 UX 設計，筆者不會著墨太大)
4. 可視化管理工具：筆者這裡會使用 Trello 進行示範
(三) Scrum
- Product Backlog：請 PO 把 Item 按照開發優先順序排列，並把相關內容都放進卡片裡面，當有任何更動時候也記得要進行更新。
首先用 Trello 把整個版面進行切割，規劃出 Product Backlog, Sprint Backlog, To do, In Progress, Done, Potentially Shippable Product Increment, Available Hours，接著按照之前的說明，把所有功能都列到 Product Backlog。
Product Backlog 透過 A,B,C,D…把不同頁面分開，加上 1,2,3區別不同的 Item
另外在每個 Item 都加上描述，並以其他資訊補充更多該 Item的內容，減少與開發團隊之間的溝通(這裡以Amazon的頁面當作範例)。
如果專案上客戶有明確的視覺設定自然是最好，但如果沒有的話，在沒有設計師的情況之下，只能依賴前端工程師個人的能力去做網頁的視覺編排，此時會蠻容易造成視覺不統一的情況，因此建議在製作Item時候，也能一併請UI一併進來一起撰寫 Item(後續會寫一篇融合 UI/UX 設計的敏捷開發如何運行)
2. Product Backlog Refinement(10% Sprint = 8小時)
在 Sprint 之間會固定有 PBR 的活動，由 PO 對開發團隊進行 Item 的說明以及討論，但在整個 Scrum 開始之前，建議可以有一次全面性的講解，從 Sitemap 細講到各個 Item 內容，釐清雙方的認知差異和功能細節，才會令後續的 Sprint 流程和產出更加順利，減少溝通成本。
所以這裡講解專案簽約內容和目前開發的計劃與進度，讓大家的目標一致，那因為會把所有的需求都講過一遍，再加上之後每次 Sprint 中間也會有需求的變更，因此在梳理的會議上時間通常比較長。
(四) Sprint：以2周為一次 Sprint
開始 Sprint 前，PO, Scrum Master 和開發團隊的資深工程師(Leader)必須商討 Sprint 的長度以及2周估算的可能工作量，在經過第一次PRB之後應該能粗略計算這些項目。
此專案假設以2周為一次Sprint，總共有6名開發人員，2周總共有80*5=400 hrs 的開發時數，除以8之後，以2周總共能開發50 points為上限
1. Sprint Planning Meeting Part 1(2小時)
由 PO 說明接下來可能會被放入此次 Sprint 的 Item，並詳細將敘述和 Acceptance Criteria 內容講解給開發團隊聽。
2. Sprint Planning Meeting Part 2(2小時)
(1) 評分：接著開始針對每個 Item 進行評分，除了上面提供的方法之外，另一個可行的方法如下圖，將所有 Item 從小到大分數進行排列，接著進行 Group 式的評分，會讓整個效率提升很多。
另外要注意的一點是，當Sprint開始第二週了，所有已經被評分過的 Item必須要重新評分，因為隨著開發的進度和客戶因素，通常 Item 的內容和細節會越來越清晰，讓開發團隊的評估也會越來越準確。
(2) 分配 Item 至 Sprint：根據50分的限制，並依照由上到下挑選Item。同時會把左上角的標題進行更動，還有會在標題的ID加上”-Sprint期數”，用來快速標示哪個 Item 何時被指派，何時完成等等。
(3) 拆解 Task：讓工程師們自行拆解需要的卡片，可以標註職能，並附加相關檔案上去讓工程師觀看詳細內容。
(4) 指派 Owner：採取認領方式，時數請負責人直接預估。而在拆分的每個 Task 筆者會請工程師在每樣Task上加上三個訊息，(預估時數/實際時數)-負責人，如此除了可以協助工程師未來判斷Task工持更加準確，也能讓PO知道這樣的功能跟原本預期的花費時數有沒有落差。
然後把 Task 內容拆出來，直接放到 To do，等到標記完人員和時數之後，就可以開始移動到 In Progress (Trello有提供 Label 和Assign功能，前者可以標記職能，後者直接指定負責人。)
那因為是示範的關係，所以這邊只有拆 A1–1 的卡片，基本上在這個會議要把所有的 Item 都拆成最小開發任務讓開發團隊進行開發 (這裏就要抱怨 Trello 的缺點了，因為他無法平行的讓一張 Item 對到特定的幾個任務，所以有時候會有點小混亂，所以如果實際的辦公室有牆面可以使用，那非常建議直接手寫用便條紙進行，會比較好觀瞻，另一個建議就是可以使用中國的 https://www.leangoo.com/，從 Trello 改編成完全 Scrum 專用版本）
記得注意分配的負責人不要超過2周80小時，如果工程師資源有共用的狀況，筆者通常會再額外增加 Available Hours 掌握開發團隊的可開發時數，用以調整每次 Sprint 的開發進度與內容
3. Sprint Start(2周)
(1) Sprint Backlog：參考上圖資訊，同時工程師開始移動 Task 到對應的狀態
當要開始進入 Test Backlog 的時候就會需要測試人員，這邊只針對完整的 Item(包含 Function 和 Bug)進行測試，通常有幾種選項 (1) 由PO測試 (2)找公司測試人員幫忙 (3) 外包人力 (4) 工程師自行測試，根據不同情境選擇不同的項目，之前筆者為了衝產品的功能，所以採用了 (2) ，但基本上依照敏捷的精神來說，應該是要採用 (4)，如果 PO 有餘力可以採用，但如果特殊情形就能採用(3)
（補充一下為何會把測試部分特別拉開，首先 Story 的測試並不是每天都會有的，等有的時候再請測試工程師協助即可。並且專職職能工程師應當花費在自己最擅長的事情上面增加效率(例如不要請數據科學家來做測試，開發功能進度上反而少了一定時數)，當然這也是筆者當初額外拉出來的想法分享，實際還是依照狀況進行變動）
另外如果有遇到 Item 在測試過程當中有問題，要把加上相對應的 Bug 到 Product Backlog，以下列圖為舉例
如果 Bug 問題很小，通常工程師會很快接手去解決，希望放越多的 Item 到Potentially Shippable Product Increment ，假設太大就把它移動到 Product Backlog，等到新一輪的 Sprint 進行評分並且指派。
另外記得提醒開發團隊每日幾點前更新 Sprint Wall 上面的進度，現實情況常常工程師會忘了要移動卡片，還有要更新目前在該 Task 上花了幾個小時，以及剩下預計剩下的小時數，才能讓 Burndown Chart 有進度。
(2) Daily Scrum：每日早上15分鐘，團隊選出一個共識時間，例如每天早上10:00
(3) Product Backlog Refinement (10% Sprint)：通常筆者會選在每周三的下午進行 Product Backlog 的更新解說，時間不夠就會再延長到週四早上。
(4) Burndown Chart：基本上在燃盡圖的指標上有多種不同的標的，例如待辦事項的預估分數(pts)、開發任務的數量、開發任務的預估時數等等
而筆者建議把開發任務數量作為 Burndown Chart 的基準，原因如下
一、每天有進度，團隊才認為開發有往前進的感覺；如果是以 Item 為主，大部分都需要 1–2天才有進度，對於開發團隊來說如果每天沒有一步一步往前的成就感，士氣有可能在隱形之中悄悄的受到打擊。
二、如果以預估小時為主，那基本上就算一天半個任務都沒有完成，團隊也認為我們現在開發進度很順利（因為指標一直下降），可是其實不然，在燃盡圖另外一個意義就是讓相關成員們了解目前開發有沒有遇到什麼瓶頸需要協助。
4. Sprint End
(1) Potentially Shippable Product Increment：經過測試之後可上線的 Item。
這邊要提到另外一個開發流程的環節「部署」，通常軟體開發會分成「RD開發者環境」、「測試環境」、「正式環境」(通常還會有使用者測試環境，關於測試部分會再額外另立一個文章說明)，而每一個環境都會對應「軟體版本」，這個版本必須要跟部署的開發人員溝通要怎麼制定。
假設是以敏捷開發的方式來的話，依照筆者經驗會這樣設計 [ va.b.c]，a代表正式上線的版本，b代表每次 Sprint 更新後的版本，c代表每日更新的版本(部署更新時間通常為每天的下班前或者剛開始上班之時)，同時要請開發人員就每次更新版本撰寫修改內容，才不會造成某Bug已經解除，測試人員還在等待。
(2) Sprint Review(2小時)：由PO根據可上線的功能進行測試互動，並與開發團隊互相溝通理解開發狀況與功能細節。
(3) Sprint Retrospective(2小時)：回顧整個 Sprint 好的地方與可以改進更好的地方，讓每一次的 Sprint 運作的更加順利。結束之後，隔週一早上再回到 Sprint Plan Meeting Part 1繼續重複把 Product Backlog 的項目開發完成。
四、總結
感謝讀者看完上面一萬初頭個字的解說，以上很多都是筆者和訪問過實際使用敏捷軟體開發人員的心得，搭配圖片、文件還有實際範例，希望讓讀者可以深刻的理解使用場景。
而不同的專案有不一樣的調整方法，也許不會用一樣的格式，也許不會用一樣流程，但只要掌握敏捷開發的中心思想，你都可以稱作自己是在運行「敏捷開發」。
五、其他補充與建議
- 其實 Scrum 不僅僅能使用在軟體開發工程，實際上任何地方都可以使用，舉凡有人利用此方式進行減肥甚至是完成行銷活動等等，
2. 在真實運行 Scrum 情況之下，其實很常發生開發團隊無法交付所有 Sprint Planning 承諾的待辦事項，此時要深入了解問題，而問題不外乎會有幾個
(1) Item 估算錯誤：必須理解為何估算太低，下次遇到類似代辦事項要怎麼去評估才合理。
(2) 額外未列出項目：開發團隊會負責其他除了撰寫程式以外項目（例如尋找更快的方法、架構、或者撰寫文件、測試等等），此時也要把這些沒有列出的 Task 或 Item 告知 PO 列出，才能更準確的評估可交付項目。
基本上只要運行時間拉長，團隊們會知道如何去解決和協調這些事情，並且必定部分會做到跨職能的工作。
