Open felix-cao opened 5 years ago
User story 是从最终用户的角度对软件的 feature 进行的非正式、一般性的解释，目的是阐明软件功能将如何为客户提供价值。
User story
feature
User story 将最终用户置于敏捷开发的对话中心。User story 是敏捷开发中以人为本的最重要体现，以人为本是敏捷开发中的一个关键部分。
User story 使用非技术语言描写功能需求的来龙去脉，团队成员在阅读User story 之后便知道：为什么？干什么？创造的价值是什么？--- User Stories with Examples and Template
因此，User story 就是从最终用户的角度来描述用户渴望得到的功能，传递需求信息。User story 不同于传统需求规格说明书，以简化的形式促进团队交流、降低修改成本、灵活调整接受变化，同时User story 以验收驱动的定义形式让所有干系人对最终的目标建立共识。
To Do list 让团队专注于需要核对的任务清单上，而 User story 使团队专注于为用户解决问题
To Do list
User story 的一个核心在于对话（Conversation），客户和开发人员可以就某个User story` 深入的交流，对每个重要的细节达成共识。这避免了通过文字记录而可能导致的不精确性或语义多重性的问题。
Conversation），客户和开发人员可以就某个
定义了最终目标后，团队可以共同决定如何最好地为用户服务并实现该目标。
User story 驱动创造性的解决方案，User story 鼓励团队批判性和创造性地思考如何最好地解决最终目标。
团队解决每一个 User story 都会享受到一个小小的挑战和一个小小的胜利，这就是给团队提供源源不断的动力
User story 使用一两句简洁明的日常语言写成，并且向用户或客户显示价值，不涉及专业的技术术语，从而使得用户和开发者理解起来都很容易。
进入 Sprint 的 User story 可以拆分为若干可开发测试完成的 Sub-task，保证一个User story在一个迭代周期内可以完成交付的。
Sprint
Sub-task
用简单的句子来表达 User story ，结构如下
“As a [persona], I [want to], [so that].”
作为一个<用户>, 我想要<功能>, 以便于<价值>
谁要使用这个功能，即与软件系统交互的真实用户
需要完成什么样的功能，指的是系统的行为
system
为什么需要这样的功能？这个功能带来什么价值？
Ron Jeffries的3个C 关于用户故事，Ron Jeffries用3个C来描述它： 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
如何写一个好的User story？一个优秀的 story 应该具备以下特点：
story
独立性（Independent），要尽可能的让一个User story独立于其他的User story。User story之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合User story和分解User story来减少依赖性。
可协商性（Negotiable），一个User story的内容要是可以协商的，User story不是合同。一个User story卡片上只是对User story的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个User story卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable），每个User story必须对客户具有价值（无论是用户还是购买方）。一个让User story有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个User story并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable） ，开发团队需要去估计一个User story以便确定优先级，工作量，安排计划。但是让开发者难以估计User story的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者User story太大了（这时需要把User story切分成小些的）。
短小（Small） ， 一个好的User story在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。User story越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）， 一个User story要是可以测试的，以便于确认它是可以完成的。如果一个User story不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的User story例子：软件应该是易于使用的。
一、什么是 User story
User story是从最终用户的角度对软件的feature进行的非正式、一般性的解释，目的是阐明软件功能将如何为客户提供价值。User story将最终用户置于敏捷开发的对话中心。User story是敏捷开发中以人为本的最重要体现，以人为本是敏捷开发中的一个关键部分。User story使用非技术语言描写功能需求的来龙去脉，团队成员在阅读User story之后便知道：为什么？干什么？创造的价值是什么？--- User Stories with Examples and Template因此，
User story就是从最终用户的角度来描述用户渴望得到的功能，传递需求信息。User story不同于传统需求规格说明书，以简化的形式促进团队交流、降低修改成本、灵活调整接受变化，同时User story以验收驱动的定义形式让所有干系人对最终的目标建立共识。二、User story 的优点
2.1、聚焦用户
To Do list让团队专注于需要核对的任务清单上，而User story使团队专注于为用户解决问题2.2、强调沟通
User story的一个核心在于对话（Conversation），客户和开发人员可以就某个User story` 深入的交流，对每个重要的细节达成共识。这避免了通过文字记录而可能导致的不精确性或语义多重性的问题。2.3、实现协作
定义了最终目标后，团队可以共同决定如何最好地为用户服务并实现该目标。
2.4、驱动创造性的解决方案
User story驱动创造性的解决方案，User story鼓励团队批判性和创造性地思考如何最好地解决最终目标。2.5、团队动力
团队解决每一个
User story都会享受到一个小小的挑战和一个小小的胜利，这就是给团队提供源源不断的动力2.6、人人都可以理解的
User storyUser story使用一两句简洁明的日常语言写成，并且向用户或客户显示价值，不涉及专业的技术术语，从而使得用户和开发者理解起来都很容易。2.7、适合于迭代开发
进入
Sprint的User story可以拆分为若干可开发测试完成的Sub-task，保证一个User story在一个迭代周期内可以完成交付的。三、User sotry 模板及案例
3.1、三段式模板：Role-Action-Benefits
用简单的句子来表达
User story，结构如下“As a [persona], I [want to], [so that].”
作为一个<用户>, 我想要<功能>, 以便于<价值>
3.2、三要素
角色(Role)
谁要使用这个功能，即与软件系统交互的真实用户
行为(Action)
需要完成什么样的功能，指的是系统的行为
system是隐性的，不会写在User story中价值(Benefits)
为什么需要这样的功能？这个功能带来什么价值？
User story可能共享相同的利益陈述。3.3、案例
Ron Jeffries的3个C 关于用户故事，Ron Jeffries用3个C来描述它： 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
四、六个特征: INVEST
如何写一个好的
User story？一个优秀的story应该具备以下特点：独立性（Independent），要尽可能的让一个
User story独立于其他的User story。User story之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合User story和分解User story来减少依赖性。可协商性（Negotiable），一个
User story的内容要是可以协商的，User story不是合同。一个User story卡片上只是对User story的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个User story卡带有了太多的细节，实际上限制了和用户的沟通。有价值（Valuable），每个
User story必须对客户具有价值（无论是用户还是购买方）。一个让User story有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个User story并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。可以估算性（Estimable） ，开发团队需要去估计一个
User story以便确定优先级，工作量，安排计划。但是让开发者难以估计User story的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者User story太大了（这时需要把User story切分成小些的）。短小（Small） ， 一个好的
User story在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。User story越大，在安排计划，工作量估算等方面的风险就会越大。可测试性（Testable）， 一个
User story要是可以测试的，以便于确认它是可以完成的。如果一个User story不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的User story例子：软件应该是易于使用的。Reference