Eric Willeke在思考：任務看板上的那些沒有通過測試的用戶故事，該怎么處理呢？應該把它回退到“開發”狀態，還是保留“測試中”的狀態？他提出了一些不同的方案：

● 一個方法是把開發和測試狀態合并為“完成”狀態，這樣就不存在狀態變化了。團隊通過協作，分解出一系列小到能分配給單個開發人員/測試人員的子任務，但直到每個人都同意所有子任務都完成了，這個用戶故事才算完成。

● 另外一種方法是把故事移到測試狀態，需要的話再移回去，如此反復。如果這就是你日常工作中的真實情況，那么你應該以此建立模型。

● 還有一種方法是在某項上放置一個“缺陷”標志(或者缺陷卡片)，但是在測試過程中當開發人員來幫忙修復缺陷的時候，標志還會一直放在那里，直到所有問題都被修復。如果這種情況更符合你的實際工作，你更應該以這種方式建立模型。

Thierry Henrio提出了不同的方案，他從精益制造行業借鑒過來了“紅卡箱”(red bins)的概念：

我是這么做的：

● 每個狀態欄都準備一個專用的紅卡箱， 放在看板的底部靠上方

● 當某個狀態欄的任務出現了問題，就把紅卡箱移過去

● 我們有30分鐘解決問題，消滅紅卡箱

這套機制對于鼓勵團隊高效處理問題還是很有效的。但當問題出現在上游工序，那么30分鐘就不夠了，這種方法的效果也大打折扣。

專用的紅卡箱相比紅色標志，有更加強烈的可視化效果。

Ron Jeffries舉了一個例子，解釋了在任務板上，什么時候任務卡片應該流轉回上游工序：

[...]如果任務又回到了原來的那位本應該搞定它的負責人的手上，那么把任務回退到前一步工序是一個不錯的建立工作模型的方法。 不管你用哪種方法，Adam Sroka認為你的看板應該反映現實情況，而不是一些理想狀態：

我們要為正在采用的步驟建立模型，而不是去給設想中的步驟建模，這一觀點是很微妙的，卻也非常重要。對我來說，這是今年夏天我參加了David主講的研 討會后，對看板最深刻的理解。可視化你在做的事情，隨后，引入清晰的WIP限制，不斷改進，等等。 對我而言，看板很適用。我也有XP的背景，我把流動可視化(visualizing flow)看成一種委婉的引入改變的方式。我過去常常在第一天就想做很多改變，現在我意識到，我可以通過幫助大家誠實地面對他們正在做的事情來輕松地做到 這一點。

總結

以上是生活随笔為你收集整理的java没通过测试_我们应该把没有通过测试的故事回退到“开发”状态吗的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。