我们在上一期了解了基本的需求背景后，可以开始我们下一步的具体需求整理工作了，通常在敏捷开发的实践中，我们将会以用户故事的形式来呈现需求，接下来我们来具体的看看用户故事是怎么形成的。
图源：网络
问卷是一种非常有效的需求收集方式，但要注意使用问卷的目的和阶段；广泛性的问卷调查通常会消耗大量的用户资源，通常我们在亟需定量验证的阶段且没有足够数据支撑时会采取问卷的方法，若你有一个庞大的用户群，那么问卷时手机有关故事优先级的好方法。在需要得到关于大量用户的具体回答时，问卷是非常有用的；但要注意问卷不适合作为捕获新故事的方法，静态的问卷不易于根据后续的问题。
图源：千图网
实地观察用户的日常使用软件（或者目标替代工作流）的过程，可以让你快速直接的从用户那里获得反馈，从而更早、更频繁的发布软件；提前做好利益方的沟通，安排好实地观察的机会，一般只有在内部或强大PO支持的项目下有实地观察的机会。
在有了前述需求收集过程后，通常我们会得到一个较为明确清晰记载了不同用户类型特征、业务痛点的表格（在每一次访谈、观测、问卷后逐步更新），通过不断的发散&收敛，按我们的用户访谈——用户画像——痛点——痛点归因——期望抽象——解决方案——产品形态这一步骤，最终形成我们整的需求全景，同时还应该注意以下内容：
开发人员、用户、产品客户和其他编写对故事有帮助的人共同参与的回忆。在工作坊期间，参与人员尽可能的编写用户故事 ；
正确的时机组织编写工作坊可以非常快速的获得大量的故事；
-
需求一旦被捕获就不要改变，可以有新的需求，可以有不同的优先级； -
技术支持需求在后期会不断涌现，依然需要对于依据发布过程进行展望并开始写容易发现的故事，在后期总结成技术故事卡； -
不断通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来返现用户故事。
将前期的收集信息规范化处理，并呈现给团队；
负责整个工作坊的Drive，调动所有成员积极参与；
准备好充足的物料，以便内容展示和全员的故事编写；
时刻注意故事书写规范、提问方式方法，保持工作坊的效率；
负责将所有收集到的用户故事进行呈现，并进行分类、排序，将成果展示给所有人，对于有疑问的内容当场确定清楚。
图源：网络
-
开发人员职责——负责理解并使用多种技巧来捕获用户故事；负责知道怎么样使用开放式和背景无关的提问； -
客户职责——负责理解并使用多种技巧来捕获故事；负责尽早写更多的用户故事；作为软件用户的主要代表、负责和开发人员多沟通；负责安排并且举办一次或者多次故事编写工作坊；负责捕捞用户故事过程中考虑所有的用户角色。
图源：千图网
