敏捷故事-背景一

软件需求是一个沟通的过程

如何规避风险

基本原则：

• 不要在项目开始阶段就做一套完善的，包罗万象的决策
• 把各个决策分散在项目过程中

什么是用户故事

用户故事描述了对用户、软件或软件购买者有价值的功能

由以下三个方面组成：

• 一份书面的故事描述，用于做计划和提示
• 有关故事的对话，用于具体化故事细节
• 测试，用来表达和编档故事细节并且可以用于确定故事何时完成

关键在于故事应该以对用户有价值的方式写下来。

细节在哪里

以用户搜索商品为例

• 用户可以搜索哪些商品
• 需要展示哪些与用户匹配的标签
• 搜索记录可以保存吗

多个小故事远胜于一个大故事

例如 用户搜索商品

• 用户可以通过商品名、商户名、分类来搜索商品
• 用户可以查看每个商品的详情和销量
• 用户可以查看每个商品相关的买家秀

我们需要不断的分解故事到一个合适的程度

与其写下这些故事细节，还不如让开发团队和客户讨论这些细节，即在这些细节变得重要时才讨论

讨论才是关键

故事并不具有契约性，达成的协议将由测试来记录，这些测试将演示故事是否被正确开发

必须多长时间完成

“必须多长时间完成？”这个问题能够从某种角度来了解项目用户的期望是什么

用户的期望最好以验收测试的形式记录下来

开发人员如果能够了解用户的期望，便能知道是什么时候算是完成了客户要求的功能

客户团队

在一个理想的项目中，一般有一个专职人员来为开发人员的工作排优先级，回答开发人员的所有问题，以及在软件完成时，写下所有故事。

这个客户团队中应该包括确保软件满足用户需求的所有人，这意味着这个客户团队应该包括产品经理、测试人员、实际用户和交互设计师

---

本文同步自掘金

如果发现内容有误或需要更新，请访问掘金原文进行查看。