听说用户故事优于用例？我到底该用哪种方法捕获需求？

用户故事是敏捷开发中一种常用的需求捕获手段，本文会先对它做个简要介绍，再比较其和用例的不同，最后附上我的一点小体会。不想看介绍的可以直接跳到比较部分。

一、用户故事

1. 用户故事（User Story）：描述对软件（或系统）用户或客户有价值的功能,只是需求描述，而不是详细的需求规范。一种敏捷开发常用的需求捕获手段。

2. 3C原则：

卡片（Card） – 用户故事一般写在小的卡片上。卡片正面写上故事的简短描述，格式为：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。卡片背面协商测试点，可随时补充。

交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的频繁的交流沟通。

确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

可能是在这样的卡片上写下用户故事

写完故事贴到墙上，确保所有人都能时刻查阅

3. Invest原则：

独立性（Independent）—
要尽可能的让一个用户故事独立于其他的用户故事，可以独立被开发、验收、测试。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。

这里我犯过一个错误，今年8月时我接了一个物料管理的Meidum级的开发需求。因我将该需求拆成小isssue时拆得太细了，导致后续的开发互相挚肘，不能独立完成开发、完成验收测试。开发、BA、测试、项管都觉苦不堪言。