当开发团队也是支持团队时，Scrum 如何工作？ [关闭]答案

【问题标题】：How can Scrum work when the development team is the support team as well? [closed]当开发团队也是支持团队时，Scrum 如何工作？ [关闭]
【发布时间】：2016-05-13 09:57:40
【问题描述】：

当开发团队也是支持团队时，Scrum 会发生什么？如何使用 Jira 改进这一点？

我们不能有消防员，因为并非所有开发人员都能同时解决前端和后端问题。但是支持问题使团队速度难以获得。

【问题讨论】：

这听起来可能很苛刻，但首先减少问题是帮助稳定您的团队提供新功能的能力并减少持续的救火的好方法。
除了 Barnaby 在下面的出色回答之外，您可能希望考虑对您的团队有所帮助的一件事是看看您的团队如何相互交叉技能，直到您不再拥有单一技能点依赖于“这是一个后端问题”与“这是一个前端问题”。归根结底，您遇到了问题，团队应该能够使用他们共同拥有的技能来解决它。让团队推动他们如何以最有效的方式做到这一点；一种方法是花时间互相学习技能或积极合作解决问题。
我投票结束这个问题，因为它与编程无关。

标签： agile scrum

【解决方案1】：

Mike Cohn 在sprint planning for teams with a lot of interruptions 上写了一篇好文章。

他建议对被打扰的平均时间进行滚动估算。然后在您进行 sprint 计划时考虑到这一点。

例如，假设团队平均将 30% 的时间用于解决问题。当您进行规划时，您计划将 70% 的容量用于开发工作。

正如您在问题中提到的，指定一个人来处理问题修复是一种常见的方法。这是有益的，因为它允许团队的其他成员专注于新的开发工作而不会出现意外中断。在开发人员是专家的情况下，这更难实现。您可能需要考虑做一些交叉技能，以便开发人员可以处理更广泛的问题。他们可能无法像专家一样解决某些问题，但团队其他成员避免了中断，从而弥补了效率上的损失。

其他值得考虑的事情：

对错误进行分类，只立即处理关键错误。将其他错误修复安排为下一个 sprint 计划会议的一部分。如果您的冲刺时间较短（例如 1 周），这可能更容易实现，因为用户等待修复的时间会更少。
分析错误并查看某些开发工作是否可以防止将来出现问题。例如，您可能会发现由于数据不正确而出现了很多错误。花时间让代码更能容忍不良数据会有所帮助。
考虑在自动化回归测试上投入更多时间。这种前期的时间投资可以减少未来错误的数量。这样做似乎需要花费大量时间和精力，但让您的工作量更具可预测性可能足以抵消这一成本。

由于工作出现的不可预测方式，生产错误的影响比修复它们所花费的时间更大。这就是为什么关注质量是有意义的，即使它看起来确实需要付出很多额外的努力。

【讨论】：

【解决方案2】：

所以 SCRUM 真的是针对有计划的工作，如果有很多中断可能不是最好的方法，也许你应该看看看板或两者的结合？

【讨论】：

【解决方案3】：

@Banarby Golden 的回答已经很好地回答了核心问题，但是由于您还询问了如何在您的 JIRA 项目管理中实现这一点：

我建议使用不同的项目或不同的史诗来完成开发和支持任务。使用默认的 Scrum 项目进行开发，使用专用的看板项目来解决支持问题对我来说似乎是一种合理的方法（我们也在使用这种技术）。

如果您想可视化整个工作负载，您还可以创建跨多个项目的板。

【讨论】：

【解决方案4】：

您可以根据进入 sprint 的工作类型调整流程。它不必一成不变，因为事情会随着时间而改变。

看板为团队提供了足够的工作量，以便他们始终如一地满负荷工作。
Scrum 将工作划分为多个冲刺（固定长度的迭代），让团队能够处理最重要的故事。
Scrumban 是看板和 Scrum 的 hybrid。它基于持续的工作流程并遵循拉动系统。故事存在于积压工作中，团队仍在冲刺中运作，但 WIP（正在进行的工作）在工作流程的每个阶段都受到限制，并且使用周期和交付周期指标来衡量生产力。

注意：周期时间是团队工作流程中故事从开始到结束所用的时间。 Lead Time 是故事出现在 Scrumban 板上的总时间。

【讨论】：