常見的User story問題


有些時候很多user story, 它們會有共同的task, 例如架構設計, 撰寫測試程式.

有些人會將這些task變成user story. 理由可能如下:

(1) 他們認為這樣要交付的東西很明確, 例如要有設計的產出, 要有測試程式的產生.

(2) 並且不用頻繁更動user story. 這些可以一直擺在tas board上面, 只要內容不一樣就好, 這次是feature 1, 2, 3的設計, 下次是feature 4, 5, 6的設計.

這樣的作法, 一開始看起來很合理, 也很方便, 所以還看到不少團隊這樣使用.

可是大家卻很容易忘了一點, 那就是你想要交付怎樣的business value給顧客. 若是這些東西都沒有價值, 我們做得再快再好也是沒用的.

User story本身就是希望從顧客價值的角度, 讓我們隨時隨地思考customer到底要的是甚麼. 或許我們在一開始的時候不容易做到, 不容易知道真正customer想要甚麼. 但是比起從不把它列入考量的好.


另外一種user story是看不出想要交付甚麼. 例如IPv6, Active Directory, 或是MS SQL等等.

原意或許是要提供IPv6的支援, 和Active Directory的整合. 但是寫的這麼模糊, 不只customer看不出你要交付甚麼, manager也不確定你要產出甚麼, 以及跟你合作的夥伴要如何一起配合規劃.

最慘的是通常你會一直保留這個user story, 因為這個user story會很大, 你會要花好幾個iteration才能做完, 這會讓你很洩氣. 並且因為你無法在一個iteration完後去demo它, 所以你也無法及早確認, 是否目前做的是正確的.

所以千萬不要隨隨便便寫個user story 就貼上task board.
arrow
arrow
    全站熱搜

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