阻滞剂vs.暂停?

我认为最好把内部障碍和外部障碍分开。

外部障碍是指依赖关系存在于团队之外，团队无法推进项目，直到他们控制之外的工作完成。这些障碍是严重的，因为它们表明团队已经接受了他们无法完成的工作。他们不拥有自己的过程。Sprint目标处于危险之中，对于受影响的项目，团队无法满足他们的“完成定义”。这是敏捷实践的禁忌，在Sprint回顾之前解决这个问题是至关重要的。

内部障碍是团队内部存在的依赖关系。例如，可能是一个团队成员正在协助另一个成员，他或她正在处理的项目被延迟了。这并不严重，因为这意味着解决方案在团队的控制范围内。

有多种方法可以标记这些拦截程序。对于外部障碍，我使用日晒光，用记号笔把它贴在标记卡上，然后把它拍在索引卡上，这样就可以使情况尽可能清晰。对于内部障碍，我指导团队成员把卡片颠倒过来。

跨越多个sprint的阻塞非常有趣。这些都对产品所有权有影响。他们不禁要问，这份工作真的需要吗?它与正在设定的Sprint目标有什么关系?这一项目是否应该被完全丢弃?

具有讽刺意味的是，一些长期的障碍是由于从客户那里得到反馈的延迟，特别是在BAU更改时。这种情况发生的次数令人惊讶，我的解决办法是制定一个规则，以避免由此产生的浪费。如果一个项目被阻止，因为提出它的客户X天没有回复，那么它将被删除。我会记录下我尝试联系他们的次数，以及给他们的通知/警告。然后，如果客户仍然需要它，则必须重新提交他们的票据请求，并且它会到达待办事项的底部。当然，这就是我使用BAU看板处理事情的方式。如果我解释我在价值链方面的努力，我通常可以得到高级管理人员的支持。

谢谢，我从来没有这样想过，但把内部和外部障碍分开是有意义的。

我喜欢@Ian对这个问题的解释。

另外，我想写一个关于如何分类“阻塞任务”和解释它们的小注释。

就像每个人都应该知道“完成”是什么一样，将Sprint backlog的类别视为信息散热器的一部分——每个人都应该能够知道它的含义。一定要和团队确认什么是有意义的。如果有一个类别暗示着“在这个Sprint中需要注意”等等，那么询问团队如何捕捉它?

作为测试，考虑团队外部的人进来，并尝试解释这一点，只要他们对团队不构成威胁。他们甚至不必是组织内敏捷团队的一员。如果他们明白了这一点，也许任何新加入的人都会很快明白这一点。

希望这能有所帮助。

>>>>我注意到相当多的任务被放入“阻塞”状态，这些任务保持阻塞数周
他们不应该停留在封锁状态几天，更不用说几个星期了。如果遵循Scrum，产品负责人就会为Sprint确定最高优先级的项目，然后自然而然地团队就会处理与这些最高优先级项目相关的任务。
如果任务被阻塞，那么你自然就不能实现你的Sprint目标，这将阻碍团队的进展。这些都必须在Scrum会议上提出，因为那是进行检查的论坛。

然后，由Scrum管理员来尝试促成解决方案，如果这不能发生，产品负责人必须知道Sprint目标受到了威胁。

我很少看到产品负责人仅仅因为项目被阻塞而改变优先级，并让团队去做其他事情。如果一个项目是高优先级的，并且它仍然存在，那么必须尽一切努力完成它。记住，任何项目都可以在下一个sprint中继续，只要它仍然是优先级。与该项相关的任务可能需要重新访问，在某些情况下，已经为该项完成的工作可以重用。

在一天结束的时候，分析你的团队所处位置的最好方法是检查他们是否有一个完整的功能增量，该增量满足在sprint结束时完成的定义。
如果答案是否定的，那么所有已完成或未完成的工作都必须根据再次选择项目执行时的普遍条件重新评估。

