2023-07-22|閱讀時間 ‧ 約 10 分鐘

從 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

    從 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 
    而困擾的朋友們有一點幫助

    分享至
    成為作者繼續創作的動力吧!
    © 2024 vocus All rights reserved.