The concept of user stories has its roots as one of the main tenets of Extreme Programming. In simple terms, user stories represent an effective means of gathering requirements from the customer (roughly akin to use cases). This book describes user stories and demonstrates how they can be used to properly plan, manage, and test software development projects. The book highlights...
The concept of user stories has its roots as one of the main tenets of Extreme Programming. In simple terms, user stories represent an effective means of gathering requirements from the customer (roughly akin to use cases). This book describes user stories and demonstrates how they can be used to properly plan, manage, and test software development projects. The book highlights both successful and unsuccessful implementations of the concept, and provides sets of questions and exercises that drive home its main points. After absorbing the lessons in this book, readers will be able to introduce user stories in their organizations as an effective means of determining precisely what is required of a software application.
作者简介
· · · · · ·
Mike Cohn是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401(k)档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍
2001年，敏捷宣言诞生,现在敏捷方法已经在全世界范围内广泛应用。而早在1996年，极限编程就提出了“故事（story）”的概念，这是用户故事的起源。2004年，Mike Cohn《 User Stories Applied: For Agile Software Development》一书正式发表。书中对用户故事理论系统化的阐述，...
(展开)
summary: - estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story; - better as ideal day for estimating rather than taking into different impacts factors in to consideration - estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals - triangulate an estimate by comparing it to other es...
2016-04-02 17:22
summary:
- estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story;
- better as ideal day for estimating rather than taking into different impacts factors in to consideration
- estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals
- triangulate an estimate by comparing it to other estimates
- whether or not a team programs in pairs has no impact on story point estimates. Paire programming affects the team's velocity, not their estimates
引自 Estimating user stories
Velocity means, on the specific approach of estimating of the efforts of your team, in one iteration, how many story points can be resolved
Story points for one feature is better to be consistent (using same way or indicator as estimation - could have triangulate methods (put different story points stories on the same board to see whether applicable or consistent from each other)
Story point for a same effort level estimation could change with time changes, due to the tech development, more familiar with the concepts or coding etc.
If story is not aggregated to the subsequent stories, the approach or standards of estimation could be changed to reflect the actual efforts.
- start with goal stories - slice the cake a far better approach is to write the replacement stories such that each provides some level of end to end functionality - write closed stories a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth - put constraints om cards - size the story to the horizon focus on one an...
2016-04-02 15:59
- start with goal stories
- slice the cake
a far better approach is to write the replacement stories such that each provides some level of end to end functionality引自 guidelines for good stories
- write closed stories
a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth引自 guidelines for good stories
- put constraints om cards
- size the story to the horizon
focus on one and expand , then expand another (trawl stories required as below)
- role modeling via brain storm an initial set of user roles, organize the initial set, consolidate roles, refine the roles.)
- gather stories via techs as user interviews, questionnaires, observations, story-writing workshops
Summaries:
1. To identify stories, start by considering the goals of each user role in using the system
2. When splitting a story, try to come up with stories that cut through all layers of the applications;
3. Try to write stories that are of a size where the user feels justified in taking a coffee break after completing the story
4. Augment stories with other requirememts gathering or documenting techniques as necesar for the project's domain and environments
5. create constraint cards and either tape them to a shared wall or write tests to ensure the constraints are not violated
6. Write smaller stories for functionality the team will implement soon, and write broad, high-level stories for functionality further into the future
7. Keep the user interface out of the stories for as long as possible
8. When practical, include the user role when writing the story
9. Write stories in active voice.
10. Write stories for a single user
11. Have the customer rather the developer write the story
12. Keep user stories short, and dont forget their purpose as reminders to hold conversations
13. dont number story cards引自 guidelines for good stories
concerns for #11 & 13
#11: The customer indicates the customer user proxy like BA or actual customer? very seldom the real customer will help to write the story ? also, if they wrote, then the key concern is how to ensure the understanding between customer & BA is correct, so product owner can pass this correct to devs?
#13: agree of not mention feature abstractly. the thing is that we can use number and make this still concrete for talking about; and this makes thinks easy to maintain or track on several places - like story & jira & action list etc,
标题是第一行笔记, 不要急着调样式啊孩纸! Estimating stories. The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when th...
2013-06-08 09:49
标题是第一行笔记, 不要急着调样式啊孩纸!
Estimating stories.
The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when they write this story. Dev needs to find out the real requirement during the discussion with customers.
Estimating as a team, find out why some people give larger story points.
Everything takes 4 hours.
- start with goal stories - slice the cake a far better approach is to write the replacement stories such that each provides some level of end to end functionality - write closed stories a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth - put constraints om cards - size the story to the horizon focus on one an...
2016-04-02 15:59
- start with goal stories
- slice the cake
a far better approach is to write the replacement stories such that each provides some level of end to end functionality引自 guidelines for good stories
- write closed stories
a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth引自 guidelines for good stories
- put constraints om cards
- size the story to the horizon
focus on one and expand , then expand another (trawl stories required as below)
- role modeling via brain storm an initial set of user roles, organize the initial set, consolidate roles, refine the roles.)
- gather stories via techs as user interviews, questionnaires, observations, story-writing workshops
Summaries:
1. To identify stories, start by considering the goals of each user role in using the system
2. When splitting a story, try to come up with stories that cut through all layers of the applications;
3. Try to write stories that are of a size where the user feels justified in taking a coffee break after completing the story
4. Augment stories with other requirememts gathering or documenting techniques as necesar for the project's domain and environments
5. create constraint cards and either tape them to a shared wall or write tests to ensure the constraints are not violated
6. Write smaller stories for functionality the team will implement soon, and write broad, high-level stories for functionality further into the future
7. Keep the user interface out of the stories for as long as possible
8. When practical, include the user role when writing the story
9. Write stories in active voice.
10. Write stories for a single user
11. Have the customer rather the developer write the story
12. Keep user stories short, and dont forget their purpose as reminders to hold conversations
13. dont number story cards引自 guidelines for good stories
concerns for #11 & 13
#11: The customer indicates the customer user proxy like BA or actual customer? very seldom the real customer will help to write the story ? also, if they wrote, then the key concern is how to ensure the understanding between customer & BA is correct, so product owner can pass this correct to devs?
#13: agree of not mention feature abstractly. the thing is that we can use number and make this still concrete for talking about; and this makes thinks easy to maintain or track on several places - like story & jira & action list etc,
标题是第一行笔记, 不要急着调样式啊孩纸! Estimating stories. The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when th...
2013-06-08 09:49
标题是第一行笔记, 不要急着调样式啊孩纸!
Estimating stories.
The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when they write this story. Dev needs to find out the real requirement during the discussion with customers.
Estimating as a team, find out why some people give larger story points.
Everything takes 4 hours.
summary: - estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story; - better as ideal day for estimating rather than taking into different impacts factors in to consideration - estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals - triangulate an estimate by comparing it to other es...
2016-04-02 17:22
summary:
- estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story;
- better as ideal day for estimating rather than taking into different impacts factors in to consideration
- estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals
- triangulate an estimate by comparing it to other estimates
- whether or not a team programs in pairs has no impact on story point estimates. Paire programming affects the team's velocity, not their estimates
引自 Estimating user stories
Velocity means, on the specific approach of estimating of the efforts of your team, in one iteration, how many story points can be resolved
Story points for one feature is better to be consistent (using same way or indicator as estimation - could have triangulate methods (put different story points stories on the same board to see whether applicable or consistent from each other)
Story point for a same effort level estimation could change with time changes, due to the tech development, more familiar with the concepts or coding etc.
If story is not aggregated to the subsequent stories, the approach or standards of estimation could be changed to reflect the actual efforts.
summary: - estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story; - better as ideal day for estimating rather than taking into different impacts factors in to consideration - estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals - triangulate an estimate by comparing it to other es...
2016-04-02 17:22
summary:
- estimating stories in story points, which are relative estimates of the complexity, efforts or duration of a story;
- better as ideal day for estimating rather than taking into different impacts factors in to consideration
- estimating stories needs to be done by the team, and the estimates are owned by the tea, rather individuals
- triangulate an estimate by comparing it to other estimates
- whether or not a team programs in pairs has no impact on story point estimates. Paire programming affects the team's velocity, not their estimates
引自 Estimating user stories
Velocity means, on the specific approach of estimating of the efforts of your team, in one iteration, how many story points can be resolved
Story points for one feature is better to be consistent (using same way or indicator as estimation - could have triangulate methods (put different story points stories on the same board to see whether applicable or consistent from each other)
Story point for a same effort level estimation could change with time changes, due to the tech development, more familiar with the concepts or coding etc.
If story is not aggregated to the subsequent stories, the approach or standards of estimation could be changed to reflect the actual efforts.
- start with goal stories - slice the cake a far better approach is to write the replacement stories such that each provides some level of end to end functionality - write closed stories a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth - put constraints om cards - size the story to the horizon focus on one an...
2016-04-02 15:59
- start with goal stories
- slice the cake
a far better approach is to write the replacement stories such that each provides some level of end to end functionality引自 guidelines for good stories
- write closed stories
a closed story is one that finishes with the achievement of a meaningful goal and that allows the user to feel she has accomplished sth引自 guidelines for good stories
- put constraints om cards
- size the story to the horizon
focus on one and expand , then expand another (trawl stories required as below)
- role modeling via brain storm an initial set of user roles, organize the initial set, consolidate roles, refine the roles.)
- gather stories via techs as user interviews, questionnaires, observations, story-writing workshops
Summaries:
1. To identify stories, start by considering the goals of each user role in using the system
2. When splitting a story, try to come up with stories that cut through all layers of the applications;
3. Try to write stories that are of a size where the user feels justified in taking a coffee break after completing the story
4. Augment stories with other requirememts gathering or documenting techniques as necesar for the project's domain and environments
5. create constraint cards and either tape them to a shared wall or write tests to ensure the constraints are not violated
6. Write smaller stories for functionality the team will implement soon, and write broad, high-level stories for functionality further into the future
7. Keep the user interface out of the stories for as long as possible
8. When practical, include the user role when writing the story
9. Write stories in active voice.
10. Write stories for a single user
11. Have the customer rather the developer write the story
12. Keep user stories short, and dont forget their purpose as reminders to hold conversations
13. dont number story cards引自 guidelines for good stories
concerns for #11 & 13
#11: The customer indicates the customer user proxy like BA or actual customer? very seldom the real customer will help to write the story ? also, if they wrote, then the key concern is how to ensure the understanding between customer & BA is correct, so product owner can pass this correct to devs?
#13: agree of not mention feature abstractly. the thing is that we can use number and make this still concrete for talking about; and this makes thinks easy to maintain or track on several places - like story & jira & action list etc,
标题是第一行笔记, 不要急着调样式啊孩纸! Estimating stories. The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when th...
2013-06-08 09:49
标题是第一行笔记, 不要急着调样式啊孩纸!
Estimating stories.
The description of stories is a reminder for developers and business people to communicate. It is not the more details the better. The true meaning of a story can't be completely described by the text. Dev and customers usually have different opinions about one same sentence, and often customers don't know what they really need when they write this story. Dev needs to find out the real requirement during the discussion with customers.
Estimating as a team, find out why some people give larger story points.
Everything takes 4 hours.
FreshAIR
清华大学出版社2010版
李小水皮
清华大学出版社2010版
漫天清凉
清华大学出版社2019版
劈马喂柴
清华大学出版社2010版
陈建军
清华大学出版社2010版
0 有用 阿阮 2019-04-19
#11 电子版读了将近一半。从英文来说，比较简单，从它讲述的领域来说，简单明了，让我对agile development有了一个初步的了解
0 有用 i'm Vincent 2008-07-11
个人认为只是介绍了一种方法，或者说用一种方法来引导你的思维方式，离“真理”貌似还有点距离。
0 有用 络绎很无聊地 2013-06-13
无论怎样, 还是读完了... 这样的方式能给传统行业软件开发带来多大的改变, 只能靠自己脑补了.
0 有用 离心力 2012-05-16
确实不错，对于我这种技术盲来说，觉得特别实用易懂！十分精彩！
0 有用 whunmr 2016-09-05
写得简单明白.
0 有用 Chandelier 2019-12-24
比较基础 2018年读的
0 有用 阿阮 2019-04-19
#11 电子版读了将近一半。从英文来说，比较简单，从它讲述的领域来说，简单明了，让我对agile development有了一个初步的了解
0 有用 zidane 2018-09-11
给出了结合user story的整个敏捷过程框架，对于敏捷入门很有帮助！
0 有用 whunmr 2016-09-05
写得简单明白.
0 有用 F.L. 2015-03-30
有蛮多问题想问的。