4.3.4. 故事编写工作坊

故事编写工作坊是开发人员、用户、产品和其他对编写故事有帮助的人共同参加的会议。

在工作坊期间，参与人员编写尽可能多的故事，此时不对故事排优先级。

正确举办故事编写工作坊可以非常快速的编写大量故事。良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法。可以把一个简单原型画在纸上，笔记本上，白板上，并画出软件内部高层之间的交互。在工作坊中，随着参与者对用户在使用软件过程中可能要做的事情进行头脑风暴，不断构建原型。这并不是像传统原型法或联合应用设计中，要确定实际界面和字段，只是为了从概念上确定工作流。

故事与简单原型

比如，下面就是通过故事编写工作坊整理的招聘网站的简单原型。

其中：

• 每个方框代表着网站的一个新组件
• 方框中带有加粗的文字是组件的标题
• 标题下面是组件要做的和包含的列表
• 方框间的箭头标示组件间的链接

对于一个网站，组件可能是一个新的页面或当前页面的一块区域。所以，每一个链接意味着弹出一个新页面或者在同一个页面上显示信息。

比如，搜索工作可能是一个页面或者首页上的一块区域。

开始画原型前，首先要决定从哪种用户角色开始。需要用每个角色来重复这个过程，不论什么顺序。然后，画一个空的方框，告诉参与者这是软件的主界面，询问他们当前这个用户角色能在这个界面做什么。即使你现在还不知道主界面是什么，有什么用，这也没有关系。参与者会想出角色会做什么。对角色做的每一件事情，画一条指向一个新的方框，然后写一个故事。

比如上面的图，我们可以得出以下故事：

• 求职者可以发布他的简历
• 雇主可以发布工作
• 求职者可以搜索工作
• 求职者可以看到搜索条件的工作
• 求职者可以看到指定工作的详细信息

这些故事都不需要界面是该如何设计。但是，走一遍流程可以帮助大家想出尽可能多的故事。

我发现深度优先的方法最有效：

对于第一个组件，写下主要的细节，接着是与第一个组件相连的组件B，一样写下其主要的细节。然后是与B相连的组件，而不是回到第一个组件A，描述其他与A相连的组件。

广度优先的办法非常不容易理解，因为很难记住自己刚才在哪条功能线上。

另外，我们要尽快扔掉简单原型

在画好简单原型后的几天内，一定要扔掉或擦掉它、 原型并不是开发流程中的一个长期工件，因为长期留着可能会导致不必要的困惑。 如果觉得在故事编写工作坊中还有发现所有故事，可以把原型保留几天，再看看是否还能写出一些漏掉的故事，然后再考虑扔掉它。

在画原型的过程中，问一些有助于找到遗漏故事的问题，示例如下：

• 用户接下来最有可能做什么？
• 用户会在这里犯什么错误？
• 在这里，用户会有什么困惑？

• 用户需要什么额外的信息？

  在问这些问题是，考虑一下当时用户的角色。许多答案都和用户当时角色有关。

  原则

  在故事编写工作坊期间，我们有一些工作的原则需要大家都了解并且遵守：

• 应该把重点放在数量上，而不是质量上。

• 即使最后会用电子方式保存故事，但在工作坊里最好还是使用卡片。
• 只需把想法记录下来就行。最初大家觉得不好的故事经过几个小时后可能会变得很棒，或者会激发我们相处其他故事。
• 不要为每个故事都陷入长时间的讨论中。

• 如果一个故事是多余或者能被更好的故事替换，就扔掉这个故事。

  小技巧

  另外，还有一些小技巧能够让工作坊进行的更加顺利。

• 可以维护一个待办问题列表，将一些当前不是最重要的故事记录其中，留着以后再来解决。

• 如果我们卡在某个点过不去，这时不妨看看竞争对手的产品或类似的产品。

• 留意在工作坊中成员的贡献。有些参与者在大部分或者整个期间都保持沉默，可以在中间休息的时候和这个参与者谈谈，确定他并不是不适宜这个过程。要让参与者觉得大家只是在记录而不是评价故事，会更乐于参与。

  最后，再次重申故事编写工作坊中的讨论应该在较高层面上。我们的目的是在短时间内写出更多的故事。这不是设计界面或解决问题的时候。