第 4 章 搜集故事
创建故事够用就行
1、传统规范过程的特征是它过分强调在项目早期正确地获取并写出所有的需求。
2、敏捷项目则承认没有一种理想的方法可以在一个单一阶段获取到所有的用户故事。
3、用户故事有一个时间维度：随着时间的推移以及先前迭代中加入产品的故事，一个故事的相关性（relevance）会有所变化。
4、应该在早期尝试编写我们可以编写的故事，即便许多故事还只能停留在十分笼统的阶段。
5、故事发布时间越往后，我们越不需要编写得那么详细。
创建故事最有用的一些方法：
- 用户访谈
访谈成功的关键之一是选择正确的受访者，应该访问真实用户，担任不同角色的真实用户。
要想获取用户的本质需求，最好的技巧是提问，而且要提开放式问题和背景无关问题。
（1）询问开放式问题可以让调查对象表达更深入的意见。
（2）最好从背景无关的问题开始提问，这样就有可能从用户那里获得更多样化的回答。 - 问卷调查
在需要得到大量用户关于某些具体问题的回答时，问卷是非常有用的。
然而问卷不适合作为拖网捕获新故事的主要方法。 - 观察
观察用户实际使用软件的情况。可以让你快速直接地从用户那里获得反馈，从而可以更早、更频繁地发布软件。 - 故事编写工作坊
故事编写工作坊是开发人员、用户、产品客户和其他队编写故事有帮助的人共同参加的会议。
（1）在工作坊期间，参与人员编写尽可能多的故事。
（2）不对故事排优先级，以后客户有机会排优先级。
（3）故事编写工作坊是快速捕捞故事最有效的方法。
（4）良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法。
1.png
通过画上面这个原型，得到以下故事：
- 求职者可以发布他的简历。
- 雇主可以发布工作。
- 雇主可以查看提交的简历。
- 求职者可以搜索工作
- 求职者可以看到符合搜索条件的工作。
- 求职者可以看到指定工作的详细信息。
画原型的过程中，问一些有助于找到遗漏故事的问题：
- 用户接下来最有可能做什么？
- 用户会在这里犯什么错误？
- 用户会有什么困惑？
- 用户需要什么额外的信息？
注意事项：
1、维护一个待办问题列表，留着以后再来解决。
2、在故事编写工作坊期间，我们应该把重点放在数量上而不是质量上。
3、不要为每个故事都陷入长时间的讨论中。
4、如果一个故事是多余的或者能被更好的故事替换，就扔掉这个故事。同样，当客户为发布而确定故事优先级时，他可以给不好的故事安排低优先级。
5、当遇到困难时，可以看看竞争对手的产品或类似的产品。
6、留意在故事编写工作坊中谁的贡献最多。对于沉默者应该去谈谈，看他是不是不适应这个过程，或者不愿意在大家面前表达自己的想法。因此不要在整个过程中评价某个故事好或坏。
小结
- 能够引出及捕捉需求这一想法是错误的。
- 拖网捕鱼的比喻非常有用，它说明了需求有不同的大小，需求会随着时间的推移变化，需要一些技巧来发现需求。
- 即使敏捷流程支持需求的后期涌现，依然需要对预期的发布进行展望并开始写下容易发现的故事。
- 可以通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来发现用户故事。
- 使用多种方法比过度使用一种方法更能获得好的效果。
- 通过开放式、与背景无关的提问更容易获得有用的答案。
开发人员职责
- 负责理解并使用多种技巧来捕捞用户故事。
- 负责知道怎么使用开放式和背景无关的提问。
客户职责
- 负责理解并使用多种技巧来捕捞用户故事。
- 负责尽早写更多的用户故事。
- 作为软件用户的主要代表，负责和他们多沟通。
- 了解怎么使用开放式和背景无关的提问。
- 如果需要关于编写故事的帮助，负责安排并举办一次或多次故事编写工作坊。
- 负责确保在捕捞故事过程中考虑所有用户角色。
