我有一个基本的看板板，与开发者和测试之间的切换：我应该如何处理未通过测试的看板项目？
----------------------------------------------------
| To Do | Ready | Develop | Test | Done |
| | | In Progress | Done | | |
假设我已经把主板上的某些限制。 如果某件产品未通过测试，该怎么办？实际上，修复这个错误并不是测试人员的工作，所以就我所见，它不可能进入“完成”。 我希望测试人员将其重新放回“准备就绪”状态，但这将超出限制。如果测试人员将项目从“准备好”降级到“待办事项”，他基本上将取消PO的优先级排序。
到目前为止，我的灵魂应该超越“准备好”的限制，标记测试失败的项目，并将其作为优先考虑事项。
还有其他想法吗？
我会将Ready状态分为Re-Open和Ready。在这种情况下，您可以清楚地区分需要重新工作的项目和新项目。需要重新工作的项目通常应该首先处理，因此开发人员应该清楚什么是新的，以及测试阶段返回的内容。
几种可能的解决方案（我敢肯定还有其他的），包括：
1）标记门票的地方，与团队期望标志项（无论何种原因）得到解决作为优先事项。
2）向后移动门票。 （但是，董事会是否真的反映了项目的状态？你是否也放松了这些变化？值得思考）。
3）创建新票。也许是一个特殊泳道或对他们不同的颜色。
他们甚至没有相互排斥。即使你坚持＃1（我的默认首选项），当项目在当前状态下值得释放时，＃3是有意义的，如果它不是一个错误，而是一个重大的误解，＃2可能是有意义的。
进一步思考：对开发人员的WIP限制较低，或者增加一个跨越dev &测试的限制，进一步鼓励开发人员在整个过程中支持他们的工作。
我不喜欢选项3.创建新票将很难跟踪。 – 2012-02-22 13:00:00
我也不喜欢它，但它确实反映了许多团队已经做了什么。 “从你现在做的事开始”以及所有这些。 – asplake 2012-02-22 13:56:57
我不想强迫失败的项目在同一开发者的权利，因为它是“推”在我看来。这也可能导致一个开发者严重多任务而另一个开发者闲置的情况。我现在要将票倒退，并将其标记出来。 – 2012-02-28 10:15:34
这取决于你想达到什么。一种选择是认真对待失败，以便反弹当前的工作项目以修复错误。
我认为你的解决方案会很好（使失败的标记真的很明显）。
也许真正的答案是尝试一段时间，看看它是如何工作的。
我希望避免弹出项目，因为这样会取消PO的工作：测试人员现在决定排队中的哪些项目会被弹开，因此他们正在确定优先级。 我打算尝试一下我的解决方案，看看会发生什么。 – 2012-02-28 10:08:19
我很确定我要在回复中描述的内容与cannon看板很不一样。我的意思是，这可能是非常非常有争议的。
从来没有那么少，既然你问了其他想法，我猜你也许会对异端观点感兴趣。如果它不适合你的情况，请把它当作概念证明。
首先，略述一下我正在使用的隐喻。在考虑采取从video you can find here
这短短的摘录“ 假设董事会代表至少两列（例如，做和QA，但名称并不重要）代表活动程序员被称为做。 假设这情况：积压任务B和实际进行中的任务A当任务A转移到QA时，程序员应该在任务A上工作还是将任务B移动到执行中并开始处理？我们都知道多任务是邪恶的，程序员不应该在任务A和任务B上工作。
正确的答案是：首先在任务A上工作。看板是一个拉动系统，可以很清楚地说明：但即使没有看板，显然任务A更接近成为商业价值，不应将其停放在质量保证专栏中，并尽快转到完成专栏。应该消除废物，不要储存。
这引出了一个问题：在列中有空闲插槽吗？另一位程序员可以向前移动任务B吗？
的问题是放错了地方。如果只有一个开发人员，答案是否定的。 由于程序员是不可用的，事实上的工作做柱进展限值应减少到0为止 随着2开发商，正确的问题应该是“可在其他开发者？”
事实是：工作进行中限制不是空闲插槽的度量。可用开发人员的数量是。
我试图想象该板使用另一条原则：一个程序员的一个通用的，个人的和定制的表示，像磁贴。称它为Face。 一位程序员把他的脸放在一个任务上来沟通他正在处理这个问题。由于每个程序员只有一个Face，程序员不能承担多个任务。 工作进度限制不是有多少空闲插槽可用的度量：可用的团队成员，即没有任务的面孔是一个很好的衡量标准。
规则很简单：每个团队成员刚刚1的脸，可以把它放在只有1任务。
然而，后果是不平凡的：使用面孔很容易，看看谁的工作谁用，球队是如何聚类和谁可以要求对具体问题。 “
换句话说，我认为是：在制品限制可能不是您应该放入列中的项目的最合适的度量，尤其是当所有列的WIP总和大于开发人员的数量（即您实际上可以依赖的插槽数量）
我相信这同样适用于您的案例：在QA专栏中，您有一个看板项目失败测试对我来说，没有问题在执行列中向后移动时，正在处理失败项目的开发人员仍然致力于实际上，您有一个空闲插槽
我不明白为什么在制造商的WIP限制lumn应该阻止你的工作流程。你应该怎么做，否则？为了尊重您在专栏中撰写的任意数字，您是否应该将开发人员移至其他任务？如果您决定放弃并违反WIP限制，您是否应该质疑该限制的含义和针对性以及适用性？
简而言之：移动任务回来，只要你投入到这项开发。
我过去的做法是将失败的票据移回“正在工作”。因为可以预测的是，很多门票在测试阶段最终都会失败，所以您应该将其纳入“正在进行中”所允许的门票数量以及实际投入的门票数量。
例如，您可能允许每个开发者的两张票据用于“正在处理”，并且永久保留失败票据的其中一个位置。
事情是，无论我如何放置极限，我都可以想象这些极限的优点。在这种情况下，我可以想象一个开发人员完成了3个项目，然后挑选了4个项目，但之后所有这三个测试都失败了，突然间程序员有4个项目分配给他。 – 2012-02-28 10:05:40
只要您保留至少一半的可用空间供失败票使用，我不认为这是可能的。 – 2012-03-06 16:12:16
如果该项目已经达到测试的程度，然后以单向方式进行查看，则该项目的优先级高于“待办事项”列中的任何其他项目，因此可以放在该列的顶部，使底部项目关闭。
或者，测试人员能否将该物品带回PO并让他们重新排列优先顺序 - 因此它基本上是从待办列中重新开始的？这就是采购订单的目的 - 他们决定解决问题的重要性。
我相信你应该有两个子列在进行中。一个应该是“积极工作”，另一个应该是“等待”或任何你想称之为的。如果测试失败，请将其移回等待。
如果您想测量从测试中返回的次数（这是一个好主意），请为其指定一个子列。
无论您选择做什么，请在董事会的“进行中”部分下进行。
我会处理这个问题的方式是将故事留在测试中，但标记为失败。它很快就会成为测试专栏的瓶颈，因为测试人员无法在不打破WIP限制的情况下提取新项目。这会迫使团队在该项目上集群来完成它（即修复问题&重新测试）。
值得问以下问题。发展的责任是谁？它要测试谁的责任？在测试失败的情况下重新开发谁的责任？希望你的回答是“团队”。
现在我只有一个相当小的板子，所以添加更多的柱子不是一种选择，尽管我愿意。我为失败的项目添加了一个明显的标记，因此它们应该优先。 – 2012-02-28 10:10:54
@Michael Dubakov：那么你如何处理物理累积流程图呢？当您将开发项目移动到测试中时，您会更新开发线，并且过了一段时间后，该项目会回到就绪部分，然后您开始研究它。如何计算半任务再次进入游戏时的速度在这种情况下，你对估计有什么想法？ – Mohsen 2016-04-26 14:12:12