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》

 

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

***

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

1 則留言:

  1. User story mapping is a valuable tool for software development, once you understand why and how to use it. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features. To learn more with the aid of graphical illustration and freely usable templates visit Creately.

    回覆刪除