l

2016年4月27日 星期三

用戶故事中的霸主

April 25 13:10~14:17

螢幕截圖 2016-04-25 13.59.24

▲照片翻拍自《User Story Mapping》

 

採取用戶故事(user story)的團隊經常遭遇一個棘手的問題:「如何切出大小適中的用戶故事?」在〈需求的大小〉介紹過Investment Theme(投資主題)、Epic(史詩)、Feature(特性)、User Story(用戶故事)這種切割方法,今天要介紹《User Story Mapping》這本書的觀點。

《User Story Mapping》從三個角度來看用戶故事,由大而小分別是:

  • 商業(Business):從企業的角度來看,可以幫助企業達到某些商業上的成果。
  • 用戶與客戶:滿足用戶或是顧客的需要。
  • 開發團隊:開發團隊能夠在幾天內做完。

舉個例子,有不少敏捷開發團隊都有這種經驗,stakeholder(例如行銷或業務主管)在sprint review的時候一直批評團隊所完成的用戶故事「太小」,功能「太少」。聽到這種打槍式的「回饋意見」,團隊也覺得很無奈:「才兩個禮拜你是希望我們能做出多偉大的東西出來?敏捷開發本來就是迭代與增量開發,你要的這些功能不是我們不做,是安排在之後的sprint才會做。」

因為行銷或業務主管腦想看到的是「商業層面有價值的用戶故事」,但是團隊此次所展示的只是「這個sprit所完成的用戶故事」,兩者的範圍相差太大,所以產生認知上的落差。

***

「《User Story Mapping》認為,不管是叫epic或是feature,它們都是一種user story所以當stakeholder或是Product Owner提出一個想法,團隊不要用「這是一個epic喔,你還沒想清楚,請把它切成user story再來討論」這種態度打發對方。而是應該透過雙方對話,一起合作切割成開發團隊所能夠施工的user story,這才是一種健康的協作模式。

螢幕截圖 2016-04-25 14.08.34

▲照片翻拍自《User Story Mapping》

 

用戶故事中的霸主,還是用戶故事。

***

友藏內心獨白:大小不是問題,有沒有對話才是重點。

沒有留言:

張貼留言