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

 

对于敏捷开发来说，User Story是开发的基础，它不同于传统的瀑布式开发方式，而是把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务。

优点和好处

1. Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
2. Allowing developer and client to discuss requirements throughout the project lifetime
3. Needing very little maintenance
4. Only being considered at the time of use
5. Maintaining a close customer contact
6. Allow projects to be broken into small increments
7. Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
8. 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规则

1. Independent 独立性，避免与其他Story的依赖性。
2. Negotiable 可谈判性，Scrum中的story不是瀑布开始某事中的Contract, Stories不必太过详细，开发人员可以给出适当的建议。
3. Valueable 有价值性， Story需要体现出对于用户的价值
4. Estimable 可估计性，Story应可以估计出Task的开发时间。
5. Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
6. 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可以包括框架，技术等内容。