暑假做项目的时候有写 User Story ，但是当时也没有正式的总结过相关的一些原则，有看到一篇文章，写的就是写 User Story 需要注意的点，10 Tips for Writing Good User StoriesRead more ，所以今天来简单总结一下 User Story 的一些原则。
什么是 User Story？
** User Story ** 是一段简单的功能叙述，以客户或者使用者的观点撰写下有价值的功能，代表客户的一个需求。
初学范本
作为一个 XXX，我希望可以 XXX，这样我就可以 XXX。
原则 (INVEST)
-
Independent(独立的)
- 每个 User Story 都是独立的，不要考虑与该 User Story 无关的事情。
** 例如 **
作为一个用户，我希望可以看到登录界面，这样我就可以登录到系统中。
那么就不要考虑与登录无关的事情，专注于登录就好。
-
Negotiable(可协商的)
- User Story 不是写好了就不修改了，客户和开发者需要经常沟通来确定最终的 User Story。因为很多细节往往在开发过程中才会考虑到。
** 例如 **
用户可以选择学校
假设这是最初的 User Story 之一，开发到了一定阶段，会出现新的问题:
用户选择学校之后可不可以选择专业？
这就需要开发者和客户好好沟通，而且是口头沟通，以达到最好的效果。
-
Valuable(有价值的)
- User Story 对于用户要有一定的实现价值。
** 例如 **
作为用户，我希望点击逻辑题，可以进入到逻辑题页面，这样我就可以开始做题了。
对于用户来说，这个 User Story 的价值就是他可以通过点击逻辑题，进入到逻辑题页面，这样才可以答题。
-
Estimable(可估的)
- 对开发人员来说，能估算故事的大小，或者是把故事变为可用的代码的时间量是很重要的。一般有以下3个原因会导致故事不可估计。
- 开发人员缺少领域知识
- 开发人员缺少技术知识
- 故事太大了
- 对开发人员来说，能估算故事的大小，或者是把故事变为可用的代码的时间量是很重要的。一般有以下3个原因会导致故事不可估计。
** 例如 **
一个找工作的人可以找到一份工作
这个故事就太大了，不可估计。我们要估计它，就要把它分解成多个更小的故事。
-
Small(较小的)
- 故事的大小很关键，故事太大或者太小，都无助于制定计划。
- 合适的故事大小最终取决于团队、它的容量及所使用的技术。
** 例如 **
用户可以登录
这个就有点大，就可以分为：
- 作为一个用户，如果输入正确账号及密码，我可以登录到系统中
- 作为一个用户，如果输入错误密码，那么我将无法登录到系统中
-
Testable(可测试的)
- 必须是可测试的，成功通过测试可以证明开发人员正确的实现了 User Story。
** 例如 **
用户绝不需要花很多时间等待窗口出现。
这个就是不可测试的。这个 User Story 可以改为：
在95%的情况下，新窗口会在2秒内打开。
总结
总的来说，User Story 就是要站在用户的角度来写，在写的过程中遵循上述几条原则即可。
希望大家都可以写出符合规则的 User Story ，干巴爹！
