【发布时间】：2010-08-20 04:23:55
【问题描述】：
我们的角色不仅仅是产品开发。我们还为内部和外部客户提供“第一线支持”，任何这些任务，就其本质而言，总是会优先于任何产品开发优先事项。
我们如何使用 SCRUM 的 sprint 来帮助我们管理产品开发和支持问题？
【问题讨论】：
-
我投票结束这个问题，因为它是关于开发过程，而不是编程。
【发布时间】：2010-08-20 04:23:55
【问题描述】：
您可能想看看看板或 scrum-ban。我不是粉丝，但它可能更适合您可能无法避免分心和干扰的场景。放弃冲刺，但仍然保留优先级积压。测量每个阶段的延迟，而不是跟踪和测量弹簧速度。
http://leansoftwareengineering.com/ksse/scrum-ban/
不过，我建议您退后一步。如果你想成为一个有效的敏捷团队，你需要管理层收买……为什么开发团队要做第一级支持？您是否有一个强大的 scrummaster 能够使团队免受分散内部客户的注意力？我不知道您的支持量是多少，但我会尝试让您的团队成员轮流进入一个阻碍大局的位置，在那里他们一次将所有支持/内部客户支持一周，让其他成员集中精力。在任何情况下，选择一个 Scrummaster...轮流担任该职位的团队成员，直到找到合适的人选。
【讨论】：
-
其中一个原因可能是公司或 IT 部门。规模太小，无法拥有独立于开发的专门支持团队。
-
@Andy ...毫无疑问。这只是一个值得问的问题。 （IT 或客户支持）和工程没有太多的技能重叠，所以看到两个（或三个）分组很奇怪。我认为，当您这样做时，您通常应该质疑管理决策……通过发言或用脚投票并找到更好的公司工作。
你好，我想这说起来容易，一开始有点复杂。
导致您团队的每个成员都必须熟悉您团队中存在的角色，例如在我的公司中，我们使用大约 1 个月的时间进行迭代，然后我们进行轮换。
另外我认为你应该混合使用 SCRUM 和其他软件开发技术。
苏丹
【讨论】：
-
“另外我认为你应该混合使用 SCRUM 和其他软件开发技术”。你对他们的工作场所一无所知，那么你怎么能提供这个建议呢？我个人曾与试图将 SCRUM 融入现有瀑布模型的团队经历过非常糟糕的经历。 @Fairy Bower：要非常清楚，拒绝考虑具体情况的需求会花钱，烧毁员工，最终让你的公司失败。
-
Fairy Bower：这也不是说混合技术是错误的解决方案。只是我们几乎不了解您，更不用说您的开发团队了，所以我们怎么可能知道您的问题的正确解决方案是什么？
在解决 sprint 问题之前，我认为了解您的团队是否围绕 Scrum 角色进行组织非常重要。
- Product Owner - 优先考虑产品积压项目
- ScumMaster - 召开每日会议，帮助团队保持正轨，消除障碍...
- Team - 致力于交付已完成的待办事项的一群人
产品负责人和 ScrumMaster 应该是两个不同的人。这些角色是否已在您的单位中定义？如果没有，我建议考虑由谁来填补这些空缺。
无论如何，我认为最好从小处着手，挑选一些项目并试点流程。从你的错误中学习。看看哪些有效，哪些无效。
因为您知道其他工作可能优先于计划的活动。尝试在 4 周的时间间隔内完成 sprint 几个月。不断迭代、反思和调整。
最后，让您的客户参与进来，邀请他们参与您的 sprint 审核。您会得到很好的反馈，您的产品也会更快地变得更好。
【讨论】：
少承诺。当你计划冲刺时，指定一个最小的可能速度。如果您的可用性增加，您可以随时从积压中提取项目。
如果您的可用资源在各个 sprint 中变化很大，请考虑迁移到看板，正如其他人所建议的那样。
【讨论】：
我的团队也处于这种情况。我们有很多持续的开发工作，但也有一些支持。而且，我们支持生产服务，因此如果出现问题，我们可能需要放弃所有内容并进行修复。
到目前为止，我们选择像以前一样继续使用 scrum，但在每个 sprint 中为正在进行的票证和其他事先不知道的工作预留一些时间。每天都有专人负责处理进票、Nagios 通知等。如有需要，该人可以随时咨询或将事情交给另一位工程师 - 但我们尽量避免这种情况。这减少了对其他工程师流程的干扰。
计划预留时间似乎非常困难：支持的负担往往会有所不同。但是，我们的经验是，大多数时候，我们预留的时间都在合适的范围内。显然也有例外，我们会额外损失几个工作日，但在最坏的情况下，我们会从 sprint 中丢弃项目。不过我不记得上次发生这种情况是什么时候了。
总而言之：大多数时候，支撑负荷是可以预测的。在冲刺中为此预留时间，它应该会奏效。但是，我能给出的最重要的建议是：尝试一些事情，即使你不太确定这是正确的事情，并在你的回顾中回顾它。只有尝试过并反映后才能确定。
【讨论】：
我同意特雷的观点。您可以考虑看板或 Scrumban。但是当你是一个真正的开发团队后期制作并且由于某种奇怪的组织原因而无法遵循看板时，你会怎么做？
我是一个与你情况相似的团队的 Scrum Master。现在让我澄清一下，当您说“第一行”时，用户是直接联系您的产品负责人还是您的团队？如果是，我只是认为需要一个不同的 Scrum 团队来处理这个问题。
我们有一个运营支持 Scrum 团队，通常会这样做。请注意，该团队也可能会进行发布和部署活动。每个 Sprint 还让不同的开发 Scrum 团队成员加入运营支持 Scrum 团队以进行支持活动。
重要的一点是，一旦为开发 Scrum 团队开始 Sprint，不建议在当前 Sprint 期间开始添加生产问题待办事项。它可能会剥夺当前 Sprint 的价值并使团队成员士气低落。保持 Sprint Backlog List 稳定是 PO 的责任，她有时可能不得不为此与业务进行斗争。 SM 应该尽其所能保护团队免受外部影响，并帮助 PO 确保 Sprint Backlog 稳定。
现在，另一方面，如果 Sprint 目标过时，管理层有时可能需要取消 Sprint。如果公司改变方向，或者市场或技术条件发生变化，或者出现太多生产问题，就会发生这种情况。一般来说，如果 Sprint 在特定情况下不再有意义，则应该取消它。但是，由于 Sprint 的持续时间很短，因此这样做几乎没有意义。
总结一下：
- 组建运营支持 Scrum 团队，让他们成为负责生产支持积压工作的第一线支持人员。
- 每个 Sprint 轮流让开发人员加入运营支持 Scrum 团队，以帮助处理生产支持积压工作。
- 如果 Scrum 团队 PO 的 Sprint 目标已过时，则可以取消 Sprint 并使用新的 Sprint Backlog 开始新的 Sprint。
参考：Scrum 指南 - Ken Schwaber 和 Jeff Sutherland（Scrum 的创建者）
【讨论】：
你不能两者都做。要么使用 Scrum，要么支持你的客户。
如果您可以组建一个由至少五名开发人员组成的团队，并且在 Sprint 期间不会受到干扰，我建议您使用 Scrum。通常，即使需要支持，客户也可以等待 Sprint 结束。另一方面，您可能有一个备用开发人员，其工作是提供客户支持。
然后，团队将能够通过开发更高价值的产品来完成其工作，从而降低您的客户支持需求。在我看来，您的组织将从您的 Scrum 体验中受益。
【讨论】：
我的团队支持两种工具 - 包括开发、错误修复、维护、工程。所以我们的情况并没有太大的不同。也许我们的解决方案也适用于您...
我们最近开始使用 Scrum 进行为期两周的迭代。我们这样做的方式是，我们有一份被所有客户接受的服务水平协议； SLA 未涵盖的请求仅在 sprint 计划期间进行处理，而那些可以立即处理的请求。
然后，我们在每个 sprint 中都有一个“一般支持”的用户故事，它只要求我们遵循 SLA。在此之下，我们为“未知请求”设置了一个任务，该任务在某某几个小时内进行评估；当新的合法任务进来时，我们从未知数中减去新任务的评估，导致工作没有净收益。如果您适当地估计了支持工作量，那么这不会导致开发时间的净损失。当然，如果你确实低估了，这可能会发生在前一两次，那是你可以从下一个 sprint 中学到的东西。
有了计划中已经考虑到的支持，您可以更好地评估在一个 sprint 中可以实现的开发成果。收到的支持请求仍然可以使您的团队随机化，但如果您可以一次专注于一项任务，这种影响不会很严重。
（我们也刚刚开始使用 Rational Team Concert 来跟踪所有内容，但我们还没有使用足够长的时间来让我说出它在这种情况下的用处）。
【讨论】：