敏捷开发（agile）中story

Agile概念的比较详细的说明见：http://www.cnblogs.com/astar/archive/2012/02/28/Scrum.html

Story概念：

• User Story是敏捷开发的基础，它不同于传统的瀑布式开发方式，而是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务。
• User Story是从用户的角度对系统的某个功能模块所作的简短描述
• 一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值
• User Story是敏捷开发和管理的核心，要确保Story的输出质量。
  

Story优点和好处：

• 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划分原则（INVEST规则）：

• 独立性（Independent）：一定要保证Story在功能上的独立，尽量不要有Story之间的依赖，否则会大大影响将来的开发和测试。
• 可谈判性（Negotiable）：Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。
• 有价值性（Valuable）： Story需要体现出对于用户的价值。
• 可估计性（Estimable）：Story应可以估计出Task的开发时间。
• 大小合适（Sized Right）：关于Story的粒度，建议的开发工作量是3-5天（包含针对Story所做的开发者自测工作量），如果Story不能拆分到3-5天的开发粒度，则一定要确保该Story在一个迭代周期内可开发测试完成。
• 可测试性（Testable）：要从可测试性考虑需求，同时要考虑能够独立测试，每个任务都应有Junit Test。另外注意，伴随Story要同时输出可接受性测试用例（Acceptance Test Case，以下简称AT），用于验证Story是否开发完成，可以给测试人员做Story测试。AT用例在Story协作阶段只是对测试要点、场景的描述，在迭代开发阶段可以继续补充和完善。

Task：

• 为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。
• 每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。
  

User Story模板：

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

一些经验：

• 永远不要在User Story中使用And和Or，因为这是些分支词就表示分支任务，把它们拆成两个Story.
• 数据整理：通常情况下1个sprint(2周一次迭代)可以做4～5个Story，极端大的Story不可大于1个sprint。
• 数据整理：通常情况下1个sprint(2周一次迭代)可以做50个左右的Task。
• User Story用于描述用户故事，不要包括任何的技术，框架等内容。Task可以包括框架，技术等内容。