從 Scrum 到 LeSS -使用者故事(三)

閱讀時間約 17 分鐘

上一篇
講完了 Story 的拆解
其中提到了 Scope 那麼 Scope 是什麼呢?
以及伴隨著 Scope 
很常聽到的 Acceptance Criteria (AC)
又扮演了什麼樣的角色?


0x00 回顧

在系列文章中的第一篇
從 Scrum 到 LeSS — 角色
裡面有提到
PO 作為 Police Officer 的角色
要控管 Story 要交付的 Scope 有哪些
不應該讓需求貢獻者或團隊增加 Scope

而系列文章的第三篇
從 Scrum 到 LeSS -使用者故事(二)
提到了可以採用
識別 Scope 是 Increment 或 Iteration
來作為 MVP -> PMF 的界線

那麼 Scope 是什麼?
我們來看一下軟體開發的鐵三角

https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle

https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle

在 Waterfall 方法裡
Scope 是絕對的
因此 Scope 的調整需要經過層層關卡
而 Resources, Time 都是 Estimated
所以專案延遲交付或是加人加班
造成成本的追加是很大機會會發生的
因此專案都會設立應急儲備的資金
讓 PM 在必要時可以使用

而 Agile 方法裡
資源固定(Teams)、時間固定(Sprint)
因此成本固定
Scope 則是 Estimated 而來
所以 Scope 的調整以 Agile 來說是必然的
甚至可以說
Sprint 期間 Story / Scope 無法全部被 finished
理應也是預期的
因此相較於 PM 有應急儲備資金
PO 的最重要的任務就是在
有限資源(開發團隊 & 開發團隊的產能)
有限時間(n 個 sprint)
的前提下透過調整 Scope 以及 Priority 
來讓產品可以儘早的帶來商業價值

雖然 Scrum 中 Sprint 固定時長
但到底要幾個 PSPI
才能完成 Shippable Product
是 PO 的權力

倘若 PO 不斷地去追求完成所有 Scope 才上線
而不是透過先有增量 increment
再透過迭代 iteration 持續改善
那麼 Sprint(衝刺)
就變成 Marathon(馬拉松)
Review 變成 Check Point
到最後就就是無限迭代
無法預期何時才能上線
無限拉高成本


0x01 Split Scope

簡單做個假設

兩個團隊在做開發各別 7 人
每人月薪 5 萬
一個 sprint 兩週
可以算出一個 sprint 就要支薪
5 * 7 * 2 / 2 = 35 萬
接著從公司的角度包含其他非薪金支出
約 1.5 倍來估算
35 * 1.5 = 52.5 萬
每個 Sprint 公司就要支出至少 52.5 萬成本

由此可知
如果某個 User Story 
原訂需要兩個 Sprint (四週)才能完成
那麼公司就要支出至少 100 萬的成本
而 PO 每延遲一個 Sprint 交付
就是支出約 50 萬

此時就需要回過頭來看
這個 User Story 是不是真的有那麼高價值
或是這個 User Story 
是否可以減少 Scope 然後提早上線
確認真的有帶來正向影響
再繼續為它開發

正向影響
可以從最基本的 ROI 
(Return of Investment)
或是日/月活躍用戶提升百分比
或是新用戶提升多少
或是客戶留存率提升多少
也有可能是客訴下降的百分比
等等預期達到的指標

若沒有設立這些指標
就無法知道投入這些成本到底為了什麼
也不知道下次可以改善什麼

回過頭來
所以 Scope 是什麼?
從上面的敘述應該可以看出
Scope 對 Story 而言
就是會影響交付 Story 時間成本的工作量

舉例來說
某個數據顯示
從加入購物車到結帳的轉換率有點低
根據 BA 的研究
也許是因為關閉網頁之後再回來時
購物車被清空導致
因此希望能做到
User 下次回訪時
能看到之前已經加入購物車的項目
進而提升轉換率 X% 因此有了以下 Story

As a Customer
I want the cart keep my added item
So that when I came back I don’t need to add it again

從這個 story 來看
就會有兩個明顯的 Scope 要做

  1. 保存購物車紀錄
  2. 當商品已經沒有的時候要提示使用者,並移除該項目

