從 Scrum 到 LeSS －使用者故事（二）
前一篇寫了關於 Story 應該如何產生
接著 當 Story 被確定下來之後
要如何切割 Story
讓他們可以在 Sprint 期間能 Done
0x00 回顧
過去經驗我們都知道
當 Story 太大的時候要拆小
但問題就來了
小要小到多小
有可能小到 Task 嗎？
此時也會有聲音是
「噢！Story 就要 End-to-End 的拆解」
那什麼是 End-to-End
如果寫了一個 API 加上 Swagger UI
有網頁可以操作 DB 的 CRUD
這樣算是 End-to-End 嗎？
如果真的要實現 Story 的 Feature 有困難
能不能先有 Proof of Concept (PoC) 的 Story
畢竟 PoC 也能 End-to-End 呀？
0x01 When to Split Story
Story 確定下來了
什麼時候需要再拆小呢？
從前篇我們知道釐清 Story 細節是在 PBR 的時候
那麼拆 Story 通常會是在 Sprint Planning I 的時候
課堂上對於 Story 要拆多小的建議
是從 Sprint 的角度去看的
以一個 Sprint 可以完成 3 至 4 個 Story 為度量
因此 Story 太大或太小就能以 Sprint 長度
以及該 Sprint 的人時來評估是否該拆
0x02 How to Split
那麼接下來就是如果需要拆
一個好的拆解要怎麼評估呢？
在課堂上給了 3V 作為評量拆解的 Story 是不是好的拆解
- Vertical
- Visible
- Valuable
Vertical
可以想像一下整個軟體的層次
就像一個漢堡 🍔
一層層堆疊起來
簡單一點的版本像是
UI
Application
Data Storage
那什麼是 Vertical ?
當你把漢堡咬一口是不是什麼都吃到了？
這就對了！
Vertical 的意思就是
不要把 UI, Application, Data Storage 拆開
吃漢堡的時候總不會想要把
麵包🥯
生菜🥗
起司🧀
肉 🥓
分開來吃吧！
但拆解之後就沒辦法交付給 User 用了怎麼辦？
首先回顧一下 Story 被完成時須要交付的是
Potentially Shippable Product Increment
Potentially shippable is a statement about the quality of the software and not about the value or the marketability of the software
ref: Potentially Shippable Product Increment
因此拆解後的 Story 並不是要求一定要能直接交付出去給客戶價值
而是確保在這個 Sprint 內有多少 Scope 已經被視為 Done
但並不代表在拆解的時候就能隨意的拆解
但如果拆 Story 時的心態是
反正最後都要全部完成怎麼拆都可以
這個想法就會落入「專案」的思維
而並非敏捷思維
反而是把 Sprint（短跑）變成了 Marathon（馬拉松）
而 Review Meeting 也不是在 Review
只是披著 Scrum Event 的皮
行 PM 的 Check Point 之實而已
導致最後真正交付的東西不一定是漢堡🍔
https://www.pinterest.com/pin/balanced-meal--427138345882467124/
Visible
https://www.pinterest.com/pin/balanced-meal--427138345882467124/
從 User 的視角每個 Story 完成的時候都是能直接看到成果的
舉例來說：
拆出來的 Story 是要能滿足「User 能成功下訂單」的 Scenario
那這個 Scenario 有哪些 Feature 要被滿足？
過去常見的會是
『噢 User 可以下訂單
然後我們可以打開 DB 給 PO 確認
資料真的有進去 DB』
這就不符合 Visible 的概念
因為從 User 的角度來說
我下訂單了可是我沒有地方可以確認？
這對 User 來說是一件很 Confuse 的事情
如果這個 Scenario 的 Business Requirement 又是要能直接刷卡結帳
那 User 錢都被扣了但沒有任何 Response
怎麼能稱作這個 Scenario 是結束的呢？
如果我是 User 可能就直接打去客服了
但在課堂中有個討論是
「如果訂單查詢太難做了但商業需求又要趕快上線怎麼辦？」
其實會有這個問題很可能多半是
這個 Scenario 直接訂立了 Feature 要怎麼做
但根據我自己的消費經驗
其實應該還是有機會討論的
舉例來說訂購成功後
發 email, 發簡訊 … etc.
作為一個消費者我覺得也算是 Visible
至少我看到之後不會打去煩客服
Valuable
如果可以應該盡可能地讓拆出來的 Story 有一定程度的商業價值
假設我們一開始就是用「專案」的思維去考慮拆解
那麼真的就得等到全都做完才能交付一個漢堡
但如果每一張拆出來的 Story 都能滿足作為漢堡的條件
PO 才有「選擇的機會」
看是否要交付 20% 的漢堡或是 80% 的漢堡
0x03 PoC 不是 Story
有時候當團隊覺得東西有點大
想要先有點小小的嘗試或做點 PoC (Proof of Concept)
再來估算真正的 Story
此時就會有 PoC 的 Story
但 PoC 並不能上 Production 給 User 用
更不可能滿足 DoD
從這個角度來看
PoC 本身就不該是 Story
如果本來就是需要做的 Story
那麼就應該直接在 Product 上實現
畢竟 PoC 跟 Product 的環境複雜度相比
PoC 真的只是 Piece of Cake
即便 PoC 實現了
不代表就一定能在 Product 重現
因此在課堂上有提到
「Take a bite」的方式來建立第一張 Story
這是什麼意思呢？
不知道大家吃漢堡有沒有一個經驗就是
點來的漢堡超厚的
沒辦法張嘴張很大
這時候會怎麼做？
應該不會分開吃吧？
🥯🥗🧀 🥓
我們應該是會找比較好咬下去的地方先咬一口
即便咬下去的時候不一定什麼都吃到
這就是
Take a Bite
先找到整個 User Story 中最容易的部分
而且滿足 3V 條件
接著 Implement 它
從這個過程得到一些經驗值
也從這個過程得到一些有用的材料（Pice of Code）
0x04 Increment or Iteration
Increment 是增量
Iteration 是迭代
如果一個 Story 太大
那麼可以嘗試思考在 Story 中的 Scopes
有哪些是可在迭代的時候做
哪些 Scopes 可以作為第一次的增量
用 Startup 的方式比喻的話
Increment 是讓 Story 從 0 到 1 的過程
Iteration 是讓 Story 從 1 到 100 的過程
這樣 PO 才有辦法在 1 到 100 之間去做選擇
是否要繼續投入
但實務上會發現有時候 Story 過大時
沒有把 Increment 拆出來先做
把理應是 Increment 的部分打散到各個拆分後的 Story
此時 PO 只能被迫選擇把東西做到 100 才能 deliver
從 0 到 1
是做出 MVP (Minimum Viable Product)
而 1 到 100
是將 MVP 打磨到 PMF (Product Market Fit) 的過程
至於 1 到 100 之間
什麼時候才算是 PMF 就是考驗 PO 的智慧了
拆小後的Story 們
產出了數個 Potentially Shippable Product Increment
而 PSPI 累積起來就能成為 Shippable Product
這時候就能 Release 給 End User 了
一個小小的 Hit:
結合上一篇提到的 Behaviour Change & System Change
要快速區分 Incremental / Iterative Story 的話
自己有個小技巧就是
通常 Increment 都會帶來 Behaviour Change
而 Iteration 帶來的通常是 System Change
0x05 小結
Sprint 交付的是 PSPI 不一定要能直接被 Release 給User
但應該要維持可以隨時 Release 給 User
只要 PO 願意
拆小的 Story 可以用 3V 原則來檢視
是否是個合格的 Story
不要做 PoC 應該要做 MVP
透過實作 MVP 的過程
蒐集所需要的經驗以及材料
把 Story 拆成
Incremental Story
Iterative Story
有助於 PO 選擇 Release Time
0xFF 參考資料
《Fifty Quick Ideas To Improve Your User Stories》
非常的推薦這本書，無論是 SM, PO, Teams
這本書有很多實例關於 Story 的起始到結束
會經過的所有歷程
以及各種看似難以拆解的 Story
如何 Take a Bite
Story 拆解的部分到這邊已經差不多了
希望這篇能幫助到一些不知道怎麼拆小 Story
而困擾的朋友們有一點幫助
