Scrum 的那些事 Part 2：今天，我們來聊聊 scrum
既然上一篇已經介紹過了 Scrum / Agile 的起源，以及對照 Waterfall 的一些差異。
這篇就直接來聊聊 Scrum，以及 Scrum 到底提供了怎樣具體的方法來做到敏捷式開發的核心價值
SCRUM Process
這張圖很清楚了表達整個 scrum 的核心流程：
- 把產品的核心 Vision 切分成多個可描述的 User Story，然後放到 Product backlog 中
- 每一次迭代，從中提取出最重要（市場價值）的部分放入 Sprint backlog
- 團隊經過討論，根據需求內容與團隊的可用資源，適時的調整（增/減）Sprint backlog 的內容
- 在 2~4週的 Sprint 中，每天透過 Daily Standup 來確保開發進度
- 在每次 Sprint 後，都有一個可上線的產品（疊加於之前的迭代版本）
並且依照這個流程不段迭代，因應市場變化不斷的調整 Product backlog 中的內容與優先級。
並確保在每次 Sprint 前都能夠提取當前最重要的項目優先開發。
Scrum 中的角色
在 Scrum 的流程中，其實只有3種明確的角色
- Product owner
產品的負責人，基本上對於用戶/客戶負責，並且能夠最終決定 Product backlog 中項目的優先級 - Scrum master
Scrum 流程的負責人，確保整個團隊在開發過程中，能夠有效率的依照 Agile 的精神運作，原則上與產品的成敗無關 - Teams
其他不屬於 PO / Scrum master 的人員都屬於團隊成員，負責具體的討論/設計/開發/測試，當團隊間意見有分歧的時候，再由 Product Owner 來仲裁，同時要負責產品的時程與品質把控。
很多人會把 Scrum master 跟 Product Owner 或是 PM 搞混，Scrum master 基本上是對團隊負責(PO 與 PM 主要是對產品負責)，確保團隊能夠在符合 Agile 的精神下，發揮最大戰力。 並且適時的針對團隊/產品特性調整流程上的節奏與細節
核心元素
User Story / Task
User Story / Task 作為一個產品的最小單位，他的定義與拆分非常重要。
首先，他的切分顆粒大小必須適中。 不能太大以至於無法有效追蹤與拆分，但是也不用小到雞毛蒜皮，這樣管理起來瑣碎又沒效率（因為太多類似的項目需要被管理）
其次，大致程度上每一個 User Story / Task 都要能夠獨立於彼此，這樣才能確保在 Sprint Planning 的時候，能夠盡可能的任意組合 User Story 就能拼湊出一個可交付的產品。原則上，一個能讓 User 完整走完一個具有商業價值的流程，才能算是一個 User Story。
一個 User Story 的基本架構如圖，裡面必須描述到 目標對象、行為流程 以及 商業價值
另外，還需要符合以下特性（用以方便管理與檢驗）
- 獨立性：
如上面所說，盡可能確保每個 User Story 都各自獨立，這樣才能被自由組合 - 可溝通 / 調整：
User Story 敘述中盡量要保留可協商的空間，而不要把規格定義的太死，不然如果寫的太死，到時候在 Planning 或是預估工作量時，可能會因為沒有空間，而導致一直無法被排入開發，或是人力與時間資源無法有效運用 - 有價值的：
一個功能，必須有它存在的價值，而盡可能避免單純個人喜好或是特殊偏好而無意義的流程/功能 - 可估算的：
某種程度要足夠具體，讓開發團隊能夠從中理解這個功能的流程與目的，進而能夠進行設計以及技術選擇 - 適當的顆粒大小：
同上，適當的顆粒大小，但是有時候這部分只要足夠彈性，很多時候可以在後續 Planning meeting 的時候進行適當拆分與合併 - 可驗證 / 可測試性：
一個功能，要有足夠明確的目的與可驗收的標準
另外，在完善 User Story 的時候，團隊成員要不停的進行討論與檢視，討論出 User Story 的兩個關鍵資訊：
DoR 表示什麼樣的資訊（從需求方來），足夠讓這個 User Story 能夠進行設計以及開發，而不會做一半會被外部依賴卡住。比方說：明確的需求定義、外部依賴的相關權限等
DoD 表示什麼樣的成品（從開發團隊交付），足夠讓產品/市場端接受，裡面包含了可能了Functional / Non-Functional 的驗收標準，例如功能需求、目標數量級、性能要求、安全性需求等
Product / Spring Backlog
將能夠描述產品所有功能的部分，拆分成 User Story 後，全部都放入 Product Backlog，並且讓全部的團隊成員都能夠看得到。
某種意義上來說，Product Backlog 裡面的項目全部做完後，就可以說這個產品已經完美了。
但是實務上，不可能會有完美的產品，一定會有因應市場變化所需要的新功能，或是過去版本所遺留下來的 Bug，或是因應用戶成長後的效能調校，這些都會是在 product backlog 的一部分。
但是如何有效的經過團隊討論/PO仲裁後，決定出符合當前市場環境/產品 Roadmap最重要的項目，並且排入 Sprint Backlog
然後在 Planning meeting 中確認 backlog 的內容，根據實際的內容/工作量與目前團隊的人力/時間資源適度的調整（增/減） Sprint backlog 內容
團隊在迭代開發中，必須專注於 Sprint Backlog 的項目，並積極把它完成。
這裡的一個核心重點在於， Product Backlog 是能夠隨時根據市場變化，產品設計的需求而動態去增減，或是調整優先級。
但是 Sprint Backlog 一但確定並且已經進入 Sprint 週期後，原則上是不能改變的，因為 Scrum 基本上能確保產品能夠快速反應變化的兩個大前提就是：
- 產品功能能夠很明確地被拆分為各自獨立的多個 User Story / Task
- 在開發迭代中的 Sprint backlog 中的 User Story / Task 不會異動
因為所有的 Planning meeting / Daily Standup 都是依照著固定的 Sprint Backlog 進行反覆討論以及確認才開始 Sprint 的，所以如果必須要改變的話，必須要在 scrum team 充分討論，並且明確理解改動後的風險是否能夠承擔，以及時程以及人力資源是否有要調整。 團隊成員都確認後才能夠調整。
實務中最困難的也是這部分，因為這部分需要公司老闆以及 PO 有對 Scrum 的正確理解與堅持，以及良好的溝通和談判技巧。很多時候在市場利益的驅動下，客戶或是來自老闆的壓力使然下， 需求內容還是會三天一小變，五天一大變 （傳說中的 隕石式開發！）
Burn down chart / Story Point
這個主要是讓 PO 或是管理階層，能夠在最不打擾開發團隊的情況下，快速掌握團隊的開發進度以及後續的團隊評估的一個重要工具！
專案進度能夠被掌握的一個重點：如何用一個有效的系統來正確的呈現目前團隊的工作進度？
Burn down chart / Story Point 就是一個有效的設計（前提是團隊成員都認真的預估點數與正確的反應 User Story 的狀態）
具體作法為團隊成員為每一個 User Story / Task 決定出一個指標性的 Story Point 來代表這項功能的複雜程度（具體作法/投票等這邊就不展開了....）
基本上 0 代表已經完成了，不需要消耗任何人力（有時候是一些特殊 Task / User Story 會出現 0 點，或是在 Sprint 之外偷跑所以已經完成了）
但是如果一個 Story / Task 點數超過了 13 / 20，某種程度代表了這個 Story 需要被拆分成更小，這樣才適合被追蹤（不然一個 Sprint 就跑一個 Task，然後點數 100 的話也無法有效追蹤...）
相對適中的 User Story 顆粒大小，點數應該介於 3~10 點左右
每個 Story / Task 都有點數之後，就能夠在每個 Sprint 之中的每一天，透過目前還剩下多少點數還沒完成，來畫出 Burn-down chart
並且能夠透過參考線，隨時能夠了解團隊目前的工作速率，是否太慢與太快
這個系統有幾項好處：
- Sprint 中每天能追蹤團隊的工作速率
- 跑了幾個 Sprint 後，能夠具體的了解目前這個團隊一個 Sprint 大概能消耗多少點數（前提是點數預估的標準要保持一致）
- 在未來 Planning meeting 時，如果計畫了一個 Sprint Backlog，很快就能評估出這個 sprint 是否能如期消化完，太少可以再加，太多可以減少（或是要加班....）
- 團隊成員每個人各別的工作效率（雖然不是每個人的標準都一致，但是至少可以跟自己的每一個 Sprint 來比較）
主要活動（Activities）
Planning
Sprint 開始前，團隊成員針對目前的 Product Backlog，當中滿足 DoR 的項目，根據當前的優先級，提取出最重要的項目，排入暫時的 Sprint Backlog
接著討論細節並進行初步的設計，並且預估點數。
然後根據當前 Sprint Backlog 中的總點數，評估是否已經滿載，如果太少，那就再挑選優先級次高的項目。如果太多，就根據當前的項目將相對優先級較低的項目移除。
全部人都做最後的確認，讓團隊中每個人都明確的知道接下來的 Sprint 要做什麼，也讓 PO/PM 知道這個迭代完成後，將會交付什麼樣的功能與產品（不多做也不少做）
不多做也不少做這個概念很重要，因為這個是團隊成員全體確認，並且承諾的項目。 必須在 Sprint 結束後如期交付，減少意料之外的改動與變化。
這部分其實是 Scrum team 與客戶/用戶之間建立信任的關鍵。
每次 Sprint 都能夠如期/高品質的交付，能夠建立客戶/用戶的信任，這樣也讓開發團隊更有理由去說服客戶不要在 Sprint 過程中去變動 Sprint backlog 的內容
Daily standup
在 Sprint 中的每一天（最好是一早），對整個團隊成員的一次集體 sync-up meeting。目標必須控制在 15分鐘內！
由於已經有 Sprint planning 的計畫與進度，所以 Stand-up meeting 的重點在於每個人的都能夠讓團隊成員知道他目前的進度是否正常，是否在前一天有發生預期之外的狀況？ 是否會影響到自己/別人的工作？是否有東西卡住自己的工作需要被解決？
要把會議控制在15分鐘內，有兩個很重要的關鍵：
- 雖然是要描述「我昨天完成了什麼，以及今天預計要完成什麼」，但是盡量只陳述跟 Sprint 內容有關的東西，而不要開始報告你昨天的生活日記流水帳....
- 遇到有人提出問題時，只在會議中找出可以幫你解決問題的人，但是不要在會議中解決問題！
因為這個會議會是全體成員共同參與，所以如何避免浪費大家時間是一個關鍵。
Sync-up 每個人的進度，以及提出可能的意外以及變化。 但是不要讓全部人站在那邊看著少數幾個人在討論他們自己的問題
Review
Sprint 的最後，要讓 PO 或甚至客戶/需求代表方展示這次 Sprint 的成果/產品，並且讓 release 團隊知道如何讓這個產品後續能夠上線道市場端。
由於 PO、客戶/需求代表方不一定會參與到每天的開發，頂多只有在 Planning meeting 的時候知道你們這個迭代「預計」要做什麼。
但是具體「完成」了什麼，如何完成的，也要到 Review meeting 的時候才會真正看到。
也讓團隊成員知道，除了「完成」了什麼，同時也「遺留下」了什麼（未完成的 User Story、Known Issue 等）
Retrospective
這部分是 Scrum 的一個核心之一，能夠幫助團隊更有效的提升效率以及能力。但也是最容易被忽略或是誤用的環節。
Review meeting 主要是面對 PO/客戶端，確認產品是否有如期完成，屬於對外的屬性。
但是，對於團隊內部，雖然產品交付了，但是這個過程是否順利？ 還是其實是每個人吐血加班爆肝完成的？ 這個就只有團隊內部才知道了。
所以這個 Retrospective 主要會是由 Scrum Master 來主持，目的在於有效的回顧這次 Sprint 過程中，是否有哪些環節能夠改善？
找出 What should we Start / Stop / Keep doing 的細節。 例如：
- 是否在 Planning meeting 時過於樂觀/悲觀的安排 Sprint backlog？
- 每天的 Stand-up meeting 是否太冗長？
- 是否有外部不可控的因素，需要事先被管理？
- 成員之間的溝通是否足夠有效率？
- 是否使用了某個工具，大家都覺得好棒棒，應該繼續使用
重點在於如何讓這個會議，盡可能對事不對人並有建設性的進行。 而不要演變成對人不對事的批鬥/抓戰犯大會。
實務經驗
最後，提一下我自己這幾年參與開發團隊的經驗。
雖然上面提到了很多 Scrum 的優點與特性。但是事實上，很多團隊（特別是台灣的團隊）其實是不適合單純的就這樣導入 Scrum。
硬要導入的後果就是團隊變得更沒效率。花在會議的時間更多，做事的時間更少。 整體產出還不如 Waterfall 來得有效率。
如果想要導入上面所述的 Scrum，可以先思考一下下面列出的幾個問題
- 團隊對於產品是否有一定的決定權：決定需求、功能、時程 （這裡的團隊不包含老闆，除非老闆也參與在 Scrum team 擔任 PO）
- 團隊成員對於 Scrum 有一定的理解與認知，或至少能接受相同的教育訓練
- 接下來最重要的一點，團隊成員是否能夠互補？
第三點解釋一下，Scrum 的核心精神在於，以達成 User Story 會最高原則，而不侷限於 How or Who。
所以舉例現在有一個 User Story 如下：
As a user, I should be able to login to the system with correct Account/Password to access services
當團隊接收到這個 User Story 的時候，會有兩種情況
Case A
團隊成員中的分工明確，所以這個需求需要
- 由 PO/PM 先確認功能細節
- 交由 UI/UX 設計 Flow 與畫面
- SA 進行系統架構設計
- 給 Developer 進行開發
- QA 部門進行測試
最後完成產品交付
Case B
團隊成員任何人，都能夠針對此功能進行基本的設計與實作，當然某部分都會有對應的專業部門，但是不限定只有那個部門可以完成。
Developer 也可以進行初步的流程設計、架構設計， Designer 也可以 coding 或是測試，QA 也能協助設計。
團隊之間每個人的功能都能夠互補，都能以 60~80% 左右的比例完成其相關專業部門能做到的程度。
確保整個團隊在 Sprint 開發過程中能夠一氣呵成，就算介面/流程設計不是由 UI/UX 部門的人完成，就算程式碼不是由 Developer team 寫的，就算測試是由 PM 或甚至 Developer 內自行測試。
但是都能夠符合 User Story 中所定義的需求，以及達到其商業目的。 並且設計/實作品質又能夠達到上線市場的水平。
如果針對前兩個問題的答案都是否定的。
並且第三個問題無法在短時間達到 Case B 的水平的話，那其實這個團隊要真正導入 Scrum 後，會跑得非常辛苦.....
但是這也不是世界末日，業界中還是有一些變形的混合式開發模式，也是下一篇要介紹的 Water-Scrum-fall 模式
