私たちのチームでは、すべてのタスクのステップは常に同じ開発者によって行われます。つまり、タスク1の場合、Aさんは設計、開発、およびテストを行います。タスク2の場合、Bさんは設計、開発、テストなどを行います。この場合、かんばんを使用するのは理にかなっていますか?
プロセスを少し変更して、かんばんを引き続き使用することをお勧めします。
Person A does design Person B does design
Person B Reviews A's Design Person A Review's B's design
Person A does development and Person B Does Development and Initial Testing.
initial testing
Person B QA's person A's work Person A QA's Person B's work.
Chadが指摘したように、すべてのタスクを1人の開発者に任せることは、初期段階ではなく、プロジェクトのメンテナンスが必要になる将来の災害のレシピです。
ある程度、「…状況次第」と答えなければなりません。個人的には、フィル博士の「それはあなたにとってどのように機能していますか?」から始めるのが好きです。
あなたを軌道に乗せるためのいくつかの基本的な「バンパー」があります。つまり、ベストプラクティスやかんばんのプラクティスを意味します。
他の人が述べているように:ベストプラクティスは、開発者が自分のコードをテストしないことです。私は誰もがそれに同意すると思います。
しかし、もう1つは、WIPを減らし、コードをDONEに移動することです。アジャイルでは、「開発が完了した」というようなことはありません。コードは、開発、テスト、承認されたときに実行されます。それ以外のものは「進行中」です。
かんばんはすべてVALUE FLOWについてです。多くの「進行中の作業」があるのとは対照的に、それは「作業を成し遂げる」ことに焦点を合わせることを強制します。したがって、チームは作業を群がらせることを強くお勧めします。
上記の設計、レビュー、開発、テスト、承認の各ステップでは、開発に多くのステップが含まれる可能性があり、その一部は異なる人が同時に作業できるという事実を見落としています。 (すべての場合ではありませんが、許可されています)
私のチームに、ジョブをシリアルに実行する必要があるシングルスレッドプロセスと、ジョブを同時に実行できるマルチスレッドシステムとの違いを指摘したいと思います。開発者は、そのアナロジーを使用して処理能力の違いを簡単に理解しているようで、次のステップで彼らを導くのに役立ちます。
かんばんの指標には、サイクルタイムとタッチタイムが含まれます。サイクルタイムは、作業が開始されてから完了するまでの合計時間です。タッチ時間は、それを完了するのにかかった時間であり、タスクに触れるすべてのリソースの合計作業量である可能性があります。
目的は、可能な限りあらゆる方法でバリューフローを増やすことです。これにより、効率が向上し、スループットが向上することを示すこれらの指標が減少します。
したがって、プロセスをマルチスレッド(スウォーム)してサイクルタイムを短縮する方が効率的です。
例:タスクには、10ステップで20時間の作業があります。 1人が1日8時間、各タスクを問題なく連続して実行する場合、ジョブは2。5日で完了できます。サイクルタイム= 2。5日、タッチタイム= 20時間。
同じタスク、均等に群がった。 Dev 1は10時間の作業を行い、Dev2も同じことを行います。サイクルタイム= 1。5日、タッチタイム= 20時間。
タスクは、2。5日と比較して1。5日で承認する準備ができています。
したがって、あなたの例では、あなたが説明したケースでかんばんを使用することは理にかなっていますが、あなたが説明したプロセスは、効率と品質を向上させるために改善される可能性があります。
*誰かが私の論理に欠陥を見つけたら私に知らせてください!