对于Scrum开发来说，User Story是开发的基础，它不同于传统的UDD开发方式，而是把原本需求拆成最小粒度的Story，以方便Scrum小组拆分Task，估计开发
时间，领取开发任务。
User Story不需要太过于详细，只有在正式开发时，做详细设计时在进入Detail阶段，如果初期时间估算不准确，实际工作量增多时，Sprint Chart需要适当的
Burn-up。
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.
经验：
1. 永远不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.
2. 数据整理：通常情况下1个sprint(2周一次迭代)可以做4～5个Story，极端大的Story不可大于1个sprint。
3. 数据整理：通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
4. User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。
我们通常用User Story来描述Backlog里的各个Backlog项，User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能，以及>这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。
User Story要由Stakeholder（利益相关者）来编写。User Story的形式很简单，人们可以很容易地掌握编写User Story的方法。这样就可以保证是由与项目相关领域专家们来
编写User Story，而不是开发人员。
我们通常把User Story写在一张小卡片上，同时在卡片上标明它的优先级和预计完成时间，以便开发人员根据任务的优先级来制定Sprint Backlog。而且，Stakeholder可以随时更改一个Story的优先级，那么此时开发人员就应该相应地调整Story的开发次序。
一个User Story的大小和复杂度应该在一个Sprint中开发完毕为宜。如果User Story太大，可能会导致对它的开发横跨几个Sprint。这种情况是需要避免的。此时就应该将这个User Story分解。
为了能及时、高效地完成每个Story，Scrum团队会把每个Story分解成若干个Task。每个Task都是可以在明确的时间内完成的，而且时间是以小时为计量单位的。特别提示：每个Task的时间最好不要超过8小时，就是要保证1个工作日内完成，如果做计划时发现有些Task的时间超过了8小时，就说明Task的划分有问题，需要特别注意。
-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;