在敏捷社群中, 我們常常會使用 user story 來描述要做的事情, 並且用它來啟動跟用戶的對話. 唯有深入瞭解客戶要什麼, 你才能做出接近正確的產品.
可是問題來了, 如果你有 200-300 張 user story 呢? 我想對於一個正式的產品, 不是練習的作業, 這樣的數量似乎很正常, 這時候你就會遇到 James Shore 所說的 Story Card Hell 問題.
我們都知道, user story 的重點在於對話, 而不是寫份完整的 user story 或是漂亮的 story 紀錄格式. 當故事卡片到達 300 張時, 這時候你還能有效對話嗎? 你怎麼知道這中間是否有重複呢? 你怎麼去找麼某個 story 呢?
有人說這還不簡單, 買個 Jira, 把它給 key in 進去, 這樣不就隨時可以查得到了. 不錯, 是可以解決查詢的問題. 但是, 這就失去 user story 的本意: 對話. 哪個用戶想跟你聊 300 張故事呢? 並且你 key 完 300 個用戶故事後, 我想你的興致也降低很多.
那可以怎麼做呢? James Shore 提到了最後責任時刻( latest responsible moment), 也就是到最後必不得已的時刻才出手, 才作出決定, 才繼續寫出要處理的用戶故事. 聽起來很不錯, 可是做起來很困難, 因為沒人知道什麼時候是最後必不得已的時刻.
James 提出一個想法. 他說敏捷開發的案子, 一個版本的發佈(release)大多會在 3 個月左右搞定, 在 大於 3 個月之前, 你可能只關注這個案子的願景 (vision). 等到三個左右, 你開始會關注這個案子要處理哪些 features. 當到只剩 6 週後, 你看得便會都只是用戶故事而已. 也就是說, 一開始你關注於顆粒較大的 故事, 這樣的你就不會一開始寫很多個故事, 不僅浪費時間, 並且也讓對話不容易進行.
另外, 你也可以善用 impact mapping, 因為影響地圖所談的是策略面, 或是較為 high level 的需求, 這時候你面對的可能是數十個功能, 而不會是數百的. 此外, impact mapping 也不是用來展開所有要做的事情, 你要做的是先從最短路徑開始, 從最重要, 最需要被確認的假設, 或是風險最高的事情上開始, 這也會讓你不用同時面對這麼多用戶故事.
不過不管怎樣, 切記用戶故事不是用來當需求文件, 是為了瞭解用戶的需求, 從中找出要交付的價值, 並且讓你順利進行之後的估算. 所以不要再劃錯重點, 一下寫出一大坨用戶故事了.
全站熱搜
留言列表
