Questions tagged «user-story»

用户故事是敏捷软件开发的核心概念之一。

4
在敏捷开发中如何处理用户界面设计和相应的功能支持？
在敏捷开发过程中，通常主要侧重于用户故事，但是有时一个需求可能跨越多个用户故事。 例如，客户端可以为论坛中的所有用户请求搜索页面，并且在每个用户上可以执行多种操作，例如禁止用户，删除用户，重置密码等。 我们可以将此功能至少分为4个用户故事： 搜索用户 禁止用户 删除用户 重设密码 用户界面设计者将如何实现这样的用户界面？他/她是否应该处理第一个用户故事，然后开始为UI增加更多功能？但是，我认为最终的UI会搞砸了！ 如果他决定使用整个功能（搜索+动作），那么如果这些动作的优先级较低，并且将在搜索功能完成后进行多次迭代，该怎么办？
2
从头开始创建SCRUM，没有建立基本框架？
我们是一个由5人组成的小组，即将开始一个新项目。这是我们将全力以赴地进行的第一个项目。 我们正在为如何建立项目基础（框架等）而苦苦挣扎。这些任务不是用户直接受益的任务，因此我们很难弄清楚如何为它编写用户故事。 因此，总的来说，当您从头开始没有框架且没有基础库的项目时，如何使用scrum？
6
如何使用用户故事定义复杂的业务规则？
用户故事的快速而肮脏的定义： "As a <role>, I want <goal/desire> so that <benefit>" 在这个公认的定义中，几乎没有空间定义业务规则，约束或用户输入。 一个简单的例子只是为了说明： "As a <librarian>, I want to <register new books> so that <students can find their availability online>" 在这个愚蠢的例子中，注册书时在哪里定义所需的字段？应该写在任何地方吗？还是应由产品负责人以口口相传通过所需的业务规则？
10
用户故事水平太高且太概念化，管理层希望开发人员填补空白
我受雇于一家非常有才华的公司，真正的目的是从事XP。沟通很好，管理人员也可以进行富有建设性的讨论，但是由于时间紧迫，某些事情被认为是RUP，无法讨论。 目前，我对实施故事时需要进行的大量更改感到有些困惑。我相信其中许多发现（当然，这需要花费时间和精力）是故事编写者（客户，最终用户和产品所有者）的责任，而不是开发人员的责任。简而言之，用户故事太概念化，只是传达了基本意图，但缺乏足够的细节（特别是前提条件和后置条件，与其他故事的相关性，依赖关系等）。由于XP开发人员同时是设计师和分析师，因此开发人员可以自行决定填补空白。问题在于许多空白是在发现错误的假设进入评估时间和代码之后才发现的，因为注意到比最初预期的情况更加复杂。即使到那时，找到合适的东西来填补也要花费时间，在不同程度上，这被认为是与初始估计的偏差。 我正在寻找一种建设性的方式来将这些含义传达给管理层，而这种方式不会使我成为试图不必要地使事情变得复杂的人。我是新手，但我尚未建立起很高的信誉。 我们欢迎您的见识。 密切相关并且以某种方式给出了答案：开发人员可以期望多少有关用户故事的细节？
5
按故事编写需求规范是个好主意吗？
目前，我们在当前项目中使用的是敏捷方法，并且我们有很多类似的故事： 作为助理，我想向客户退款，以便他们可以在要求时获得一些退款 作为客户，我想付款以购买商品。 到目前为止，我们的工作方式是在每个冲刺中挑选最重要的故事，并将其详细阐述为许多正式的需求规格（我们将一些在相同规格中相似的故事归为一组）。根据故事的不同，它可能只是屏幕上的按钮或整个工作流程。 现在的问题是，因为故事太多，对于系统中与故事相关的任何部分，现在还不清楚。 它可以在开发人员时发挥作用，开发人员的每一次冲刺都只是获得一个规范，概述他们需要做的事情和需要进行的更改。但是就维护此故事列表和进行测试而言，它开始变得很难跟踪错误，并且通常只是维护规范，因为屏幕上的一项功能可能已经记录在许多不同的地方按故事拆分。 根据故事写规范是个好主意吗？我们写故事的方式有误吗？
3
用户故事定义中的“ so that”子句的目的是什么？
用户故事可以用如下语句来定义： As a <type of user> I want <some goal> so that <some reason> 只是Google的“用户故事公式”和第一个链接都提出了此公式。 我的问题是，该条款的目的是什么？经理那里吗？是否在那里使项目经理和利益相关者可以更好地了解项目的优先级？为什么在那儿？ 注意：我已经处理过as a <type of user> I want <some goal>公式，并且效果很好。通过采用这种更简短的格式，我在工作中没有发现任何问题。
10 user-story 
4
后端开发者被用户故事所压倒
我计划将后端开发垂直切入用户故事。但是我们团队的一个后端家伙开始抱怨这使他们的工作变得无形。 我的答案是 在冲刺计划和审查会议上，我们在利益相关者面前讨论了后端任务，以便使其可见，并且 在项目过程中保持高质量将导致启动速度比其他团队慢，但是在项目过程中我们的速度将保持稳定。利益相关者非常清楚地看到速度。 他仍然坚持有这样的故事：“作为开发人员，我需要一个域层，以便我可以封装业务逻辑。” 在污染团队之前，我该如何解决？ 问题的根源在于，我们的管理人员系统地将后端工作视为无形的工作，并召集了受支持的开发人员矿工或其他贬义术语。
10 agile  scrum  team  user-story 
3
在敏捷中，如何使用严格的管理框架（例如TFS在线）计划和分配项目开始时的基本基础架构任务？
在这里，我正在确定和估计一个相对较小的新软件开发项目。我已经遍历了客户建议的用户案例，并针对每个案例放置了任务，并提供了估算和一些简短的注释，说明如何完成任务。有验收标准。所有人都应该对世界有益。 在查看我计划的工作时，我意识到缺少一些东西。只需设置一些我们可以固定功能的东西，这是最初的支出。属于所有用户故事的事物，而不是一个特定的用户故事。 例如，此应用程序的一部分是解析XML的服务。从用户的角度来看，有一些特定的故事，根据XML的内容，需要做不同的事情。实际上，编写XML解析器（查找文件的位，读取文件并提取相关数据，然后再决定如何处理内容）是所有这些故事的一部分。就像使用安装程序等将其包装在Windows服务中一样。这是以开发人员为中心的任务，与用户没有直接关系。 该特定应用程序的另一个相关示例是获取并重写一段不良的旧代码，这对此应用程序的功能很有用。同样，这对用户没有立即的结果，但这是必要的工作。在针对用户故事的项目计划中，如何计划和执行这项工作？ 我已经看到人们通过写用户故事“作为开发人员，我想...”来解决这个问题，但是正如其他地方所讨论的，这不是用户故事。是开发人员。 我正在为此寻求一个具体的答案，以帮助我（和其他人）使用严格的管理框架（例如TFS在线）来计划项目。这些往往不具有编写“利益相关者故事”或其他模糊的元解决方案的功能，这些解决方案在Scrum团队如何在计划会议中解决基础架构任务的答案中提到。
3
如何为多个项目中解决的问题建立故事准备模型
在我们公司中，几个团队将同时从事多个项目的不同组成部分。例如，一个团队可能为某些项目制作特定种类的软件（或硬件），而另一个团队可能制作另一种特定种类的软件。我们使用Jira项目来托管特定项目的问题，并使用Jira董事会来为不同团队的sprint进行托管。 我们面临着避免在项目之间重复代码的问题，并且已经开发了一套在这些项目中使用的核心库。在进行项目工作时，一些开发人员会意识到他们编写的一段代码更加有趣，应该将其提取到一个核心库中，或者他们正在使用的某些核心代码存在错误，需要更多的参数化，或者新功能...您命名。 因此，他们创建了一个核心库问题，该问题进入了核心项目的待办事项列表。在核心图书馆会议上（一周一次）对所有这些问题进行审查，确定优先级和估算，并将在以后的某些冲刺中根据其优先级（与项目相关的问题）进行处理。 通过对问题进行排序来确定优先级，然后sorted在已排序的问题上贴上标签（以便我们可以搜索未排序的问题）。然后，我们将每个核心组件手动发行一个问题到待办事项的顶部，以便首先解决它们。当某些团队将这样的问题放入他们的冲刺中时，他们不得不手动将另一个项目拖到待办事项列表的顶部。 这很容易出错。基本上，我们拥有的是“未解决”和“进行中”之间的其他问题状态“已排序”和“估计”。通过sorted标签及其在电路板上的位置来反映这一点非常麻烦且容易出错。（例如，如果有人在某个冲刺中上下移动一个问题，这将反映在核心董事会上，默默地扰乱团队在几周前的广泛讨论中可能已经决定的问题的顺序。） 那么有什么更好的方法来实现呢？
4
垂直用户故事的缺点
在敏捷方法是组织工作纳入垂直用户故事，并提供有重点，但功能完备的片从应用的终端到终端。因为这是构建软件的新方法，所以我读了很多关于为什么它比水平故事更好的文献，但是我对这种方法的弊端知之甚少。 我已经喝了敏捷的冷却剂，我也同意垂直切片蛋糕比水平切片有很多优势。以下是我可以提出的一些缺点： 开发人员起初可能会较慢地实现功能，因为他/她必须了解开发故事所需的所有技术（UI +服务层+数据访问+网络等）。 总体架构设计（成为应用程序的骨干）并不能完全满足这一要求（但是有些人可能会认为开发/更改总体架构是用户故事的一部分） 垂直切片用户故事还有哪些缺点？ 注意：我现在要问这个问题的原因是因为我将试图说服团队开始以“垂直方式”撰写故事，并且我希望能够提前提出可能的取舍，以便他们获胜。当他们面对弊端时，不要认为这种方法是失败的。
3
本机移动应用程序开发-如何构建用户故事？
我将开始一个项目，该项目将涉及开发原型本机移动应用程序（最初为iOS和Android）以及基于Web的管理界面和与这些应用程序进行通信的API。我们有一个已经起草的故事列表，但是其中许多格式如下： As a mobile user I want to be able to view a login screen so that I can sign into the app 如果这是针对单个平台的，那么我不会出现问题。但是，由于我们的目标是多个平台，所以我不确定现在是否应该复制这些平台，例如“作为Android用户”或类似的名称。这似乎是重复的，但需要针对每个平台分别完成这项工作。 这是我们第一个本地化的移动项目-以前是Phonegap，我们将所有故事都归类为“作为移动用户”。由于本质上这是一个使用本地代码包装的基于Web的应用程序，因此这并不会带来太大的问题，但是我意识到纯本地应用程序是另一回事！
4
如果我们采用用户故事，我如何说服我的团队不需要需求规范？
我们计划采用用户故事，以轻量级方式而不是繁重的SRS（软件需求规范）来捕获利益相关者的“意图”。但是，似乎他们虽然了解故事的价值，但仍然希望将故事“转换”为具有所有属性，优先级，输入，输出，来源，目的地等的SRS式语言。 用户故事从一开始就“消除”了对像正式SRS这样的工件的需求，那么拥有SRS的意义何在？如果我们采用用户案例来捕获系统的功能需求，我应该如何说服我的团队（顺便说一句，他们都是非常合格的CS人才-在教育和实践上都如此），SRS将被“消除”。（也可以捕获NFR等，但这不是问题的意图）。 所以这是我的“工作流程”论点：将初始需求捕获为用户故事，然后将其详细阐述为用例（需要以较低级别进行记录，即描述与UI原型/模型的交互，并且是可交付的文章）部署）。因此，从用户故事转到用例，而不是从用户故事转到SRS到用例。 你们目前如何在工作场所中捕获用户故事（如果有的话），以及您如何建议我为存在用户故事的情况下缺少SRS辩护？
6
什么时候停止编写用户故事并开始编码？
在发现第一个冲刺的故事时，您如何知道何时停止写作并向前发展？ 我问了几个我认识的人，基本上我得到的答复是，它取决于项目所处的环境以及整个项目的时间安排。 有什么标准的方法可以知道何时停止编写用户故事，如果是的话，其基础是什么？它如何应用于未来的冲刺？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.