上 CSPO 在練習撰寫使用者故事 (user story) 時, 被老師質疑一個很根本的問題: 你是在思考問題, 還是在思考解法?

 

06fig03  

當你是 product owner, 你需要撰寫使用者故事, 來描述系統所要提供的功能. 所以你可能會用以下方式來述說:

As a [Role], I want a [function] because [business value]

所以訂旅館的系統來說, 你可能會寫出:

身為一個背包客, 我需要[系統列出最便宜的房間], 因為我沒有太多錢.

我想大多數人會覺得這應該不錯的敘述, 把要做的事情, 以及背後的理由都寫了出來. 所以到時候, 你就是時做一個功能, 列出最便宜房間, 這樣他就可以下訂單.

你再想想這真的是好的方式? 尤其你是一位 product owner, 尤其你在 start up 公司時, 你認為這樣的產品客戶就想要買? 你的產品就會與眾不同嗎?

由上面的範例來說, 背包客考量的是沒有太多錢, 這是他擔心的. 而提供找最便宜的房間, 是其中一種解法. 如果你做出這個功能, 我想不太有人會覺得你的系統有多特別. 你想得到, 別人也想得到. 所以做出來系統會大賣嗎? 不會的機率其實很高!!

所以當你是 product owner, 應該多思考的要解決的是什麼問題, 而不是只在思考如何解決. 你在列使用者故事時, 不該光都列的是解法.

以上面的定義來說, 你可以改寫成:
身為一個背包客, 我需要[訂最便宜的房間], 因為我沒有太多錢.

這 2 個故事差別在哪裡呢? 這時候的差別在於, 你不一定是實作"列出最便宜房間清單"的功能, 你可能會思考是否有其他做法. 像是合住的可能, 或者其他提供折價服務的整合, 這樣才可能會有差異化出現.

為什麼我們要這樣思考呢? 在早期你還搞不清楚你要幹嘛時 你會列出正確的故事嗎?  或者即使那時候, 你很清楚要做什麼, 但是過了一段時候後, 那些肯定的東西是否還是正確的? 所以對於不清楚或是後期的項目, 我們應該以列要解的問題為主, 而不該以列要做的解法為主.

Agile 很重要的一個觀念叫做延遲決策. 這就是延遲決策, 我們只對很確定的東西, 或是很近的東西, 花時間處理. 但是對於叫後面的事情, 我們只需要概念性的東西. 

學習 agile 真的很傷腦筋, 我是否可以退回 command and control, 當個小白癡照做好了 (誤)

創作者介紹
創作者 kojenchieh 的頭像
kojenchieh

David Ko的學習之旅

kojenchieh 發表在 痞客邦 留言(0) 人氣()