我们的角色不仅仅是产品开发。我们还为内部和外部客户提供“第一线支持”，这些任务中的任何一项，就其本质而言，总是会优先于任何产品开发优先事项。
我们如何使用 SCRUM 的 sprint 来帮助我们管理产品开发和支持问题？
问问题
1387 次
8 回答
3
你可能想看看看板或 scrum-ban。我不是粉丝，但它可能更适合您可能无法避免分心和干扰的场景。放弃冲刺，但仍然保留优先级积压。与其跟踪和测量弹簧速度，不如测量每个阶段的延迟。
http://leansoftwareengineering.com/ksse/scrum-ban/
不过，我建议您退后一步。如果你想成为一个有效的敏捷团队，你需要管理层收买……为什么开发团队要做第一级支持？您是否有一个强大的 scrummaster 能够使团队免受分散内部客户的注意力？我不知道你的支持量是多少，但我会尝试让你的团队成员轮流进入一个阻碍大局的位置，在那里他们一次将所有的支持/内部客户支持一周，让其他成员集中精力。在任何情况下，选择一个 scrummaster... 轮换团队成员担任该职位，直到找到合适的人选。
于 2010-08-20T04:46:42.193 回答
0
你好，我想这很容易说，一开始有点复杂。
导致团队中的每个成员都必须熟悉团队中存在的角色，例如在我的公司中，我们使用大约 1 个月的时间进行迭代，然后进行轮换。
另外我认为你应该混合使用 SCRUM 和其他软件开发技术。
苏丹
于 2010-08-20T04:37:50.123 回答
0
在解决 sprint 问题之前，我认为了解您的团队是否围绕 Scrum 角色组织起来很重要。
- 产品负责人- 优先考虑产品积压项目
- ScumMaster - 召开每日会议，帮助团队保持正轨，消除障碍......
- 团队——致力于交付已完成的待办事项的一群人
Product Owner 和 ScrumMaster 应该是两个不同的人。这些角色是否已在您的单位中定义？如果没有，我建议考虑由谁来填补这些空缺。
无论如何，我认为最好从小处着手，挑选一些项目并进行试点。从你的错误中学习。看看哪些有效，哪些无效。
因为您知道其他工作可能优先于计划的活动。尝试在 4 周的时间间隔内完成 sprint 几个月。随心所欲地迭代、反思和调整。
最后，让您的客户参与进来，邀请他们参加您的 sprint 评审。你会得到很好的反馈，你的产品会更快地变得更好。
于 2010-08-20T05:50:39.363 回答
0
少承诺。当你计划冲刺时，指定一个最小的可能速度。如果您的可用性增加，您可以随时从积压中提取项目。
如果您的可用资源在 sprint 中变化很大，请考虑转移到看板，正如其他人所建议的那样。
于 2010-08-20T14:32:51.807 回答
0
我的团队也处于这种情况。我们有很多持续的开发工作，但也有一些支持。而且，我们支持生产服务，因此如果出现问题，我们可能需要放弃所有内容并进行修复。
到目前为止，我们选择像以前一样继续使用 scrum，但在每个 sprint 中为正在进行的票证和其他事先不知道的工作预留一些时间。每天都有专人负责处理进票、Nagios 通知等。如有需要，该人可以随时咨询或将事情交给另一位工程师 - 但我们尽量避免这种情况。这减少了对其他工程师流程的干扰。
计划保留时间可能看起来非常困难：支持的负载往往会有所不同。但是，我们的经验是，大多数时候，我们预留的时间都在合适的范围内。显然有例外，我们会额外损失几个工作日，但在最坏的情况下，我们会从 sprint 中删除项目。我不记得上次发生这种情况是什么时候了。
总而言之：大多数时候，支撑负载是可以预测的。在冲刺中为此预留时间，它应该会奏效。但是，我能给出的最重要的建议是：尝试一些事情，即使你不确定它是不是正确的事情，并在你的回顾中回顾它。你只有在尝试过并反思过之后才能确定。
于 2010-08-22T18:41:57.443 回答
0
我同意特雷的观点。您可以考虑看板或 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 Backlogs 开始新的 Sprint。
参考：Scrum 指南 - Ken Schwaber 和 Jeff Sutherland（Scrum 的创建者）
于 2010-09-15T20:53:42.320 回答
0
你不能两者都做。要么使用 Scrum，要么支持你的客户。
如果您可以组建一个至少由五名开发人员组成的团队，并且在 Sprint 期间不会被打断，我建议您使用 Scrum。通常，即使需要支持，客户也可以等待 Sprint 结束。另一方面，您可能有一个备用开发人员，其工作是满足客户支持。
然后，该团队将能够通过开发更高价值的产品来完成其工作，从而降低您的客户支持需求。在我看来，您的组织将从您的 Scrum 体验中受益。
于 2010-10-29T02:36:14.783 回答
0
我有一个支持两种工具的团队——包括开发、错误修复、维护、工程。所以我们的情况并没有太大的不同。也许我们的解决方案也可以为您服务...
我们最近开始使用 Scrum 进行为期两周的迭代。我们这样做的方式是，我们有一份被所有客户接受的服务水平协议；SLA 未涵盖的请求仅在 sprint 计划期间接受，而那些可以立即处理的请求。
然后，我们在每个 sprint 中都有一个“一般支持”的用户故事，它只要求我们遵循 SLA。在此之下，我们为“未知请求”设置了一个任务，该任务在某某几个小时内进行评估；当新的合法任务进来时，我们从未知数中减去新任务的评估，导致工作没有净收益。如果您适当地估计了支持工作的数量，那么这不会导致开发时间的净损失。当然，如果你确实低估了，这可能会在前一两次发生，那是你可以从下一个 sprint 中学到的东西。
有了计划中已经考虑到的支持，您可以更好地评估在一个 sprint 中可以实现的开发成果。传入的支持请求仍然可以使您的团队随机化，但是如果您一次可以专注于一项任务，则这种影响不是很严重。
（我们也刚刚开始使用 Rational Team Concert 来跟踪所有内容，但是我们还没有使用足够长的时间来让我说出它在这种情况下的用处）。
于 2011-09-15T13:21:11.023 回答