但團隊在 SP2 的時候發現
保存購物車紀錄在現行的架構上有一定的難度與工作量要做
此時可能就可以將 1. 拆成兩個 Scope
1–1. 保存紀錄在 browser local storage
1–2. 保存紀錄在 DB

這時對交付可能會有些影響

a. 使用者若換不同瀏覽器或裝置一樣沒有紀錄
b. 使用者使用無痕模式也沒有紀錄

這時候 PO 就有幾種選擇
1.「完美版本」
繼續增加交付成本、以及延後交付時間
以達到原本規劃的所有內容
2.「有部分情境能滿足就先開出去觀察」
先開一部分的客戶做 A/B test
並且觀察是否有如預期的將轉換率提升 x%
再繼續評估是否要繼續開發此功能
若效果不如預期那也沒有繼續開發的必要
應找出其他提升轉換率的解決方案

那麼怎樣可以不讓時間成本無限上綱呢?
由於 PSPI 不一定是可以直接交付的東西
Shippable Product 才是
因此為設立 Milestone
 (or 大家比較不喜歡聽到的 deadline)
是一個可行的方法

因為在某個時間點所累積起來的 PSPI 
被迫要能達到 Milestone
這樣一來才能在
有限資源、有限時間的狀態下
去因應 Scope 的非預期變化
並且在該上線的時間點上線
提升產品競爭力


0x02 From Scope to Scenario

不知道看到上述的例子時
各位有沒有心裡想著
為什麼不乾脆依照工作拆分成

1. 完成 UI 
2. 存入 DB

這兩個 Scope 就好
同樣也能達到拆分的效果

在前一篇我們提到
拆 Story 的時候應該要遵循 3V 的原則
拆 Scope 也是同樣的道理
原因還是在於
每一個 Scope 被 Done 的時候
PO 是否有機會選擇 release
因此相較於 Scope

我更喜歡先從 Scenario
去思考怎麼做到降低工作量的同時
還是能滿足一定程度上的情境

以上述的例子來說
也許存在 Local Storage 就已經能滿足 Y% 的 User
因此這 Y% 的 User 就能在新的服務上得到滿足

如果當次的 Sprint 真的只能完成 UI
那麼其實是沒有太大價值的
因為如果 PO 想要看到 UI 長怎樣
去看 designer 的圖就可以
因此完成 UI 只是證明了
「噢!我們能做出跟設計稿一模一樣的 UI」

反過來說
如果 PO 真的只想 release 一個美美的畫面
那為什麼不乾脆把 designer 的稿
輸出 html 丟到網頁上呢?


0x03 Contract Game

Acceptance Criteria (AC)
本質上應該是用來補充 Scenario / Scope 的細節注意事項
因此有沒有 AC 理應都不該做錯 Scenario / Scope

但根據觀察
無情境的 AC 到後來很有可能把 Scrum Team 導向
PO vs. Dev Teams 的 Contract Game

為什麼會如此呢?

其實就是「不確定性」
原本 Agile 就是應該擁抱「不確定性」
承認其實所謂的需求本來就不可能講清楚

俗話說世界上最難的兩件事
1. 把別人口袋裡的錢放到自己的口袋
2. 把自己腦袋裡的想法放到別人的腦袋

當 PO, Teams 其中一方無法擁抱不確定性
那麼就會開始有不安全感

通常比較常見的狀況就是
Teams 交付成果
也完成 DoD 了
Scenario 也是正常的
但 PO 就是對交付出來的東西不滿意
覺得缺少了他想要看到的東西
接著就會有
「怎麼我沒講就沒做」
開始責備團隊

到下一次的 Sprint 開始增加 AC
甚至可能不是 PO 要求要增加
也許團隊為了不想被責備
就自己要求 PO 要講得更詳細
然後簽名畫押

因此就會玩起甲方乙方的合約遊戲
把無情境的 AC 當作 Spec 來寫
時間久了
Story 其實有跟沒有一樣
甚至會發現
有些 Story 是

As a …
I want …

先不說開頭沒有 In order to
就連 So that 都不見了
更甚至有時會看到

As a PO
I want a OOO feature

這種赤裸裸的 request
但沒人在乎 Story 的合理性了

因為大家只在乎
「名為 AC 實為 Spec」的 AC
由於沒有人想為無法如期上線背鍋

