首页 > 代码库 > 如何编写敏捷开发中的user story
如何编写敏捷开发中的user story
http://blog.csdn.net/chengyb74/article/details/4762247
对于敏捷开发来说,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可以包括框架,技术等内容。
如何编写敏捷开发中的user story
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。