SCRUM - 敏捷开发 - 同时处理多个用户故事的一名开发人员 [关闭]

Question

刚刚有一个关于 敏捷开发 的简短问题，即每个开发人员在 sprint 中分配的用户故事的数量...

要点是：在 10 天的冲刺中，我有 2 个故事分配给我。这些故事非常非常相关，而第二个故事显然是从第一个故事中借鉴而来的。

在敏捷开发中，是否可以在一个分支中处理两个故事的主动性/接受标准，并将两个故事的逻辑推到同一分支中以进行拉取请求/代码审查。

在我们的 sprint 管理软件中，这 2 个用户故事确实有各自的故事编号。第一个故事本质上是渲染一个带有 2 个链接的组件，第二个故事是让这些链接要么转到特定的路线（条件 1），否则它们各自打开一个特定的模式（条件2）。

在我的代码审查期间，一位开发人员问我为什么这样做，并建议我应该等待第一个故事不仅代码审查批准，而且在开始处理第二个故事之前被 QA 接受，说我为 QA 增加了不必要的复杂性，并延迟了故事在当前 sprint 中被接受的机会。

我的论点是（除了代码审查所花费的持续且不必要的长时间），完成第一个故事，然后坐等它完成是没有意义的在开始开发第二个之前接受，特别是，因为它很简单。

另一方面，如果我开始开发第二个故事，要么会有不必要的重复代码（从第一个故事渲染必要的组件）来测试新逻辑，或者大量在branch-1、branch-2 和develop 之间来回切换；更不用说在每个分支上使用git rebase（我很失望，只是说）（git pull 对develop 的新更改，在branch-1 上运行git rebase develop ，然后在branch-2 上运行git rebase branch-1。看起来很复杂)

为了提高效率，并且由于第二个故事的次要标准，我在单个功能分支中完成了所有编码工作。

哇！这比我预期的要冗长得多。对不起……

TL;DR -- 开发人员可以在一个 sprint 期间在一个功能分支中同时处理多个单独的用户故事吗？只要它们之间的关系非常密切并且相互依赖..？

Answer 1

听起来好像用户故事一开始就被错误定义了：从用户的角度来看，在 UI 中设置一个不指向任何地方的链接有什么意义？如果您的故事 1 在没有故事 2 的情况下实施，这就是您最终会遇到的情况。 IE。您所说的用户故事实际上并不是用户故事，而是属于单个用户故事的两个任务。要解决这种情况，这应该反映在管理软件中。

但更一般地说，在 sprint 计划会议之后，不应该有关于谁负责什么任务的问题。

回答您的问题，一般来说，处理多个用户故事当然是可以的，但在团队内部，每个人都应该清楚在开始工作之前做什么，以及一般组织条件（QA用户故事，在你的情况下）应该被考虑在内。沟通是关键。如果您认为用户故事的结构应该不同，或者有些事情孤立起来没有意义，请在开始处理之前让其他人知道您的意见。 sprint 计划会议是进行此类讨论的最佳时间，但您的 scrum master 应该始终开放讨论。这种处理事情的方式应该可以避免让你的队友感到意外。