搜集用户故事

一、传统方法与敏捷方法的区别：

        传统方法的特征是过分强调在项目早期正确地获取并写出所有的需求；

        敏捷项目的特征是没有一种理想的方法可以在一个单一阶段获取到所有的用户需求。

二、项目开始时用户故事整理到什么程度：

        四个字，够用就行。可以也要在项目开始前尽可能多的写出用户故事，但并不是要在项目开始前要花费几个月的时间去写用户故事，相反，它要求大家展望未来一个 发布时间，故事发布的时间越往后，我们就不在需要详细的写这个故事，可以用一个占位符来表示，比如：客户说想要一个报表功能。不需要详细的去描述这个功能 （如：用什么样的方式来实现）。

三、捕捉用户故事：

      不同大小的网用来捕获不同的大小的需求，第一遍，我们可以用大网眼的网捞一遍需求池，来得到所有大的需求，通过这些大需求对软件形成整体的感觉，接下来使 用网眼稍微小一些的网再来捞一遍，可以得到中等大小的需求，在开始还没有必要顾及那些小的需求。（可能会漏掉一些需求，但不要再去花费的时间捕捞了）

四、故事的重要性：

     也许在捕捞的时候会漏掉一些需求，因为这个需求对软件来说不是很重要，故事像鱼一样，会长大，也会死亡，根据每轮的迭代的反馈，会向事先不可预知的方向发展，有些需求可以会变的不在重要，甚至已经没有用了；以前漏掉（认为不重要）的需求可能会变的越来越重要。

五、捕捉用户事故的方法：

1）用户访谈：这可能是每个团队都想要的，与客户面对面的交谈。访谈成功的关键在于选择正确的受访者，尽可能的访问真实用户，还应该访问担任不同角色的用 户。与用户交谈时，不要认为用户想的就一定是对的，也许你的观点、做法比他想到的要更好，让他更加的满意。交谈的方式也很重要，我访问时，尽可能的使用开 放式问题，不要使用封闭式的问题。最好从与背景无关的问题开始问起。如果从具体的问题开始提问，很可能会漏掉很多故事。不要让受访者对你提问的问题只有回 答 “是” OR "否" 、“对” OR “不对”、“行” OR “不行”。

2）问卷调查：如果需要等到大量用户关于某些具体问题的回答时，是非常有用的。但是它局限了用户的想法。如果可以让用户可以自由的回答就很难归纳多个回答。不可以做为捕捞故事的主要方式。

3）观察：在观察别人使用自己做的软件时，自己会获得很多提高用户体验或生产力的想法，不幸的是这种机会少之甚少。所以造成不要错过任何可以看用户使用你软件的机会。

4）故事编写工作坊：是开发人员、用户、产品客户和其它对编写故事有帮助的人共同参加的会议。在工作期间，参与人员尽可能多的 去写故事（不分优劣好坏），不排优先级，最后让客户去排优先级。故事编写工作坊是快速故事最有效的方法，至少在开始每个计划发布前举办。这个虽然好，也没 有必要在整个项目中举办太多的故事编写工作坊。故事编写工作坊中的讨论就在较高层面上，我们的目的在短时间内写出更多的故事，而不是设计怎么做，怎么来实 现。

5）演示：与观察相同，在为别人演示自己所做的软件时，可能会感受对其中一些用的不爽的地方，观看者也可以在第一时间提出对这个功能更好的建议。第一时间获得用户的反馈

五、小结：

      1） 能够引出及捕捉需求这一想法是错误的它有两个有问题的假设：用户知道所有的需求，需求一旦被捕捉，就锁定，不再改变。

      2）拖网捕鱼的比喻是有用的：它说明了需求有不同的大小，需求会随着时间的推移变化，需要一些技巧来发现需求。

      3）即使敏捷流程支持需求的后期涌现，依然需要对预期的发布进行展望并开始写下容易发现的故事。

      4）我们可以通过用户访谈、观察用户、问卷调查、为用户演示和举办故事编写工作坊来发现用户故事

      5）使用多种方法比过度使用一种方法更能获得好的效果。

      6）通过开放式、与背景无关的提问更容易获得有用的答案，例如：“告诉我你想要怎么搜索工作？” 就胜于 “你要通过职位来搜索工作吗？”。

六、开发人员职责：

     1）负责理解并使用多种技巧来捕捞用户故事。

     2）负责知道怎么使用开放式和背景无关的提问。

七、客户职责：

     1）负责理解并使用多种技巧来捕捞用户故事。

     2）负责尽早写更多的用户故事。

     3）作为软件用户的主要代表，负责和他们多沟通。

     4）了解怎么使用开放式和背景无关的提问。

     5）如果需要关于编写故事的低碳哥，负责安排并举办一次或多次故事编写工作坊。

     6）负责确保在捕捞故事过程中考虑所有用户的角色。