既然上一篇已經介紹過了 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 (PO)
產品的負責人,基本上對於用戶/客戶負責,並且能夠最終決定 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 模式