我有一个基本的看板，在开发人员和测试人员之间进行切换：
----------------------------------------------------
| To Do | Ready | Develop | Test | Done |
| | | In Progress | Done | | |
假设我在板上设置了一些限制。如果一个项目未能通过测试，我该怎么办？实际修复错误不是测试人员的工作，所以在我看来，它不可能进入“完成”。我希望测试人员将其放回“就绪”状态，但这将超出限制。如果测试人员将某个项目从“就绪”降级为“待办事项”，他基本上是在撤消 PO 的优先级。
到目前为止，我的想法是接受超出“就绪”的限制，标记未通过测试的项目，并将它们作为优先事项。
还有其他想法吗？
I'd split Ready state to Re-Open and Ready. In this case you can clearly separate items that need re-work and new items. Items that need re-work usually should be handled first, so it will be clear to developers what is new and what is returned from Testing phase.
几种可能的解决方案（我相信还有其他解决方案），包括：
1) 标记工单，团队期望标记的项目（无论出于何种原因）作为优先事项得到解决。
2) 向后移动车票。（但是董事会真的反映了项目的状态吗？你是否也解除了这些变化？值得思考。）
3) 创建新票。也许是一条特殊的泳道或对他们来说不同的颜色。
它们甚至不是相互排斥的。即使你坚持使用#1（我的默认偏好），当项目即使在其当前状态下也值得发布时，#3 也是有意义的，如果它不是一个错误而是一个重大误解，#2 可能是有意义的。
进一步的思考：降低开发人员的 WIP 限制，和/或添加跨越开发和测试的限制，进一步鼓励开发人员在整个过程中支持他们的工作。
我很确定我将在回复中描述的内容与规范看板非常不同。我的意思是，这可能非常有争议。
尽管如此，既然你问了其他想法，我猜你可能也对异端观点感兴趣。如果它不适合您的情况，请将其作为概念证明。
首先，简要概述一下我正在使用的隐喻。考虑一下您可以在此处找到的视频的简短摘录
" 假设一块板子至少代表两列（例如，Doing 和 QA，但名称在这里并不重要）代表一个程序员被要求执行的活动。假设这种情况：任务 B 在积压中，而任务 A 实际正在进行中。当任务 A 移到 QA，程序员应该做任务 A 还是将任务 B 移到 Doing 并开始工作？我们都知道多任务处理是邪恶的，程序员不应该同时处理任务 A 和任务 B。
正确答案是：首先完成任务 A。看板是一个拉动系统，可以很清楚地说明这一点：但即使没有看板，很明显任务 A 更接近于商业价值，不应该停在 QA 列并尽快移动到 Done 列。废物应该被消除而不是储存。
这就引出了一个问题：Doing Column 中是否有空闲 Slot？另一个程序员可以将任务 B 向前推进吗？
问题放错了地方。如果只有一个开发人员，答案是否定的。由于程序员不可用，事实上的工作进度限制应该减少到 0。如果有 2 个开发人员，正确的问题应该是“其他开发人员有空吗？”
事实是：Work In Progress Limit 不是 Free Slots 的衡量标准。可用开发人员的数量是。
我试图想象的板子使用了另一个原则：单个程序员的通用、个人和定制的表示，比如磁贴。叫它脸。一个程序员把他的脸放在一个任务上，以表达他正在解决这个问题。由于每个程序员只有一张 Face，因此程序员不能提交多个任务。正在进行的工作限制并不是衡量可用空位数量的标准：可用团队成员，即没有任务的面孔，是一个很好的衡量标准。
规则很简单：每个团队成员只有一张脸，并且只能将其用于一项任务。
然而，后果并非微不足道：使用 Faces 可以很容易地查看谁与谁合作、团队如何聚集以及可以就特定问题询问谁。"
换句话说，我的想法是：WIP 限制可能不是您应该在列中放入项目的最合适的衡量标准，特别是当所有列的 WIP 总和大于开发人员的数量时（即是，您实际上可以依靠的插槽）。
我相信这同样适用于您的案例：在 QA 列中，您有一个看板项目失败测试。对我来说，将它向后移动到doing 栏中没有问题，正在处理失败项目的开发人员仍然致力于它。实际上，您有一个空闲位置。
我不明白为什么 Doing 列的 WIP 限制会阻止您的工作流程。不然该怎么办？为了尊重您在专栏上写的任意数字，您是否应该将开发人员转移到另一项任务？如果您决定放弃并违反WIP限制，您不应该质疑该限制的含义和针对性和适用性吗？
简而言之：只要您有开发人员致力于该任务，就将任务移回。
这取决于您想要达到的目标。一种选择是认真对待失败，以至于您退回当前工作项以修复错误。
我认为您的解决方案会很好（使失败的标记非常明显）。
也许真正的答案是试一试，看看效果如何。
我相信您应该在 In Progress 列中有两个子列。一个应该是“积极工作”，另一个应该是“等待”或任何你想称之为的。如果测试失败，请将其移回等待。
如果您想衡量有多少人从测试中返回（这是一个好主意），请专门为它设置一个子列。
无论您选择做什么，都将其放在板的“进行中”区域下。
我过去的做法是将失败的票移回“工作中”。因为可以预见许多票证最终会在测试阶段失败，所以您应该将其构建到“工作”中允许的票证数量以及您实际放入的数量中。
例如，您可能允许每个开发人员有两张票用于“工作”，并永久保留其中一个用于失败的票。
如果该项目已进行测试，然后以一种方式查看它，它的优先级高于“待办事项”列中的任何其他内容，因此可以放在该列的顶部，将底部的项目撞掉。
或者，测试人员是否可以将项目带回采购订单并让他们重新确定优先级 - 所以它基本上从待办事项列重新开始？这就是 PO 的用途——他们决定修复的重要性。
我处理这个问题的方法是将故事留在测试中，但标记它已经失败。它将很快成为测试列中的瓶颈，因为测试人员将无法在不突破 WIP 限制的情况下提取新项目。这迫使团队蜂拥而至完成该项目（即解决问题并重新测试）。
值得提出以下问题。开发是谁的责任？测试是谁的责任？在测试失败的情况下重新开发是谁的责任？希望你的答案是“团队”。