What Is A User Story
- form User Stories Applied: For Agile Software Development
最近team要開始採用user story 的方法, 因此需要花一些時 間來研究, 要如何套用會比較合宜. 我基本上相信, 要套用一個新的aprroach, 應該是花時間熟悉它是什麼, 和想辦法試試看是否能原汁原味的採用.
公司之前有很多team 在採用一些新的methodology, 大多是採用一個, 就怨恨一個, 常常會認為那方法不適合在這個地方執行. 可是在我看來, 你既沒花時間研究它, 也沒有心要要全面使用它, 或是套用他所有規則, 自然就不會成功.
就像Agile來說, 大家只知道要做iteration, 可是卻沒有採用要達成iteration, 所要使用相關的practices. 因此run下來, 大家只是很累地快速deliver了幾個版本, 可是是否快速反應user需求, 或是仍能維持適當的品質水準, 這些事情反而變成不是大家討論的重點.
有鑒於這些教訓, 小弟想想還是要花時間研究一下, 希望自己在run 完後, 也不會一直怨恨.
首先, 就先開始拜讀User Stories Applied: For Agile Software Development 一書, 從了解什麼是User Story開始.
What Is A User Story
1. Describes functionality that will be valuable to either a user or purchaser of a system
2. Example
- A user can search for jobs.
- A company can post new job openings.
- A user can limit who can see her resume.
3. Not good examples
- The software will be written in C++.
- The program will connect to the database through a connection pool.
Three Aspects of A User Story
1. A "Written Description" of the story used for planning and as a reminder
2. "Conversations" about the story that serve to flesh out the details of the story
3. "Tests" that convey and document details and that can be used to determine when a story is complete
Written description
1. Short heading, typically one or two lines
2. Often written on an index card
3. Used throughout the project for
- Planning
- Reminder
Conversations
1. Used to uncover the details of the story
2. Takes place throughout the project, e.g.,
- When estimating the story
- When implementing the story
3. Notes from these conversations can be added to the index card
- the conversation is the key, not the note on the story card.
Tests
1. Specify and describe details about a story as tests, e.g., some of the details uncovered during the conversation
2. Use the tests to determine when a user story is complete, i.e., acceptance tests
3. Write the tests on the back of the index card
Big User Story
1. It is better to have more stories than to have stories that are too large.
2. Epics (Big user stories) can be split into two or more stories of smaller size
3. We do not continue splitting stories until we have a story that covers every last detail.
- We stop when it is a very reasonable and realistic story
4. Rather than writing all these details as stories, the better approach is for the development team and the customer to discuss these details.
- form User Stories Applied: For Agile Software Development
最近team要開始採用user story 的方法, 因此需要花一些時 間來研究, 要如何套用會比較合宜. 我基本上相信, 要套用一個新的aprroach, 應該是花時間熟悉它是什麼, 和想辦法試試看是否能原汁原味的採用.
公司之前有很多team 在採用一些新的methodology, 大多是採用一個, 就怨恨一個, 常常會認為那方法不適合在這個地方執行. 可是在我看來, 你既沒花時間研究它, 也沒有心要要全面使用它, 或是套用他所有規則, 自然就不會成功.
就像Agile來說, 大家只知道要做iteration, 可是卻沒有採用要達成iteration, 所要使用相關的practices. 因此run下來, 大家只是很累地快速deliver了幾個版本, 可是是否快速反應user需求, 或是仍能維持適當的品質水準, 這些事情反而變成不是大家討論的重點.
有鑒於這些教訓, 小弟想想還是要花時間研究一下, 希望自己在run 完後, 也不會一直怨恨.
首先, 就先開始拜讀User Stories Applied: For Agile Software Development 一書, 從了解什麼是User Story開始.
What Is A User Story
1. Describes functionality that will be valuable to either a user or purchaser of a system
2. Example
- A user can search for jobs.
- A company can post new job openings.
- A user can limit who can see her resume.
3. Not good examples
- The software will be written in C++.
- The program will connect to the database through a connection pool.
Three Aspects of A User Story
1. A "Written Description" of the story used for planning and as a reminder
2. "Conversations" about the story that serve to flesh out the details of the story
3. "Tests" that convey and document details and that can be used to determine when a story is complete
Written description
1. Short heading, typically one or two lines
2. Often written on an index card
3. Used throughout the project for
- Planning
- Reminder
Conversations
1. Used to uncover the details of the story
2. Takes place throughout the project, e.g.,
- When estimating the story
- When implementing the story
3. Notes from these conversations can be added to the index card
- the conversation is the key, not the note on the story card.
Tests
1. Specify and describe details about a story as tests, e.g., some of the details uncovered during the conversation
2. Use the tests to determine when a user story is complete, i.e., acceptance tests
3. Write the tests on the back of the index card
Big User Story
1. It is better to have more stories than to have stories that are too large.
2. Epics (Big user stories) can be split into two or more stories of smaller size
3. We do not continue splitting stories until we have a story that covers every last detail.
- We stop when it is a very reasonable and realistic story
4. Rather than writing all these details as stories, the better approach is for the development team and the customer to discuss these details.
