开发人员之间应该共享用户故事吗？[关闭]

我通常会看到具有后端和前端开发功能的故事。例如，考虑一个带有几个表和一些动态控件的大对话框。我们将制作几个故事（也许每个表一个，而动态控制系统一个）。

然后，开发团队将在后端拆分一个人，在前端拆分另一个人。这使后端人员可以轻松担心SQL层的结构，而前端人员则可以专注于布局之类的工作。在后端和前端之间的初始接口达成协议后，两个开发人员可以集中精力在sprint结束时完成自己的任务。

然后是混乱。谁“拥有”哪个故事？“进行中”是什么意思？我们应该为后端和前端分别制作两个故事吗？如果是这样，这是否会打破基于功能的用户故事的观念？我们的系统具有“子任务”的概念，可以缓解其中的一些问题。但是子任务增加了额外的复杂性。有没有更好的办法？这是使用Scrum的“坏”方式吗？

过去几年中，我在一些地方一直在使用某种形式的敏捷。我尚未接受官方培训，因此请原谅任何错误的术语或意识形态。我只是想学习实用的方法来改善我们的流程。

之所以称为“故事”，是因为它从客户的角度代表了完整的故事。没有前端或后端，就没有客户可以执行的用例路径。

就您而言，我认为前端和后端都应该是一个故事。将其划分为任务。开发人员拥有自己的不同任务。这些任务可以按阶段进行单独跟踪-进行中，完成编码，完成模块测试等。

确保在同一故事中包含QA分配的任务-未经验证，故事是无用的。质量检查人员将测试客户将看到的端到端集成故事。只有这样，整个故事才能标记为“完成”。在理想的敏捷环境中，真实的客户或客户代理还可以在正在运行的应用程序中试用该故事，并在满足约定要求的情况下将该故事标记为“已接受”。

如果您想要更快的反馈循环，请尝试将用例分解为较小的端到端功能。例如，代替“客户可以使用购物车购买东西”这样的用例，将其划分为“客户可以将产品添加到购物车”，依此类推...然后完成每个较小的用例如上所述端到端。

编辑：我想用一些资源来备份以上几点。良好的用户故事的特征用缩写词“ INVEST ” 简明地表示。它由Bill Wake创建，并由Scrum运动推广。特别注意故事中的项目是独立和垂直的。

这里和这里有更多信息。

谁“拥有”哪个故事？

谁抓住这个故事。他们从组织的角度看关键是一个人负责这项工作。一旦你得到两个人，就太容易了。

我们应该为后端和前端分别制作两个故事吗？如果是这样，这是否会打破基于功能的用户故事的观念？

这取决于。我已经看到两种方法都可以工作。如果故事足够大，可以让两个开发人员全职工作，那么也许应该分开讨论。如果两个开发人员是两个不同团队的一部分，那么也许应该分开。如果两个开发人员将在不同的sprint期间进行处理，则应该将其拆分。

这是使用Scrum的“坏”方式吗？

要记住的关键是流程可以为您服务，反之亦然。用户故事是技术人员和非技术人员促进交流的一种方式。他们说出自己想要的东西，每个人都进行谈判，然后您就故事的进展提供反馈。

只要该过程对您有用，就不会那么糟。

在我们已经实现Scrum模型的地方，完全可以期望多个开发人员可以参与一个用户故事。可能需要进行数据层，集成，前端CSS，基础结构等工作。团队可以将各个子任务组合在一起，以完成故事。

话虽这么说，一个人拥有这个故事，并负责更新故事的进展，并确保每个人都完成自己的作品，并确保它正在共同努力。这是我们的人，他说一个故事“完成”。

就像其他人建议的那样，我的团队还将用户故事分为任务。如果要通过软件（例如JIRA或Rally）管理用户故事，通常这很容易做到。然后，很容易说出故事的哪些部分正在发展。

但是任务的另一种选择是在每个人完成自己的工作时重新分配所有权。故事就这样传开了-也许开发人员1从后端工作开始，然后传给开发人员2做UI。然后将其传递给您的质量检查测试人员进行验证。在您在墙上使用实际卡或软件无法跟踪任务的环境中，此方法应能很好地工作。

但是无论如何，我建议不要在团队同意完成故事（包括测试）之前将故事称为“完成”。这样，每个人都有机会提供自己的意见。而且，如果将其与关于集体代码所有权和代码审查的想法结合在一起，那么每个故事实际上都是团队真正“拥有”的。一路上可能会将其“分配”给其他人，但是如果有人不在（病/休假/太多会议？/其他），工作仍然可以完成。

我的团队经常在上午站立/ SCRUM会议中接受用户故事。这样，每个人都可以轻松地确认或质疑它是否真的“完成”。其他时候，我们只是让质量检查工程师来做-如果她对它的测试和工作感到满意，并且所有任务都已完成，那么我们就称其为完成。

今天我在哪里，我们称这个更大的项目为“史诗般的”。史诗由多个故事组成，并且可以跨越多个冲刺/迭代。对于我们来说，故事总是提供给单个开发人员，并且应该适合单个冲刺。然后，将单个故事细分为任务。每个任务均由该故事的同一位开发人员完成。这些任务旨在使您了解在冲刺/迭代过程中故事的进度。随着每个故事的完成，每个开发人员都会在史诗中展示进度。

史诗般的目的是要有一个更大的目标，不一定适合单个sprint / iteration。随着时间的流逝，所有故事都完成了，史诗也完成了。史诗放到发行版中。

然后是混乱。谁“拥有”哪个故事？“进行中”是什么意思？

我们每两周进行一次代码演示，其中必须向利益相关者展示并批准该冲刺/迭代的故事。在这种情况下，故事的“完成”意味着我可以向您展示它的作用。开发人员拥有他们的故事并负责显示它（这部分过分简化，但对于此答案而言足够好；我们通过一个人来协调演示）。“完成”表示可以成功演示。“进行中”表示我的任务尚未完成，故事还不完整。成功完成史诗的所有故事后，史诗即告完成。

现在，这是完美的案例进展。我们有失败的故事和演示，用户想要其他东西，等等。以上是目标，并且在大多数情况下有效。