Agile 的 Scope 本來就是 Estimated
因此 Sprint 無法將所有東西 Finish
本來就是理所當然

回到上面的情境
在 Scenario OK, DoD OK 的狀態下
PO 若對交付成果不滿意可以怎麼做?

別忘了 Scrum 本來就是仰賴 Sprint 的循環來持續改善
若這個 Scenario 已經可以為產品提供增量
那麼就是評估距離 Milestone 還有幾個週期
而下一個週期要不要為這個增量做迭代
讓他更好或是繼續往下一個 Scenario 前進
儘早的累積所有的 PSPI 來達到 Shippable Product 的程度
還有餘力再繼續迭代

從測試的角度來看一些過度強調精細的 AC
某個 banner 的高度多高我們會去寫測試嗎?
如果不寫測試
不會去保護他
那麼對於這麼精準的要求
不能容許有誤差
並且要調整到和設計稿一模一樣的意義其實不大
因為也許過兩三個 sprint 之後就算他歪了 1 pixel 也沒人知道
既使發現了
是不是會開 Ticket 去修?
從結果回過頭來看
就會發現在當下的這些過度要求的「條款」
不但對 User 產生不了價值
同時也墊高了交付成本

本來 Scrum Team(PO & Dev Teams)
應該是站在同一條船上的 Team
不斷向前衝並且共同成長
在有限條件下
(Fixed Release Date, Team Technical Skill …)
為產品帶來價值的最大化

畢竟東西到底是不是完美
或是倒底能不能讓用戶滿意
也並不是誰說了就一定是「正確」的
一個產品要服務的客戶眾多
PO 也只是眾人之一
用最少的成本完成 PMF
趁早的上線搜集數據搜集回饋
才有可能找出眾多 User 中相對完美的版本
有沒有必要在已經滿足 Scenario 的情形下
持續的追求 PO 自己心中的 100% 完美版本
其實是有待商榷的

若 Scrum Team
陷入合約遊戲
那麼這艘船無法向前衝
因為這種文化是毒藥
大家只追求不要背鍋
而不是把鍋拿起來炒一鍋好菜
因此把失誤推給

AC 沒有寫!!!

是最輕鬆的事情
也很容易上癮的事情


0x04 A-TDD

那麼要怎麼避免上述的方式呢
從人去解決總是比較困難的
如果團隊已經陷入 Contract Game
不仿考慮大家拉開一點距離
換掉工具
不要再繼續寫 Spec. (無情境 AC) 了
嘗試改為 A-TDD 吧!

Acceptance Test-Driven Development
驗收測試驅動開發

先思考這個 Story 希望提供 User 什麼樣的 Behaviour Change
把這些關鍵實例寫下來

在 LeSS in Action 的課程中
講師用了這樣的模板
來促進大家在 PBR 的討論

General:
Scope:
Assumptions:
Keys Examples:

General:
可以是很粗淺的 Idea 
或是想要解決的問題
也可以是已經稍微有點樣子的 User Story

Scope:
即較大範圍的工作量(如上面提及的)
當然這些工作量是有可能在 SP2 之後再去做裁減

Assumptions:
當大家在討論過程中
有疑惑但可能 PO 或需求貢獻者正在別組的時候先記錄下來
經過不斷的溝通與釐清
將這些假設確立出明確的答案

Keys Examples:
關鍵實例,把確認的 Scenario 寫下來
用以說明這個 Idea 是期望 User 能體驗到什麼樣的服務

raw-image
這是在課堂中 PBR 後的其中一個 Story 的樣貌

可以看到在過程中大家會盡量的去描述
甚至做些簡單的 Mock UI 確認使用情境
而不是一條條沒有生命的 AC

有了這些實例之後
怎麼驅動呢?

我們可以嘗試將他規格化
e.g. Given When Then
接著套用一些工具如 Cucumber 來文件化

raw-image
此為課堂中我們小組寫的 Feature File

而 Sprint Review 的階段
Teams 也不用再為了 Demo 花時間準備
直接打開來執行測試
就可以知道這個 Story 已經完成了多少

Show tests in Sprint Review
In a Sprint Review, the team demonstrates visible progress to the Product Owner by showing the output of the iteration.
We worked with some groups that defined the demo steps during the Sprint planning. The team would spend an inordinate amount of time in demo preparation. A complete waste.
During Sprint Planning, an alternative is to define the examples that need to pass and show the progress by using these tests in the Sprint Review.
ref: Acceptance Testing

