中间件开发团队的用户故事和其他积压项目[关闭]

作者: IP地址
发布时间: 2024-04-01 09:39:11 (1月前)
转自：

3 条回复

0#
回复此人
一别而尽几念深i | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 这里有几个问题。我们应该解决的第一件事是你在你的场景中与工具作斗争。用户故事的重点是从最终用户的角度来看待开发需求。在大多数应用程序中，这意味着有一些功能需要前端工作，中间层工作和数据库工作，或者应用程序具有的任何其他组件。如果这意味着提供任何给定的用户故事需要多个团队，那只会告诉您构建团队的方式与您的价值流不一致。现在，您可以走这条路并重新调整您的团队，或者您可以跨团队处理用户故事，或者您可以决定此工具不是您想要使用的工具（Scrum实际上并不需要使用用户故事，尽管它需要跨职能团队）。无论你做什么，如果你正在与技术作斗争，你将无法获得用户故事带来的价值。你会感到沮丧。 因此，例外情况是：如果您的API本身就是一个产品。例如，Google的Firebase产品是您主要通过API进行交互的平台。现在您的最终用户是使用您的API的开发人员，使用用户故事没有问题： <BLOCKQUOTE> 作为一名实施开发人员，我希望能够更新用户帐户详细信息，以便我可以保持我的用户信息是最新的。 </BLOCKQUOTE> 在这些情况下，我建议在用户故事中使用实施产品的人作为“WHO”，而不是系统。系统不需要东西。 的 验收标准 </强> 例子真棒！它们还可能包含API用户可能想要使用该功能的内容。这可以促使您更有效地讨论您的团队创建的软件将如何使用。（请记住，用户故事技术的核心部分是，您必须与该用户的用户或代表进行所需功能的对话 - 与其他类型的需求文档不同，它旨在启动对话，而不是替换一个） 的 使用PO验证 </强> 像邮差这样的工具工作得很好。大多数PO，利益相关者和用户都习惯于快速查看XML。另一个很好的选择是创建裸机UI作为演示工具。这不仅可以让您轻松展示您的工作，还可以在其他人使用您的API时充当示例实现。 的 一种不同的工作方式 </强> 敏捷，XP，Scrum，看板等中的许多工具和技术代表了不同的工作方式。如果你试图将它们塞进旧的工作方式，你最终会感到沮丧。如果你要开始练习Scrum，TDD，用户故事，或者在敏捷或精益伞下的其他许多练习，你需要留出时间以他们想要的方式尝试它们并改变你的方法来匹配什么那些做法正在努力实现。在用户故事的情况下，目标是从用户的角度查看它。如果您不打算这样做，那么您现在最好不要采用用户故事。 </DIV>

编辑
1#
回复此人
甲基蓝 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 制定我们团队使用的用户故事的最佳做法之一是基于以下内容： <UL> <LI> 它始终从最终用户的角度制定。我们不区分前端，后端或设计任务。这是有原因的。只有工作软件才有价值，产品负责人可以接受。如果您想为不同的人或团队分割工作，您可以创建子任务或创建史诗。 </LI> <LI> 通过制定我们总是使用的用户故事的 以便 </强> 表示商业价值。很明显为什么故事是为任何开发人员实现的，这对分布式团队来说很重要。例如，故事可以表述为：作为银行客户经理，我想检索银行帐户列表，以便使用更新的信息填充报告。 </LI> </UL> 故事可以拆分为创建后端，API等。 至于验收标准。我建议将符合功能要求的业务标准纳入验收标准。例如，确保此功能支持跨浏览器。 当功能完成时，也可以安排产品负责人接受，以避免提供QA团队已有的反馈。另一个好处是在实现该功能之前验证原型和线框。像Balsamic这样很好的收费来创造那些。 希望它可以给出一些问题的答案！ </DIV>

编辑

登录后才能参与评论