象观敏捷之旅-初探UserStory

D项目一期临近上线，开始考虑二期的需求。

项目一期的需求分析和编写PRD的方式存在很多问题，最主要的是语言本身是模糊的，“详细”的需求文档会造成“确定性的幻觉”，让我们以为需求细节都在文档里了，缺乏有效沟通，导致开发出不符合预期的功能。3月22日的那次需求变更记忆犹新，需求细节理解的不一致最终导致产品模型和流程的变更，涉及交互、前端和后台的多处修改，完成开发的时间延期4天。急需找一种方法应对这样的情况。

大家想到了敏捷开发和BDD，通过UserStory来描述需求，既是PRD也是测试用例，能解决文本需求的多义性也能响应变化。

UserStory是一段简单的功能描述，以用户的观点编写有价值的功能。它是一种极简主义，只要求写下最有价值不要忘记的内容，而且能够让我们足以评估工作量与客户沟通。与其说它是文档，不如说它代表用户的一个需求而已，因为具体细节将延后到开发时才会确认。

每个UserStory由卡片、交谈和确认组成，简称3C：
card：编写故事描述，用于项目计划并做为需求备注（故事的基本功能）
conversation：故事的需求细节，通过与用户之间交谈来补充。
confirmation： 决定需求完整的关键因素，是由大量测试传递和记录的。

简单的范例：
As a (role of user), I want (some feature) so that (some business value).
作为一个（某角色的用户），我可以做（某功能）如此可以有（某业务价值）

UserStory的特点：
非常强调口头上的沟通（可避免文本需求的多义性）
对每个人都容易了解
大小刚好适合计划
适合迭代开发
鼓励延后细节（迅速启动开发，在需要的时候再明确细节）
鼓励人人参与的设计

周末两天的学习对UserStory有了大致的认识，但是UserStory和UserCase孰好孰坏还需要摸索，需求细节颗粒度的把握是重点。总感觉UserStory更像在描述用户需求，UserCase是描述产品需求，说不定口头上的沟通可以弥补需求细节理解的一致性，值得一试。