User Story 笔记1

1. User Story是独立的， 有商业价值的模块

2. Bug Fixing和Task都不是User Story, 因为它没有阐述它的价值

3. 当你被分配到一个任务是你应该问一问客户它的价值是什么， 这样你就不会被局限在一种解决方案了

4. User Story Cards分成三个部分

   1）Card - User Story的载体， 用来计划和提示

   2）Converstation - 通过沟通来澄清User Story的要点和细节

   3）Confirmation - 确认接收测试的细节，确定需要进行什么样的测试来确认User Story的完成和正确

5. 物理的卡片要强于虚拟的卡片，除非是分布式开发一定要尽量使用物理载体，但是要确保卡片不被遗失

6. User Story 定义

  As a [User role] i want to [action], so I can [reason/goal].

  For example, As a registered user, I want to login, so I can access subscriber-only content.

  Who - user role

  What - action/ feature/ function

  Why - goal/ reason/ value

7. 用户接收测试

  为了防止scope变大， 验收标准必须清晰描述出来

  格式：Given..., When I do ..., Then I exepect ...

  项目应该以把这些验收测试自动化

  跟QA合作来优化你的测试

  和大家一起Brain Storming出可能多的标准， 不一定非要做到100%， 80%-90%也足够了

  验收标准一定会有正反两面

8. User Story 卡片的内容

Tilte (Headline)

一句或几句话描述用户的需求

估算 (可以体现User Story尺寸的差异， 并非是实际开发的开销的差异)

背面写接收测试样例

手写在序列化的卡片上

卡片被排序，管理，跟踪