本文主要是介绍Scrum团队在迭代中如何处理计划外的工作，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
认为 Scrum 团队不做计划其实是一个误区，实际上很多 Scrum 团队在冲刺计划会议以及在细化工作项时均会进行详细规划。此外，他们还会创建一个路线图，以便显示他们在多个冲刺中的计划。
Scrum 团队需要经常进行计划，以便在不断变化、信息不断涌现的复杂环境中不迷失方向。团队评估新的信息，并调整他们的工作方式以充分利用所获得的新知识。
当团队在冲刺进行中突然遇到未计划的工作时，应该如何处理？本文将分享一些最佳实践。
处理计划外工作的三个最佳实践
不可避免地，无论 Scrum 团队如何精心计划，总会有突如其来的需求要求团队在冲刺（Sprint）中途处理未计划的工作。
发生这种情况时，开发人员与产品负责人应立即拉起会议，讨论如何应对。为什么要由开发人员和产品负责人来处理？因为产品负责人负责对产品待办列表中的任务进行优先级安排，只有他们有权决定是否将这项突发工作加入产品待办列表，并判断其是否足够重要以至于需要在当前冲刺待办列表中加以考虑。
产品待办列表
另一方面，由开发人员负责完成冲刺待办列表，只有他们可以判断自己是否有能力接下这项额外工作，同时不影响冲刺目标的实现。
如果产品负责人确实希望在冲刺中添加新的工作项，开发团队可以选择拒绝，或者可以与产品负责人协商，决定为了容纳新的需求而从当前冲刺中移除哪些任务。不过不能因为需求变更而使冲刺目标受到威胁。
有些 Scrum 团队经常面临大量未计划的工作。例如许多 Scrum 团队不仅要负责新的开发任务，还要处理生产支持问题。
对许多组织而言，生产支持的工作是不可预测的，且不能推迟到下一个冲刺处理——必须立即处理这些请求。尽管这类工作属于未计划的，但它对于产品的成功至关重要。
下面是几种处理未计划工作的方法。
选择1：预留一定容量，将未计划的工作加入冲刺待办列表
在此方法中，开发团队在冲刺计划时会预估未来冲刺可能接收到的未计划工作量，并相应预留出一部分容量来处理这些突发事件。这个预测并不容易，因为这其中很多东西都是未知的。
虽然我们无法做到这一点，但可以通过回顾历史表现来做出有根据的预测。
比如，过去几次冲刺中，未计划工作占用了团队多少时间？这些突发任务的出现是高度不可预测的还是相对稳定的？通过这些问题的答案，我们可以预估出应为冲刺期间可能出现的临时需求留出多少空间。
一旦未计划的工作出现，如果产品负责人和开发团队同意将其加入冲刺，他们应将其包含在冲刺待办列表中，以确保工作的透明度，保证团队能够跟踪冲刺中所有任务的进展。
选择2：预留一定容量，但不将未计划的工作加入冲刺待办列表
如果未计划的工作由一系列较小的任务构成，Scrum 团队可能会考虑是否真的需要将这些任务加入冲刺待办列表，尽管不加入会导致缺乏透明度。但大量的小任务如果加入冲刺待办列表，可能会造成管理上的负担。
在这种情况下，团队仍可以选择不增加冲刺待办列表的负载，而是选择在冲刺范围之外处理这些未计划的工作。在这种做法下，团队会预留出部分能力，从而避免了将其加入冲刺待办列表所带来的管理负担。
选择3：设立专门团队处理未计划工作
如果未计划的工作量大且频繁，Scrum 团队可以考虑分设一个团队专门负责生产支持等任务。
限制计划外工作影响的策略
正如很多 Scrum 专家所分享的，每次冲刺都是组织和 Scrum 团队之间的一个约定。Scrum 团队需要尽可能地集中精力处理冲刺中的工作以及定期的优化工作，组织将定期获得可用的产品增量。
然而，在某些组织中，完全避免计划外的工作是比较困难的。如果您的团队经常面对意外工作，以下是几种我们可以采用的策略。
1.优先完成当前工作项
当遭遇计划外的工作时，立即停下手中的工作并转向紧急任务看起来很好。但最好不要这么做。应当先完成当前的工作，然后再着手处理下一个优先级最高的工作项。
原因是什么呢？
因为当我们暂停当前的工作，并在未完成先前任务之前开始另一项任务时，我们将留下许多未完成的工作，这会造成浪费。那些“未完成的工作”不能永久地搁置，否则会变得过时。而且，当我们最终回到最初的工作项时，由于需要重新组织思路，完成这项工作所需的时间将会更长。
2.限制进行中的工作
如果团队面临大量计划外的工作，限制进行中的工作变得更加重要。进行中的工作指的是我们在冲刺期间正在进行的任务数量。如果我们的进行中的工作很多，并且遇到计划外的工作，我们将需要在转向这些额外工作之前做很多调整。
通过限制进行中的工作，我们在将精力投入计划外工作之前，没有太多需要暂停或完成的任务。
3.将工作切割得更细
对于经常面临大量计划外工作的团队来说，另一个策略是将计划中的工作分解成更小的部分。这样做可以使我们更快地完成当前任务，并在出现计划外工作时更迅速地转换方向。
4.结对工作
与每位开发者分别承担各自的任务不同，配对工作涉及两位开发者共同完成同一项任务。这种策略带来两个好处：
一方面，实际上它限制了进行中的工作量。另一方面，当面对计划外的工作时，它为团队提供了更大的灵活性，因为他们可以更快地完成当前的工作项，或者安排其中一位开发者转向新任务，而另一位继续进行原有任务。
结论
无论 Scrum 团队如何精心计划，总有时候会在冲刺中途出现计划外的工作请求。出现这种情况时，开发者和产品负责人商量，确定是否将这些额外的工作添加到当前冲刺中。
Scrum 团队应事先决定如何处理计划外的工作——是将其加入冲刺待办列表，还是在冲刺范围之外完成它？
如果频繁出现意外工作，团队是否应预留一些容量来处理这些工作，或者是否应该由一个专门的团队来承担？只有 Scrum 团队能够回答这些问题，并且随着对客户需求的了解增加，他们的处理方法可能会发生变化。
推荐阅读：
Scrum 开发指南： Scrum 框架详解 | Scrum 四个会议及正确召开方式 | 正确的计划和执行Sprint的方式 | 做好迭代计划的4大关键点 | 做好这4点让每日站会更适配敏捷团队 | 开好迭代评审会的3个关键步骤 | 为什么要召开迭代回顾会 | Scrum 3大角色及其岗位的具体职责 | Scrum三大工件在敏捷开发中的作用 | 2022年14个最佳 Scrum 敏捷项目管理软件 | 更多
Kanban 敏捷指南： 使用看板（Kanban）管理方法的5大好处 | 看板 VS Scrum：如何选择？ | 看板和 Scrum 的混合模式适合在哪些场景使用 | 更多
规模化敏捷： 规模化敏捷的价值及五大规模化敏捷框架 | 规模化敏捷之 Spotify 模型 | 规模化敏捷框架之LeSS框架 | SAFe 规模化敏捷框架 | Scrum@Scale 模型 | 敏捷项目组合管理 | OKR与敏捷开发 | 更多
产品管理： 如何构建合格的产品路线图 | 如何成为一个优秀的产品经理 | 敏捷路线图的重要性以及构建 | 如何构建简单有效的产品需求文档 | 利用 NPS 确定功能优先级 | 每个产品经理都需要了解的产品分析技能 | 更多
这篇关于Scrum团队在迭代中如何处理计划外的工作的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
