我们应该把没有通过测试的故事回退到“开发”状态吗？

Eric Willeke 在思考：任务看板上的那些没有通过测试的用户故事，该怎么处理呢？应该把它回退到“开发”状态，还是保留“测试中”的状态？他提出了一些不同的方案：

• 一个方法是把开发和测试状态合并为“完成”状态，这样就不存在状态变化了。团队通过协作，分解出一系列小到能分配给单个开发人员 / 测试人员的子任务，但直到每个人都同意所有子任务都完成了，这个用户故事才算完成。
• 另外一种方法是把故事移到测试状态，需要的话再移回去，如此反复。如果这就是你日常工作中的真实情况，那么你应该以此建立模型。
• 还有一种方法是在某项上放置一个“缺陷”标志（或者缺陷卡片），但是在测试过程中当开发人员来帮忙修复缺陷的时候，标志还会一直放在那里，直到所有问题都被修复。如果这种情况更符合你的实际工作，你更应该以这种方式建立模型。

Thierry Henrio 提出了不同的方案，他从精益制造行业借鉴过来了“红卡箱”(red bins) 的概念：

我是这么做的： - 每个状态栏都准备一个专用的红卡箱, 放在看板的底部靠上方

• 当某个状态栏的任务出现了问题，就把红卡箱移过去
• 我们有 30 分钟解决问题，消灭红卡箱

这套机制对于鼓励团队高效处理问题还是很有效的。但当问题出现在上游工序，那么 30 分钟就不够了，这种方法的效果也大打折扣。

专用的红卡箱相比红色标志，有更加强烈的可视化效果。

Ron Jeffries 举了一个例子，解释了在任务板上，什么时候任务卡片应该流转回上游工序：

[…] 如果任务又回到了原来的那位本应该搞定它的负责人的手上，那么把任务回退到前一步工序是一个不错的建立工作模型的方法。

不管你用哪种方法， Adam Sroka 认为你的看板应该反映现实情况，而不是一些理想状态：

我们要为正在采用的步骤建立模型，而不是去给设想中的步骤建模，这一观点是很微妙的，却也非常重要。对我来说，这是今年夏天我参加了 David 主讲的研讨会后，对看板最深刻的理解。可视化你在做的事情，随后，引入清晰的 WIP 限制，不断改进，等等。 对我而言，看板很适用。我也有 XP 的背景，我把流动可视化（visualizing flow) 看成一种委婉的引入改变的方式。我过去常常在第一天就想做很多改变，现在我意识到，我可以通过帮助大家诚实地面对他们正在做的事情来轻松地做到这一点。

查看英文原文： Should We Move a Failed Story Back?