我有一個基本的看板板，與開發者和測試之間的切換：我應該如何處理未通過測試的看板項目？
----------------------------------------------------
| 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