我们的角色不仅仅是产品开发。我们还为内部和外部提供“一线支持”。外部客户以及任何这些任务本质上都将优先于任何产品开发优先级。
我们如何使用SCRUM的冲刺来帮助我们管理产品开发和支持问题？
答案 0 :(得分：3)
你可能想看一看看板或禁止扫描。我不是粉丝，但它可能会更好地适应您的情况，其中分心和中断可能是不可避免的。放弃冲刺但仍保持优先顺序。而不是跟踪和测量弹簧速度，而是测量每个阶段的延迟。
http://leansoftwareengineering.com/ksse/scrum-ban/
我建议退一步。如果您想成为一个有效的敏捷团队，您需要管理层购买......为什么开发团队会提供一流的支持？你有一个强大的scrummaster能够让团队免受内部客户的注意吗？我不知道你的支持量是多少，但是我会通过你的团队成员轮流进入一个障碍的位置，他们将所有支持/内部客户一次攻击一周，让其他成员集中注意力。在任何情况下，选择一个scrummaster ......通过该职位轮换团队成员，直到找到合适的人选。
答案 1 :(得分：0)
你好我想这很容易说，开头有点复杂。
导致团队中的每个成员必须熟悉团队中存在的角色，例如在我的公司中，我们使用大约1个月的时间进行迭代，然后我们进行轮换。
另外我认为你应该混合使用SCRUM和其他软件开发技术。
苏丹
答案 2 :(得分：0)
在解决冲刺问题之前，我认为了解你的团队是否围绕Scrum角色进行组织非常重要。
产品负责人和ScrumMaster应该是两个不同的人。您的单位是否已定义这些角色？如果没有，我建议考虑谁应该填补这些插槽。
无论如何，我认为从小做起，选择一些项目并试点这个过程会更好。从错误中吸取教训。看看哪些有效，哪些无效。
因为您知道其他工作可能优先于计划的活动。尝试以4周的时间间隔完成短跑几个月。随你进行迭代，反思和调整。
最后，让您的客户参与其中，邀请他们参与您的冲刺评论。您将获得很好的反馈，您的产品将更快地获得更好的效果。
答案 3 :(得分：0)
承诺减少。计划冲刺时，请指定最小可能速度。如果可用性增加，您可以随时从待办事项中提取项目。
如果您的资源在冲刺中的变化很大，请考虑转移到看板，正如其他人所建议的那样。
答案 4 :(得分：0)
我的团队也处于这种状况。我们有很多持续的开发工作，但也有一些支持。而且，我们支持生产服务，所以如果出现问题，我们可能需要删除所有内容并进行修复。
到目前为止，我们选择继续像以前一样继续使用scrum，但是为每个sprint预留一些时间用于持续预订的门票和其他工作。每天都有一个专门负责处理来门票，Nagios通知等的人。如果需要，该人可以随时咨询或将事情交给另一位工程师 - 但我们会尽量避免这种情况。这减少了其他工程师的干扰。
规划预留时间似乎非常困难：支持的负载趋于变化。但是，我们的经验是，大部分时间，我们的预留时间都在正确的范围内。显然有例外情况，我们会减少几天的工作日，但在最糟糕的情况下，我们会从冲刺中丢弃物品。我不记得上次发生这种情况了。
总结一下：大多数时候，支持负载是可以预测的。为sprint预留时间，它应该可以解决。但是，我能给出的最重要的建议是：尝试一些事情，即使你不确定这是正确的事情，并在你的回顾中回顾它。只有在你尝试过并且反映出来之后，你才能确定。
答案 5 :(得分：0)
我同意Trey。你可以考虑Kanban或Scrumban。但是当你是一个真正的开发团队后期制作并且由于一些奇怪的组织原因而无法跟随看板时你会怎么做？
我是一个团队的Scrum Master，与你的情况类似。现在让我明白这一点，当您说“第一行”用户是否直接联系您的产品所有者或您的团队？如果是的话，我认为需要有一个不同的Scrum团队来处理这个问题。
我们有一个运营支持Scrum团队，通常会这样做。请注意，此团队还可以执行发布和部署活动。还有一个不同的开发Scrum团队成员加入每个Sprint的Operations Support Scrum团队以获得支持活动。
重要的一点是，一旦Sprint开始为一个开发Scrum团队，不建议在当前Sprint期间开始添加生产问题积压。它可能会夺走当前Sprint的价值并使团队成员士气低落。 PO的责任是保持Sprint Backlog List稳定，她有时可能不得不与这项业务作斗争。 SM应该尽一切可能保护团队免受外部影响，并帮助PO确保Sprint Backlog稳定。
现在另一方面，如果Sprint目标已经过时，管理层有时可能需要取消Sprint。如果公司改变方向，或者市场或技术条件发生变化，或者生产问题太多，就会出现这种情况。一般情况下，如果在某些情况下不再有意义，Sprint应该被取消。但是，由于Sprint的持续时间很短，所以很少这样做。
总结一下：
参考文献：Scrum指南 - Ken Schwaber和Jeff Sutherland（Scrum的创造者）
答案 6 :(得分：0)
你不能两者都做。要么使用Scrum，要么支持您的客户。
我建议你使用Scrum，如果你能建立一个至少有五个开发人员的团队，他们不会在Sprint期间被中断。通常，即使需要支持，客户也可以等待Sprint结束。另一方面，您可能有一名备用开发人员，其职责是为客户提供支持。
然后，团队将能够通过开发更高价值的产品来完成其工作，从而降低您的客户支持需求。那么，在我看来，您的组织将从您的Scrum体验中受益。
答案 7 :(得分：0)
我有一个支持两种工具的团队 - 包括开发，错误修复，维护，工作。所以我们的情况并没有太大的不同。也许我们的解决方案也适合你......
我们最近开始使用Scrum进行为期两周的迭代。我们的方式，我们有一个服务水平协议，所有客户都接受; SLA未涵盖的请求仅在sprint计划期间被接受，而那些可以立即处理的请求。
然后我们在每个sprint中都有一个“常规支持”的用户故事，只需要我们遵循SLA。在此之下，我们为“未知请求”提出了一项任务，并在一两个小时内进行评估;当新的合法任务进入时，我们从未知数中减去新任务的评估，从而导致无法获得净工作。如果您恰当地估计了支持工作量，那么这不会导致开发时间的净损失。当然，如果你低估了，这可能会发生在前一两次，那就是你可以从下一个冲刺中学到的东西。
如果计划中已经考虑了支持，您可以在一个sprint中更好地评估可以实现开发的目标。传入的支持请求仍然可以在某种程度上随机化您的团队，但如果您可以一次关注一项任务，则效果不是很严重。
（我们也刚刚开始使用Rational Team Concert来跟踪所有内容，但我们还没有用这么长时间来说明在这种情况下它有多么有用。）