目前，我在为另一个远程开发人员输入用户故事时遇到麻烦。我需要为他创建用于不同功能的综合文档/技术规格。
以我自己的观点，我想创建一个用户案例：“作为一名开发人员，我需要向另一名开发人员提供一个包含xxx技术规范的合并文档。”看着这个，https://www.industriallogic.com/blog/as-a-developer-is-not-a-user-story/那是不对的。
我们希望所有任务都在Agile JIRA中，就好像我们只是将其存储在头脑中一样，我们可能会忘记它。我是从用户角度看的，他们将不需要此技术文档，因此我将无法“以用户身份”使用用户。
这是我目前的想法：
答案 0 :(得分：1)
用户故事描述了提供最终用户价值的功能。您所描述的是有助于传递用户故事的技术任务。
我建议以下其中之一：
答案 1 :(得分：0)
用户故事是从用户的角度编写的，在这种情况下，如果我们要为开发人员和测试人员创建故事，则基本上是将瀑布分成更小的故事供个人使用。 Scrum团队的核心价值之一就是跨职能，如果您想获得真正的敏捷体验，请不要根据角色来打破用户的故事，因为这会给完成个人一个感觉。故事。
在您的案例结构中，您的用户故事基于提供给用户的功能，并且您可以在JIRA中具有子任务，以使开发人员和测试人员可以定义完成任务所需的工作给定的故事。另外，为您的BA或产品所有者创建子任务，以定义与用户故事相关的功能规格，以便开发人员明确说明需要做什么。假设您正在与远程开发人员一起尝试研究敏捷的现场离岸模型，则可以参考此站点（ http://www.agilebuddha.com/agile/distributed-agile10-good-practices-of-successful-teams/ ）了解分布式团队的结构。
示例故事：作为一名会计，我想在我的应用程序仪表板上看到不同的投资组合帐户以进行结算。
子任务 •开发UI组件以将投资组合添加到仪表板。 •进行UI设计并制作原型。 •为投资组合创建数据库表–与DBA一起使用。 •从UI测试和验证帐户检索。
从以上示例中，我并没有定义将哪个任务交给谁，而是由团队来定义并选择他们的工作来完成故事。最后，JIRA中的子任务可以添加为给定用户故事的子任务。
答案 2 :(得分：0)
我建议不要专注于修正用户故事的特定形式。您引用的公式如此常见，因为它可以证明：
如果与您一起工作的人是真正的开发人员，而不是使用多个AC发明复杂的用户故事，请采用敏捷方法并让他找到解决方案...
只需写下您所需的内容！
我建议：“作为一个新手程序员，我需要了解XXX项目中正在发生的事情，并且我认为我需要一个可以帮助我入门的文档。”
以上用户故事完全正确。有价值。