敏捷开发挑战

Question

对于Scrum /用户故事/敏捷开发，如何处理作为用户故事一部分的调度不同步的任务？

我们是一家小游戏公司，与一些从事图形和音频工作的远程顾问合作。通常情况下，图形工作应该至少提前一周(有时是2周)，以便为集成做好准备。但是，既然SCRUM应该专注于用户故事，那么我应该如何在迭代中拆分这些故事，使它们仍然遵循用户故事模型呢？理想情况下，用户故事应该由所有团队成员在同一个迭代中完成，我觉得以任何方式分割它们都违反了用户故事驱动开发的核心原则。

另外，一个前端开发人员可以以后端开发人员的2X速度工作。然而，这也使调度不同步，因为他要么一直领先于他们，要么我们让他做一些与这个迭代无关的任务，只是为了保持忙碌。无论哪种方式，这都是相同的问题，分裂用户故事任务。

Answer 1

这是团队交叉功能的问题。基本Scrum期望每个团队成员都能做任何事情--在某些环境中(比如游戏行业)，情况并非如此。敏捷成功在UI设计器示例中描述了这一点。正如在其他答案中所描述的，当UI设计人员提前进行一次迭代来讨论和为开发人员准备设计时，没有什么错。你可以用同样的方法来处理你的情况。

但是，如果您对您的每个专业角色都这样做，您将失去Scrum可见性的要点。如果跨功能在您的环境中不起作用，那么您应该检查另一种敏捷方法--看板应该在您的环境中工作。如果您想了解更多关于看板的知识，我强烈推荐这本书。

还有关于在游戏行业中实现Scrum的特殊书，但我还没有读过。

Answer 2

挑战就是这个。

如何避免教条主义和不思考。

敏捷需要灵活性。不是教条。

然而，既然SCRUM应该专注于用户故事，那么我应该如何分割这些故事呢？

放下"SCRUM应该是“的思维定势。(Scrum是一个词，查一查，而不是缩略语。这是一场橄榄球比赛，每个人都朝着同一个方向前进。)

理想情况下，用户故事应该由所有团队成员在相同的迭代中完成。

不是的。在任何敏捷描述中都没有“用户故事应该存在”。你完成了一些可以释放的东西。这并不意味着每件事都是一次完成，然后奇迹般地到达终点线。Scrum意味着在sprint结束时，您可以发布一些内容。也许你还有更多。也许你已经准备好了一份杂乱无章的事情清单，并且很早就做好了。一切都没问题。真的。

无论哪种方式，这都是相同的问题，分裂用户故事任务。

放松点。不要再关注Scrum“应该是”的东西了。

理智地把事情拆散。想想看。你们自己谈谈。想出一些合乎逻辑的方法。

不要教条主义。不要拘泥于死记硬背的方法。停止播放。想。说吧。决定吧。

Answer 3

将事情分解成小故事并在迭代中进行的目的是更快地获得关于这些故事的反馈，并限制正在进行的工作。

在我参与过的一些Scrum团队中，分析人员一直在研究下一次迭代的需求，而开发团队则完成了当前的迭代。你的情况似乎很相似。我会做任何看上去最明智的事情，让你在工作中最危险的方面得到最快的反馈。

您可能会对看板的一些原则感兴趣，在这些原则中，我们使用"cadence“而不是迭代，因为这可能有助于您进行协调。看板还专注于减少反馈时间和限制WIP，因此对于一个已经超越Scrum的团队来说，这有时是一个很好的下一步。Kanbandev列表在雅虎，我推荐大卫·安德森的书。