其他用户已登录 如果继续 则会将他们断开连接_做需求分析，使用用户故事工具的禁忌，你知多少？...

此文来自于：翻译 IIBA 官网 博客文章

用户故事是一个与软件开发的敏捷方式相关的术语。 当我们想到Scrum时，通常会将其以 User Story 及其他方式联系在一块。

什么是用户故事？

当然，它是一个非常流行并广泛应用的技术。常常被用来做个性化需求。它用简短而明确的方式描述了指定类型的用户想要做什么及为什么这么做。总而言之，它进化了被交付的价值。

有时候人们习惯从狭义上理解用户故事，仅作为核心部分，即“价值声明”。这是描述实现特定故事时所传递的价值的声明。让我们首先解决这一部分。

价值声明

通常一个“价值声明”是基于一个范本，可能最受欢迎的是：

“As a

“As a

这给了我们一个三个主要元素的结构：

行为《谁？》—表明了一个特定的用户类型(设计行为与这个系统互动，例如，管理员、顾客、供应商等等)。通常识别了各种各样的用户群体，他们使用这个系统的原因不同，权限级别也不同。

行为---描述了在这个系统中，设计好的行为主要目的是什么，已执行的活动的描述

价值---具体阐述 已实现背后描述交付价值的原因。不幸运的是，这是非常容易犯错的一个元素，因为它经常不会被适当地展示或者有时候直接跳过。在我看来，这会造成一个非常严重的问题：要交付的业务价值已经消失，而它却成为我们关注的中心。

用户故事的其他元素

剩下的元素是：

标题-可选择的。它通常是一个用户故事目标一句话简短的陈述

对话---用户故事应仅作为与项目团队和其他利益相关者进行进一步讨论的简介，是进一步考虑和相关建模的基础。 此元素不应被视为可见的书面文字片段。 而是应强调每个故事都需要更广泛的对话。

验收标准———他们帮助细化用户故事工具及确认它的界限。这儿有很多需要遵守的条件以便它确认需求价值是否需要被交付？

用户故事工具适合每个情景？

行进一步的讨论和考虑，以寻求适当的解决方案。 听起来不错，实际上如此好，以至于这种技术经常被滥用。

我听说过一个观点，那就是：敏捷不会辨认出这个文档，或者它只能辨认出其仅仅允许的格式。当然了，这个观点是错误的。

在过去我曾经作为业务分析师工作过的一个团队中，我遇到以下情况：当我们遇到由我的团队开发的系统要与另一个团队开发的系统集成时，我问另一个业务部门。 分析师分享了这些文档，以便我可以了解他们一部门，比如说其功能，可用的界面等。因而我收到了与他们的部分开发相关的153个用户故事的列表…当然，这些用户故事是这几年开发的， 它们是在以后的修改中创建的，并且在用户案例中也进行了描述。 因此，基于可用列表为系统创建一致的愿景似乎是一项极其艰巨的任务。

这是一个非常典型的例子，尽管用户故事通常非常有用，但不应将其用于所有目的。

在哪里使用用户故事？

总之：无论你什么时候需要存储以短期目标为基础的需求，及有一个要强调其交付价值的需求时。除此以外，为了找到共同的理解及继续从事创建一个解决方案模型的工作，用户故事工具被用来做进一步讨论的介绍。

除此之外，由于其特殊的性质，可以将工作划分为一些精炼的功能或质量要求，因此，用户故事可以用于：

优先讨论

工作评估

产品研发和其版本计划

 画高级需求地图

设计验收测试

追踪和报告工作进程

什么地方不适合使用用户故事工具？

首先，用户故事不能被用作一个长期的需求储存工具。他们被证明不是用于开发和维护产品的文档的良好基础。大部分原因是没有其他额外的文档，仅仅依靠用户故事工具，如果要重建当下的系统声明就变得非常困难。

重要的是要记住：通常来说仅仅凭用户故事自己，没有任何背景不能让研发团队有效率地工作。他们需要更大的范围，以提升已实施变更、目标和对系统各个组件影响的理解水平。它可能提供我们使用其他的技术和不同类型的文档。

我的建议

· 按照其名称使用用户故事：记录短期使用的要求

· 将它们视为进一步讨论的介绍，而不是固定且不可协商的要求

· 不要试图使所有内容都适合用户故事。 使用其他形式的文档来支持它，该文档更适合您的需求，例如图表，界面模型，用例描述等。

· 对于长期维护需求，请使用其他合适的技术。

· 始终记住要交付的价值的正确描述(请参阅上述用户故事结构的最后一个元素：价值声明)

关于作者：

Radek在担任业务分析师和产品负责人方有丰富的专业经验。 他是一名专业人员，曾与各种IT团队合作，为不同规模的组织(从小型初创企业到国际公司)做过项目。

Radek是国际商业分析协会波兰分会的会员。 他持有IIBA颁发的以下证书：CBAP(业务分析专家认证)，CCBA(业务分析能力证书，比CBAP证书含金量低一点)和IIBA-AAC(敏捷分析证书)。

Radek与多家公司和机构合作，担任商业分析培训师。

参考文献：

A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3.