[CD心得] 5 Common Mistakes In User Stories - 五個使用者案例中常見的錯誤
什麼是使用者案例(User story)？ 怎麼區分好與壞？
軟體開發的三個基礎
- 知道問題
- 針對問題提出寫法 (程式開發)
- 確定問題有確實被解決
但是工程師經常的省略了某些步驟, 甚至專注在程式開發上, 不管其他兩項了...
怎麼知道我們的產品或系統正面臨什麼問題, 這其實是非常的重要,
要先有明確的問題才知道如何去解決...
這邊經常被省略或是有些常見的錯誤
Remote control Programming
使用者案例(User story) 一般不會告訴程式人員該如何解決問題或是提供解決方案,
好的使用者案例更應該在描述問題或是需求的本身, 至於該如何解決接給專業的工程師來就好
這種案例很常發生在有技術背景的PM or Planner 身上, 他會依照他過去的經驗提供一些解法
這個table 多開個什麼欄位, 這邊多傳個什麼值就可以解決問題了
導致PM or Planner 開出來需求就是加個欄位加個回傳值....
但這真的是最好的解法嗎？
說不定技術框架已經跟以前不一樣了？或是有其他更好的解法？
開發團隊沒有真正的是了解為什麼要做這個改變, 同時也限制了解決問題的創意
Story as a contract
開出來的功能需求跟被要求遵守的規範是一樣的,
需求應該是可以引領工程團隊作進一步的對話跟討論
在討論對話的過程中常常會出現更有創造力更有效率的解決方案
使用書寫的方式去記錄規範, 很容易產生誤解
下雨天留客天留我不留
不同的斷句地方就會有不同的意思
如果有一個交互式對談就可以明確的澄清問題以及用戶的需求
好的開發團隊在收到案例初期應該會有大量的交談對話去建立問題的細節
Monster stories
使用者案例應該以小步快跑不段遞增的方式去描述需求,
盡可能小到讓使用者案例可以在一個開發週期裡面被完成
怎麼分解到足夠小的部分,並且可以讓工程師快速的完成每一部分去向客戶提供價值
這是最大的挑戰
使用者案例的價值在於它能夠解決客戶的問題或是提供客戶想要的價值
一堆寶藏很有價值, 但是一塊錢也是有價值的
開發團隊經常會誤解為做完客戶想要的所有事才有價值...
我們應該把案例拆分到更小的單位, 更快且不斷交付提供價值給用戶
這樣做是會更有效率, 且單位更小的好處是當犯錯時更容易回朔,
這樣客戶和開發團隊所承擔的風險或更小
Dependencies between stories
案例之間的互相依賴, 這通常是不可避免的
我們常常會在舊的案例上加上新的需求
問題是發生於為了能夠優化開發過程而進行排序
這會影響開發團隊專注在正在交付的價值
迫使團隊專注在還無法提供價值且複雜的任務上
好的案例應該是可以在任何順序被執行的 (atomic)
使用者案例幫助我們保持專注在使用著的需求上, 避免過度設計
留言
發佈留言