用户故事与敏捷方法 - 第四章 搜集故事

    本章将告诉你如何和用户一起工作，如果通过与他们的沟通来发现故事。同时介绍各种方法的有点，怎样恰当的提出问题，从而获得真正的用户需求。

    引出和捕捉是不合用的：

            我们一直有一种错觉：“需求本来已经存在了，我们只要让客户给我们解释需求，然后我们把它们放在笼子里就可以了。”其实不然，很多需求并不容易得到。同样，用户并不知道所有的需求，所以不能单纯的靠引出（elicitation）。

            拖网（trawling）形容收集需求的过程。要像“拖网渔船捕捞鱼”那样收集需求。大小不同的网来捕捉不同大小的需求。第一遍我们使用大网眼来捕捉大需求，通过这些大需求，形成对软件的整体感觉。大需求也是史诗故事。然后在用小一点的网，捕捉中等需求。其次还有另一个含义，需求会像鱼一样，成长，游动，死亡。需求一样会遗漏，小需求变大需求，大需求变小需求，甚至消失。拖网捕鱼时，有时也会捕获到一堆垃圾残骸。最后，拖网捕鱼比喻了一个重要的现实：技能也是捕捉需求的一个要素。一个熟练的需求分析人员会知道哪里有需求，而不熟练的人员可能会捕捉到一堆垃圾。

    够用就行，不是吗？

            辨别传统开发模式与敏捷模式的方法之一，看他们收集需求的方式。传统开发模式希望在项目编码前清楚的描述客户素有需求，敏捷开发承认用户故事有一定时间维度。

            然而，虽然我们愿意承认无法在一个项目编码之前编写出所有的故事，但是我们还是应该在早期尽可能尝试编写我们可以编写的故事，即便许多故事还停留在十分笼统的阶段。使用故事的好处在于简洁，一个故事是一个恰当的占位符（placeholder）。我们可以逐步将他演化成为更小的，更有用的多个故事。因此对应用程序的大部分编写是十分容易的，其工作量少于其他方法搜索。

    方法：

            故事会随着项目的进展演进。所以们需要一个反复使用的方法来搜集。我需要使用足够轻量，不咄咄逼人，可以持续的方法收集故事。

            1.用户访谈。

            2.问卷调查。

            3.观察。

            4.故事编写工作坊。

            这些方法有很多传统业务分析师所使用的。

        

            1.用户访谈：

                    1.大多数客户不善于理解，有不善于表达他们真是需求。

                    2.尽量让客户表达。开放式问题与背景无关。

                    3.不要有封闭式问题，客户的回答不能是对或错，或A或B。比如问客户是否用户姓名搜索用户要比问客户用什么方式搜索用户差的多。

            2.问卷调查：

                    1.它不能作为捕捞故事的主要方法。

            3.观察：

                    1.太多商业产品开发采用的都是猜测用户需求。

                    2.如果有机会观察到用户使用软件的情况一定要珍惜。

                    3.客户描述需求可能很模糊，只有通过观察才能发现。

            4.故事编写工作坊：

                    1.所有项目有关人员参加的会议，参与者尽可能多的编写故事。我们的目标是在短时间内编写出大量的故事，而不是讨论界面和解决问题。

            开发人员职责：

                    1.负责理解并使用各种技巧捕捞用户故事。

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

            客户团队职责：

                    1.负责理解并使用各种技巧来捕捞用户需求。

                    2.负责尽早写出用户故事。

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

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

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

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