再次回到上面的問題
如果 Sprint Review 後 
DoD 完成了
Scenario 也透過展示自動化測試 Pass
但 PO 還是不滿意怎麼辦?

raw-image
不可能有真正的完美的騎驢法

那就把希望繼續改善的部分
進入下一個 Sprint 迭代囉!
只要 Scenario 不變
這個 Feature File 也不需要更改
下一個週期的 Sprint 結束後
一樣的在 Sprint Review 重新執行一次
就能證明系統想要提供的功能
都還是好端端的

畢竟要不要 release 是 PO 的權責
團隊沒辦法直接干涉
但至少作為開發團隊的成員
我們可以很有信心的說
隨時 Release 都沒問題

raw-image
不管外人怎麼講 無論改變什麼騎法 驢還是驢 — Feature Still Work

這時候就可以來點音樂
I’m ready for release
I’m ready for you
I’m standing right here
I’m waiting for you…
I’m ready for release
I’m ready for you
I’m standing right here
I’m waiting for you…

0x05 Living Documentation System

將關鍵實例從 Story 萃取出來的好處
除了縮短驗收時間
確保功能沒有損壞之外

同時我們還獲得了一份活的說明文件系統
如果今天有個新人需要做新人訓練
甚至可以直接請他看這些文件
理應就能了解這個應用到底提供哪些服務


0x06 小結

擁抱執行 Scrum 時對於 Scope 的不確定性

避免無限修改的發生
設立一個 Milestone 作為 release date 
在那個時間點就是 release 
而在 Sprint 的過程中不斷的去因應變化做調整
不斷的 iterative & incremental
而非完成所有 spec 才 release

raw-image
src: Project Management Stack Exchange

避免 Contract Game

厲害的 PO
是能使用手邊的有限資源
可能是人數不多
可能是技能不足
可能是時間不夠
的這些狀態下
照樣交付價值到商業環境

不應該把非客觀的「不滿意」
將團隊推向 Contract Game
Scrum Team 理應是學習型組織
大家是共同的學習成長
而非互相卸責

如果一直追求的是 100% Spec
大家還是喜歡 Contract Game
甲乙方簽名畫押的方式
那麼組織應該思考一下
也許需要的不是 Agile 而是 Waterfall

用 Living Documentation System 的方式

取代無情境的 AC 來讓使用情境更加的明確
也能更加的 focus 在交付的 feature
而非一條條的規格
同時也能確保在後續的迭代不會改壞
畢竟 AC 通常都是交付了之後就不再去維護的東西
但做產品需要維護的就是已經在線上的 Feature

因此 Living Document 的好處包含
某天需要重新打造系統的時候
不會遺失本來就有的 feature
因為在商業模式沒有改變的狀態下
就算整個系統重寫
這些 feature 也應該還要持續提供給 User


0xFF 參考資料

文章:Specification by Example
書籍:《Specification by Example 中文版:團隊如何交付正確的軟體

