开发软件可以通过编写用户故事来确立开发的目标和方向。而在编写故事前首先要对所有用户进行分类，根据角色的不同属性进行分类。步骤为：1、通过头脑风暴，列出初始的用户角色集合；（要坚持‘已确认的角色代表的是单一用户’的原则）2、整理最初的角色集合；（确认角色之间的关系；用户角色定义的是人而不是外部系统）3、整合角色；（对于完全重叠的用户进行重新定义，舍弃对系统成功作用不大的角色）4、提炼角色（根据角色特征来建立角色的模型）。
编写故事之前需要搜集故事，通过与用户沟通来发现故事。可以像用渔网捕鱼一样获取故事。不同大小的网用来捕获不同大小的需求：可以先用“大网”来捕获用户最基本的需求，明确软件的基本方向，接着可以用“小网”来捕获用户对每个功能具体实现方面的需求。
对于软件开发过程来说传统的规范过程和敏捷过程的区别之一在于获取需求的方式。传统规范过程在项目早期正确地获取并写出所有需求；而敏捷过程则随着软件开发的过程每个故事都会根据需求进行变化或是保持不变，也会有新的故事加入开发流程。所以对于敏捷过程来说因为故事会随着项目的进展而演进，所以需要一些反复使用的方法来搜集故事（可以采用用户访谈、问卷调查、观察、故事编写工作坊等方法进行搜集）。
捕获需求尤为重要，了解用户如何使用软件也很重要，这个关键在于实际用户，但是由于实际开发流程不可能给开发团队与很多实际用户一起工作的机会，所以需要一个用户代理。用户代理可能不是用户，但是在项目中代表用户。选择合适的用户代理对于项目的成功至关重要，要考虑用户代理的背景和动机。使用以前的用户来担任用户代理就是非常好的选择，因为他/她使用过软件，对于软件的操作肯定有自己的简介，对软件一些不利于使用的操作肯定也深有了解，但是需要考虑他/她的目标和动机是否与实际用户完全一致。业务或系统分析师也是很好的用户代理，因为他们既懂技术，又熟悉软件的相关领域知识。能平衡好这些背景且努力跟实际用户沟通的分析师，通常会是非常优秀的用户代理。
在实际开发过程中，因为实际用户总是会优于用户代理，所以如果可能就要邀请实际用户加入客户团队；如果条件不够，就需要一个或多个用户代理与客户团队建立成一个优势互补的团队。
所以在敏捷开发过程中要不断捕获用户需求，而用户故事则根据实际用户需求在每个迭代过程进行演进；还需要一个有实际用户或用户代理参与的客户团队，方便开发人员时刻了解用户对于软件操作的需求，以及他们的使用习惯。这两点对于软件的成功起着非常重要的作用。
原文：http://www.cnblogs.com/muamu/p/5929538.html