David Ko的學習之旅

身為開發人員的我們, 在列 user story 時, 常常會做出功能拆解的事情, 而不是找出一個 end to end, 對使用者有意義, 可以單獨展示的功能. 

例如高鐵訂票系統. 當你要訂購一張高鐵票時, 你要選擇要定哪一班, 接著填客戶資料, 然後再輸入付款方式.這些都完成後才能買到票.

可是你在撰寫 user story 時, 你不能寫成 3 個 user story: 選票, 填寫客戶資料, 付款. 因為這些是完成買票這件事的其中一個步驟, 單獨完成對使用者沒有太大意義. 因為在真實狀況, 前面兩件事是需要一起完成, 付款可以之後再單獨進行. 你必須要把前兩個步驟合在一起.

可是有人會問說, 那選票有兩種方式, 一種是依時間選擇, 一種是一車次選擇. 我可能沒有辦法一次做完, 或者之後可能有新的選擇方式, 例如最近一班. 那都要何在一起做完嗎?

這當然是不用.

你要先有一個基本流程, 把買票完成, 所以你先有一個基本的 user stoty :"依時間選擇來買票”, 然後再加上”依車次選擇來買票”, “選擇最近一班來買票” 這兩個 user story. 但是後面這兩個 user story 就只是處理一個小步驟而已. 也就是前面第一個的時間會比較久, 你必須把一些基礎架構處理完, 你必須要考量到這件事情.

可是如果你這樣拆解, 你會面臨的問題, 就是 user story 之間會有相依性. 也就是說, 你會需要一定的順序來開發, 如果依時間選擇來買票”. 根據大多數人的說法, 你必須避免有太多這樣的狀況, 因為檢定一個 user story 好不好, 其中一個標準就是要沒有相依性. 

在實務上, 你很難避免相依性的問題, 但是你要避免以下狀況
A <— B <— C <— D <— E <— F

如果是這樣的狀況, 可能彈性就會比較大.
A <— B
A <— C
A <— D
A <— E
A <— F

如果是互相相關, 也就是 A —> B, A <— B, 這時候重新撰寫這兩個 user story 會是最英明的決定. 如果真的不行, 或許把這兩個合併起來, 也是一種做法.