Question

如何编写敏捷开发中的user story

Answer 1

对于敏捷开发来说，User Story是开发的基础，它不同于传统的瀑布式开发方式，而是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务。
优点和好处
Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
Allowing developer and client to discuss requirements throughout the project lifetime
Needing very little maintenance
Only being considered at the time of use
Maintaining a close customer contact
Allow projects to be broken into small increments
Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
May be easier to estimate development effort

User Story模板

User Story可以遵循以下模板：As a <User Type> I want to <achieve goal> So that I can <get some value>
翻译成中文就是：作为一个<某种类型的用户>，我要<达成某些目的>，我这么做的原因是<开发的价值>。

User Story应遵循INVEST规则
Independent 独立性，避免与其他Story的依赖性。
Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。
Valueable 有价值性， Story需要体现出对于用户的价值
Estimable 可估计性，Story应可以估计出Task的开发时间。
Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.
一些经验：
永远不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.
数据整理：通常情况下1个sprint(2周一次迭代)可以做4～5个Story，极端大的Story不可大于1个sprint。
数据整理：通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。
本答案来自于互联网，仅供参考学习作用
如果您对我的回答有不满意的地方，还请您继续追问；
答题不易，互相理解，互相帮助！

Answer 2

对于敏捷开发来说，User Story是开发的基础，它不同于传统的瀑布式开发方式，而是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务。
优点和好处
Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
Allowing developer and client to discuss requirements throughout the project lifetime
Needing very little maintenance
Only being considered at the time of use
Maintaining a close customer contact
Allow projects to be broken into small increments
Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
May be easier to estimate development effort

User Story模板

User Story可以遵循以下模板:As a <User Type> I want to <achieve goal> So that I can <get some value>
翻译成中文就是:作为一个<某种类型的用户>，我要<达成某些目的>，我这么做的原因是<开发的价值>。

User Story应遵循INVEST规则
Independent 独立性，避免与其他Story的依赖性。
Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract， Stories不必太过详细，开发人员可以给出适当的建议。
Valueable 有价值性， Story需要体现出对于用户的价值
Estimable 可估计性，Story应可以估计出Task的开发时间。
Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.
一些经验:
永远不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.
数据整理:通常情况下1个sprint(2周一次迭代)可以做4~5个Story，极端大的Story不可大于1个sprint。
数据整理:通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。
本答案来自于互联网，仅供参考学习作用
如果您对我的回答有不满意的地方，还请您继续追问；
答题不易，互相理解，互相帮助。

Answer 3

用户故事是敏捷开发中提出来的一个概念，从用户角度来描述用户渴望得到的功能。是一种对需求的描述方式，当我们给研发讲需求时，用户故事可以让研发了解需求的背景，进一步理解需求。

用户故事的格式通常为：

作为一个xxx（某类用户），我要xxx（做一件事），从而达到xxx（某一结果或动机）。

在写用户故事之前，我们可以思考：

（1）这是一群怎样的用户？

（2）在什么场景下，想解决什么问题？

（3）解决问题的过程中碰到了哪些问题？

（4）最后用户想要怎么解决？

另外，我们在写用户故事时，还要注意遵循「INVEST」原则：

独立的 (Independent）：独立原则要求编写的用户故事之问应当是相互独立而不是相互依赖的。用户故事相互独立可以降低需求的优先级排序和迭代计划制定的难度。

可讨论的 (Negotiable）：用户故事是可讨论的，意味着故事描述的需求不是巨细无遗的，它只是对需求的简短描述，更多的细节将在与用户的讨论中产生。

有价值的 (Valuable）：用户故事必须体现出用户关心的价值。

可估计的 (Estimable）：用户故事中的需求描述虽然不够具体详细，但是也必须能够让开发人员对故事的大小和开发的工作量进行估计，否则就无法制定迭代计划。

小的(Small) ：用户故事应尽可能地避免史诗式的巨型故事，小型故事既便于估计，也便于制定迭代计划和跟踪监控。

可测试的 (Testable）：用户故事必须是可测试的，这样才方便验证故事是否完成。