私は基本的なかんばんボードを持っており、開発者とテストの間で引き継ぎがあります。
----------------------------------------------------
| To Do | Ready | Develop | Test | Done |
| | | In Progress | Done | | |
ボードにいくつかの制限を設けたと仮定します。アイテムがテストに失敗した場合はどうすればよいですか？実際に間違いを修正するのはテスターの仕事ではないので、私が見ているように、「完了」に進む方法はありません。テスターに「Ready」に戻してもらいたいのですが、それで限界を超えてしまいます。テスターがアイテムを「準備完了」から「実行」に降格した場合、テスターは基本的にPOの優先順位付けを元に戻します。
これまでの私の魂は、「準備完了」の制限を超えて大丈夫であり、テストに失敗したアイテムにマークを付け、それらを優先することです。
他のアイデアはありますか？
Ready状態をRe-OpenとReadyに分割します。この場合、手直しが必要なアイテムと新しいアイテムを明確に区別できます。通常、再作業が必要なアイテムを最初に処理する必要があるため、開発者には、何が新しく、何がテストフェーズから返されるかが明確になります。
以下を含むいくつかの可能な解決策（他にもあると確信しています）：
1）フラグが立てられたアイテムが（何らかの理由で）優先順位の問題として解決されることをチームが期待して、チケットにフラグを立てます。
2）チケットを後方に移動します。（しかし、取締役会は実際にプロジェクトの状態を反映していますか？変更を解消しますか？検討する価値があります。）
3）新しいチケットを作成します。おそらく、彼らのための特別なスイムレーンまたは別の色。
それらは相互に排他的ではありません。＃1（私のデフォルト設定）に固執しても、アイテムが現在の状態でもリリースする価値がある場合は＃3が理にかなっており、バグではなく重大な誤解があれば＃2が理にかなっている可能性があります。
さらなる考察：開発者のWIP制限を下げる、および/または開発者とテストにまたがる制限を追加することで、開発者がプロセス全体を通じて作業をサポートするようにさらに促します。
それはあなたが何を達成したいかによります。1つのオプションは、失敗を非常に深刻に受け止めて、バグを修正するために現在の作業項目をバウンスすることです。
私はあなたの解決策がうまくいくと思います（失敗したマークを本当に明白にします）。
そして、おそらく本当の答えは、しばらく試してみて、それがどのように機能するかを確認することです。
返信で説明する内容は、正規のかんばんとは大きく異なると確信しています。つまり、それは非常に議論の余地があるかもしれません。
それでもなお、他のアイデアを求められたので、異端的な視点にも興味があるのではないかと思いました。ケースに合わない場合は、概念実証として使用してください。
まず、私が使用している比喩を描写するための簡単な概要。あなたがここで見つけることができるビデオからのこの短い抜粋を考慮に入れてください
「少なくとも2つの列（たとえば、DoingとQAですが、ここでは名前は重要ではありません）を表すボードが、プログラマーが実行するように呼び出されたアクティビティを表しているとします。この状況を想定します。バックログのタスクBと実際に進行中のタスクA。タスクAはQAに移動します。プログラマーは、タスクAに取り組むか、タスクBを実行に移して作業を開始する必要がありますか？マルチタスクは悪であり、プログラマーはタスクAとタスクBの両方に取り組むべきではありません。
正解は次のとおりです。最初にタスクAに取り組みます。かんばんはプルシステムであり、これを非常に明確にします。ただし、かんばんがなくても、タスクAはビジネスバリューに近いため、QA列に駐車して、できるだけ早く完了列に移動しないでください。廃棄物は排除し、備蓄しないでください。
これは疑問を投げかけます：DoingColumnに空きスロットはありますか？別のプログラマーがタスクBを進めることができますか？
質問は見当違いです。開発者が1人だけの場合、答えはノーです。プログラマーが利用できないため、事実上の仕掛品の実行制限を0に減らす必要があります。2人の開発者の場合、正しい質問は「他の開発者は利用できますか？」です。
事実は次のとおりです。仕掛品制限は空きスロットの尺度ではありません。利用可能な開発者の数はです。
私が想像しようとしたボードは、別の原則を使用しています。磁気ステッカーのような、単一のプログラマーの一般的で個人的なカスタマイズされた表現です。それを顔と呼びます。プログラマーは、彼がその問題に取り組んでいることを伝えるために彼の顔をタスクに置きます。各プログラマーには1つの面しかないため、プログラマーは複数のタスクにコミットすることはできません。仕掛品の制限は、使用可能な空きスロットの数の尺度ではありません。使用可能なチームメンバー、つまり、タスクのない面は、適切な尺度です。
ルールは単純です。各チームメンバーの顔は1つだけで、1つのタスクにそれを置くことができます。
しかし、結果は些細なことではありません。Facesを使用すると、誰が誰と協力しているか、チームがどのようにクラスタリングしているか、特定の問題について誰に質問できるかを簡単に確認できます。「」
言い換えれば、私が思うのは、WIP制限は、特にすべての列のWIPの合計が開発者の数よりも多い場合、列に入れる必要のある項目の最も適切な尺度ではない可能性があるということです。つまり、実際に信頼できるスロットです）。
同じことがあなたのケースにも当てはまると思います。QA列にかんばんアイテムの不合格テストがあります。私にとっては、doing列でそれを後方に移動しても問題はありません。失敗した項目に取り組んでいた開発者は、引き続きそれに取り組んでいます。実際には、空きスロットがあります。
Doing列のWIP制限がワークフローをブロックする理由がわかりません。そうでなければ、あなたは何をすべきですか？コラムに書いた任意の数字を尊重するために、開発者を別のタスクに移動する必要がありますか？WIP制限を放棄して違反することにした場合、その制限の意味と適切性および適用可能性に疑問を投げかけるべきではありませんか？
つまり、開発者がタスクにコミットしている限り、タスクを元に戻します。
私が過去にそれを行った方法は、失敗したチケットを「作業中」に戻すことです。多くのチケットがテスト段階で失敗することが予測されるため、「作業中」で許可されているチケットの数と実際にそこに入れた数にそれを組み込む必要があります。
たとえば、開発者ごとに「作業中」のチケットを2つ許可し、それらのスポットの1つを失敗したチケット用に永続的に予約することができます。
アイテムがテストの範囲内にあり、それを一方向で見る場合、「やること」列の他の何よりも優先度が高いため、その列の一番上に配置して、一番下のアイテムをぶつけてしまう可能性があります。
または、テスターはアイテムをPOに戻し、優先順位を付け直すことができますか？つまり、基本的にToDo列から再開しますか？それがPOの目的です-彼らは修正を取得することがどれほど重要かを決定します。
[進行中]列に2つのサブ列が必要だと思います。1つは「積極的に取り組んでいる」必要があり、もう1つは「待機中」またはあなたがそれを呼びたいものである必要があります。テストが失敗した場合は、待機に戻します。
テストから戻ってきた数を測定したい場合（これは良い考えです）、それにサブ列を割り当てます。
何をするにしても、ボードの「進行中」エリアの下に配置します。
私がこれを処理する方法は、ストーリーをテストに残すが、失敗したことを示すフラグを立てることです。テスターはWIP制限を超えずに新しいアイテムをプルすることができないため、テスト列のボトルネックになります。これにより、チームはそのアイテムに群がってそれを実行します（つまり、問題を修正して再テストします）。
次の質問をする価値があります。開発を行うのは誰の責任ですか？テストするのは誰の責任ですか？テストが失敗した場合に再開発するのは誰の責任ですか？うまくいけば、あなたの答えは「チーム」でした。