杂谈--User Story

本篇用于给自己后续慢慢看，对敏捷感兴趣的小伙伴，可以自行去看官方文档或者各种网站的视频讲解，更详细。

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

一. INVEST原则

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

Story 应该遵循 INVEST原则

• Independent 独立性，避免与其他Story的依赖性。
• Negotiable 可谈判性，Stories不必太过详细，开发人员可以给出适当的建议。
• Valueable 有价值性， Story需要体现出对于用户的价值
• Estimable 可估计性，Story应可以估计出Task的开发时间。
• Sized Right 合理的尺寸， Stories应该尽量小，并且使得团队尽量在1个sprint(2 weeks)中完成。
• Testable 可测试性， User Story应该是可以测试的，最好有界面可以测试和自动化测试。每个任务都应有Junit Test.

user story: 代表一个 user feature。基于INVEST原则写的story，应该是大家看懂的。如果哪个角色看不懂一个 story，那么大家会认为有可能这个 story本身有问题。我们可以让PO去澄清一下，追加 comments补充或者修改一下 story的requirement的描述。一定要强调的是，user story一定是从用户的角度来描述用户渴望得到的功能。尽管 user story拥有模板，但是不提倡一个 story就一句话描述，验收条件对一个 story来说至关重要。我们在jira或者confluence上面同样还有 Epic的概念，Epic 翻译成史诗，即非常大（巨大）的用户故事。一个 Epic会拆分成多个 user story。

user story 的 3C原则：3C是收集用户故事的有效手段，包括以下。

• 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。
• 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
• 确认（Confirmation）：通过验收测试确认用户故事被正确完成。

《敏捷估算与规划》书中介绍了两种基本的方法： 理想人天法和故事点法。

相对来说理想人天法是在需求非常明确情况下，进行编码和测试工作所花费的时间。问题是对于同一个项目不同的人根据其能力和经验的不同，会有不同的理想人天。实际项目应用中，最好别用。

故事点法就是按照故事卡的规模和难度，给予每张故事卡一个点数。这也是实际项目中用到的比较多的。需要注意一点，1点数不等于1人天，点数代表的是难度系数。后续可以通过点数以一定比例整理成人天数，比例规则不同项目不同预算不同分析。