實行敏捷開發的團隊大部分都會用 User Story 來梳理使用者的需求,依照團隊的情況,每個團隊實行的方式也不盡相同,看起來差不多,可是細節卻有差。
User Story 看似簡單,操作起來卻有很多地方需要注意,一不小心很容易成為災難一場,不僅徒勞無功,又累死三軍,下面記錄我最近一次使用 User Story 的經驗,過程多少有一些操作得不是很好的地方,把它寫下來後,希望可以做為我未來調整及修正的方向。
實行敏捷開發的團隊大部分都會用 User Story 來梳理使用者的需求,依照團隊的情況,每個團隊實行的方式也不盡相同,看起來差不多,可是細節卻有差。
User Story 看似簡單,操作起來卻有很多地方需要注意,一不小心很容易成為災難一場,不僅徒勞無功,又累死三軍,下面記錄我最近一次使用 User Story 的經驗,過程多少有一些操作得不是很好的地方,把它寫下來後,希望可以做為我未來調整及修正的方向。
目前我常聽到估算需求複雜度的方法有 Dog Point Game、T-Shirt Size,還有一個叫 Planning Poker,曾經玩過幾次 Planning Poker 不過我總覺得費氏數列的那些數字不是很親切,所以我想做一點改變,讓它變得親切一點,就變成下面這樣,我叫它「Manday Card」。
在上週末從 David Ko 的 Agile 敏捷專案管理實務班結業後,覺得有點後悔,倒不是課程不好,而是後悔自己沒有多跟同學分享我們 Team 這三年來嘗試導入 Agile 的心路歷程,真的是血淚交織啊!