因此，在某些情况下，当你几周后再次使用该项目时，对该项目所做的部分工作可能是无关紧要的。

你提到了阻塞任务的积压，这一事实清楚地表明，许多sprint没有达到他们的目标，这要求对整个Scrum团队的方法进行认真的审查，这其中包括产品负责人。

我们组织正在讨论这个问题。我认为增加了额外的复杂性，因为我们使用的Azure Dev Ops不支持保持或阻塞状态。在我看来，“保持”和“阻止”两种状态都意味着物品是暂时不工作因为这样或那样的原因。两者之间唯一的区别是当你计划报告其中一个或两个项目时，或者你计划在一个集合上采取一些你不会在另一个集合上采取的行动时。

对于我所合作的团队来说，我们不会在“封锁”和“保持”之间争论不休。我们只需选择一个或另一个状态，并提供将项目置于该状态的描述暂时的状态．有时，这是一个会持续几个月的重要原因。有时候，这是一个很小的原因，只会持续几天或几周。因为每件物品都是不同的，我们会在检查或梳理过程中单独对待它们。例如，如果我们在暂时的状态(阻塞或暂停)我们评估项目的条件，并对每个项目做出后续决定。后续决策的一些例子是设置一个稍后跟进的提醒，删除不再需要的项目，或者将项目与可跟踪的依赖项关联起来。

很好的回答，但是问题…无论何时我们使用阻滞剂，我们都发现它是一个充满情感的词。

总是有一个人在拦截者的末尾，没有人想被“指责”为一个拦截者。我发现，即使在运作良好的团队中，这也会侵蚀心理安全感。

对于不同的措辞，你有什么建议吗?

障碍。

老实说，如果有人妨碍别人完成工作，那就应该指出来。我知道政治正确很重要，但说实话，有人被“阻止”完成工作。没有什么不明显的礼貌表达方式了。不过我可以变得更有创意。

• 乐高积木(等它沉进去)
• 挤
• 三维矩形对象
• 阻塞
• 等待
• 无法前进
• 封锁

总是有一个人在拦截者的末尾，没有人想被“指责”为一个拦截者。我发现，即使在运作良好的团队中，这也会侵蚀心理安全感。

侵蚀你所描述的透明度会提高心理安全吗?

谢谢丹尼尔，是的，你是对的，让我们把勺子叫做勺子:)我只是发现“拦截器”这个词太final了，我经常看到人们对它的反应比他们应该的更强烈。

我说的是Ian描述的外部阻滞剂。在一个运作良好的团队中，可能变成外部阻碍、障碍或依赖的问题会在backlog细化期间被识别和计划。因此，在这些情况下，障碍是在冲刺过程中发现的，在这种情况下，它们可能与能够解除障碍的个人或团队的优先级和工作量不一致。

我确实喜欢“等待”，但也同意Ian的观点，即我们不想削弱透明度。我不确定正确的答案是什么，所以也许我现在应该把术语放在一边。

我说的是Ian描述的外部阻滞剂。

这是一条古老的线索，但9年后回过头来看，我想说缺失的部分是承诺．

内部和外部镜头仍然有用。然而，我现在不太关心这个，而更关心培养一种意识承诺是由开发人员制作的，以及演示的必要性问责制不管障碍可能来自哪里。

在一个运作良好的团队中，可能变成外部阻碍、障碍或依赖的问题会在backlog细化期间被识别和计划。

我建议产品待办事项列表改进应该确保这一点不会发生．

细化是使工作为Sprint计划做好准备的活动，这意味着开发人员有信心在Sprint中完成工作。

所以在这些情况下，障碍是在冲刺过程中发现的

这通常是一个问题，它表明工作没有事先得到令人满意的改进。

细化可以被看作是降低Sprint风险的艺术和科学。当一个团队进入Sprint计划时，问题永远不应该是“我们能做这项工作吗?”，而是“为了实现有用的Sprint目标，我们应该做这项工作吗?”

谢谢你的澄清，伊恩。