David Ko的學習之旅

切割user story的文章整理

最近要訂定每個sprint所要產出的內容, 可是發現大家有遇到一些問題

1. 不知道甚麼是sprint的產出要怎麼定
2. 不知道甚麼是user story, 大小要如何, 內容要填寫甚麼
3. 都是以internal module or architecture為導向, 所以產出都是某個module已經完成

其中以第三項最為嚴重, 因為
1. module產出和所要deliver的feature之間的關聯是甚麼? 不一定module都做了,feature也都完全deliver了
2. 在demo時展示module, project manger或是customer會沒有感覺, 不知道要怎麼給feedback, 因為這是tech -oriented, 不是user-oriented
3. QA無法針對每個sprint的結果加以測試, 因為QA不需要針對每個feature 加以測試, 但是他要確保每個feature都正確. 因此這樣的產出讓QA很難出力

此外, 因為每個RD自然都會希望交付一個完整的module, 所以常常無法在一個sprint(2-4 weeks)內完成, 導致會要求sprint的長度是不固定的, 這會樣整個sprint開發的節奏是不穩定的.

因此我針對了這些問題, 找了一些文章, 希望能對團隊有些幫助

1. User Story基本知識
有時候基本知識還是要先有, 這篇white paper寫得很簡潔, 但是該講的都有提到
(1) A User Story Primer
http://trailridgeconsulting.com/files/user-story-primer.pdf

2. 如何切割user story
這是要讓大家知道要如何將一個大的feature, 切割出一對小的功能, 好讓你可以在一個2-4 周的sprint內完成
(1). Ways to split user stories
http://radio.javaranch.com/lasse/2008/06/13/1213375107328.html
(2). Twenty Ways to Split Stories
http://xp123.com/xplor/xp0512/
(3). A User Story Primer - Splitting User Stories
http://trailridgeconsulting.com/files/user-story-primer.pdf

3. 垂直切割比水平切割好
這裡提到了, 不管怎麼切割, 記得要注意要以deliver customer value為最高原則
(1). Stories Too Big – Vertical Slices
http://stevesmithblog.com/blog/stories-too-big-ndash-vertical-slices/
(2). Breaking Down User Stories
http://www.cmcrossroads.com/blogs-menu/featured-blogs/software-cm/13577-breaking-down-user-stories