沒想到光是 Story 就寫了三篇 …
希望這些文章能讓 Story 的目的更為鮮明
而非只是一張可有可無的小卡片

    留言0
    查看全部
    發表第一個留言支持創作者!
    你可能也想看
    迎新活動「方格新手村」:新格友註冊加入方格子,知名日料吃到飽餐券送給你! 👉 還不是 vocus 的會員嗎?點此註冊,參與新手村活動 👈 近期站上也出現了不少新格友,為了歡迎各位的加入,「方格新手村」隨之登場! 即日起,只要是新註冊帳號於活動期間內發佈 3 則文章,就有機會抽獎獲得知名日料吃到飽餐券。原格友也可以一起同樂,我們準備了小任
    Thumbnail
    2024-06-21
    閱讀心得:展現自我的生活態度|成熟大人的說話課我們每天都在說話,但說出的話合適嗎? Sunny最近讀完一本有關溝通的書籍。 這是由世紀奧美公關的創辦人「丁菱娟」所寫的書,書的全名《丁菱娟的成熟大人說話課:如何說,才能得體又不傷人?反擊時,如何堅定又有力量?任何情境都可用的38個溝通之道》。 會找這本書來看,主要是因為Sunny 近期發
    Thumbnail
    2024-07-10
    防曬產品係數測試報告彙整(2024年)從2014年起,自己對於市售防曬產品的效能產生了濃厚的興趣。因為當時候發現不少產品的防曬係數其實標示是有問題的,像是原本應該是人體測試的SPF與PA數值,實際上沒有做,只用機器測試的數據來充當,但這兩者卻有很大的差異。像是防曬係數其實有強度、廣度與平均度三個面向需要一起判斷,但多數廠商並沒有完整標示
    Thumbnail
    Scrum Master 能從學習更多產品管理知識中獲益處在「產品」越來越盛行的世界裡的這個事實,幫助了 Scrum Master (SM) 了解更多有關產品管理的知識。 Product Owner (PO) 作為了解顧客的人, 在排定對顧客具有價值的排序工作上,負有重責大任。 一般來講,在許多國家...
    Thumbnail
    2023-06-24
    從自身的生命經驗中發現生命力(一):被打到頭破血流的故事  擁有發現生命力的眼光,最直接受惠的人就是我自己。我開始用這樣的眼光重新看待我的生命經驗,特別是那些令我感到痛苦的生命經驗。我發現,這樣做雖然沒辦法改變過去發生的事情,卻可以改變我的感受、我的想法,更重要的是,可以改變我看待自己的方式。   國中的時候,我曾經被人用椅子砸破了頭...
    Thumbnail
    Product Owner 如何跟 Scrum Master 密切工作共同作者:Shalom Chin 與 KK;譯者:KK 你的 Product Owner (PO) 和 Scrum Master (SM) 能良好合作嗎?你的 SM 和開發人員是否將 PO 視為 Scrum 團隊的一份子? Scrum 是以強大團隊合作為基礎的工作方式,尤其是 PO 和 SM 之間的
    Thumbnail
    2023-04-18
    從露宿街頭到入住豪宅──但這是矽谷,不是迪士尼故事一對在矽谷露宿街頭長達十年的老夫婦在一夜之間翻轉命運,搬入了山上四百萬美元的豪宅。但,這不是迪士尼故事,所以劇情是以矽谷真實的人性上演……
    Thumbnail
    2019-08-12
    從電影看Scrum - 黑金丑島君1 慾望篇 在電影黑金丑島君1 慾望篇中,一位角色為了賺大錢,挺而走險向高利貸借錢來發展自己的事業,不過在無法順利償還的情況下,讓自己的困境越陷越深。  看完電影後,除了感受到高利貸金錢債務的恐怖,也聯想到軟體開發中的技術債。
    Thumbnail
    從製作到劇情都充滿故事的《歡樂滿人間》(Marry Poppins)1964年,改編自同名小說的《歡樂滿人間》(Marry Poppins)上映。此部電影成了迪士尼至今,在奧斯卡上提名最多(被提名了13獎項)、也獲獎最多(獲得5項獎項)的電影。而「歌舞電影」的形式,讓
    2019-02-03
    從橄欖球賽看SCRUM團隊 (1) 得分方式 今天去看了U19亞洲青年橄欖球錦標賽,除了親眼看到 scrum爭球 覺得很激動之外,橄欖球賽的得分方式,我也覺得很有意思。 
    Thumbnail
    從咖啡看Scrum - Espresso Espresso 義式濃縮咖啡,是將咖啡豆研磨後,經由咖啡機在高溫高壓下萃取出約1盎司的濃縮精華。  這讓我想到scrum裡的衝刺待辦清單(sprint backlog)   
    Thumbnail
    從關注科技到留意文具:過去幾年心路歷程轉變的故事我大學沒有修讀跟畫畫或電腦相關的科目,工作也不算碰上這方面的經歷。但對紙和電子裝置有興趣,是因為它們與生活、與自我需求很有關連,是個人管理、成長的重要伙伴,所以會偶爾試不同的文具和apps,也會試不同的方法。
    Thumbnail
    2018-09-05
    從電影看Scrum - 還有機會說再見(BEFORE I FALL)這部電影說的是一個女高中生重複過著同一天的故事。 一早主角起床,和好朋友一起去上學,到晚上參加派對,派對結束後在回家的路上車禍。醒來後,發現過著和 "前一天" 一樣的生活...