上 CSPO 在練習撰寫使用者故事 (user story) 時, 被老師質疑一個很根本的問題: 你是在思考問題, 還是在思考解法?
當你是 product owner, 你需要撰寫使用者故事, 來描述系統所要提供的功能. 所以你可能會用以下方式來述說:
As a [Role], I want a [function] because [business value]
所以訂旅館的系統來說, 你可能會寫出:
身為一個背包客, 我需要[系統列出最便宜的房間], 因為我沒有太多錢.
我想大多數人會覺得這應該不錯的敘述, 把要做的事情, 以及背後的理由都寫了出來. 所以到時候, 你就是時做一個功能, 列出最便宜房間, 這樣他就可以下訂單.
你再想想這真的是好的方式? 尤其你是一位 product owner, 尤其你在 start up 公司時, 你認為這樣的產品客戶就想要買? 你的產品就會與眾不同嗎?
由上面的範例來說, 背包客考量的是沒有太多錢, 這是他擔心的. 而提供找最便宜的房間, 是其中一種解法. 如果你做出這個功能, 我想不太有人會覺得你的系統有多特別. 你想得到, 別人也想得到. 所以做出來系統會大賣嗎? 不會的機率其實很高!!
所以當你是 product owner, 應該多思考的要解決的是什麼問題, 而不是只在思考如何解決. 你在列使用者故事時, 不該光都列的是解法.
以上面的定義來說, 你可以改寫成:
身為一個背包客, 我需要[訂最便宜的房間], 因為我沒有太多錢.
這 2 個故事差別在哪裡呢? 這時候的差別在於, 你不一定是實作"列出最便宜房間清單"的功能, 你可能會思考是否有其他做法. 像是合住的可能, 或者其他提供折價服務的整合, 這樣才可能會有差異化出現.
為什麼我們要這樣思考呢? 在早期你還搞不清楚你要幹嘛時 你會列出正確的故事嗎? 或者即使那時候, 你很清楚要做什麼, 但是過了一段時候後, 那些肯定的東西是否還是正確的? 所以對於不清楚或是後期的項目, 我們應該以列要解的問題為主, 而不該以列要做的解法為主.
Agile 很重要的一個觀念叫做延遲決策. 這就是延遲決策, 我們只對很確定的東西, 或是很近的東西, 花時間處理. 但是對於叫後面的事情, 我們只需要概念性的東西.
學習 agile 真的很傷腦筋, 我是否可以退回 command and control, 當個小白癡照做好了 (誤)
留言列表
