0

カンバン ボードの基本的なフローを考えると、次のようになります。

| Backlog | Dev | QA | Deploy |

本/記事/プレゼンテーションを読んだ後、大まかに次のように変換されました

Business  -> | Backlog | Input |     Development    |         QA         | Deployment | Closed |
Marketing -> |         | Queue |--------------------|--------------------|    Queue   |        |
Other   ->   |         |       | Queue | WIP | Done | Queue | WIP | Done |            |        |

だから私が理解できない質問：

  1. バックログ & 入力キュー & 開発キューの関係。PM は、そのリリースのバックログから MMF に優先順位を付け、それらを入力キューに移動します。dev (WIP 制限に基づく) は 1 つを取り、作業を開始します (WIP 列)。Dev Queue は何に使用されますか? PM が Backlog から Dev Queue に移動し、開発者が Dev WIP に移動する必要がありますか、それとも PM が Backlog から Input Queue に移動し、開発者が 1 つを取得して Dev WIP に移動する必要がありますか? かんばんの例で、バックログ、入力キュー、および開発サブキューを持つことについて話している理由がわかりません。それぞれに独自の目的がありますか?

  2. 開発者は完了/解決済みの作業項目をどこに移動し、完了と次のキュー列の関係は? QAが不要な場合はどうなりますか? たとえば、開発 WIP が完了したら、それを Dev Done に移動できます。QA はそこから QA WIP にプルします。または、Dev WIP から QA Queue または Deploy Queue へ (QA が不要な場合)。最初のケースでは、説明が技術的すぎたり曖昧すぎたりしても、QAer は Dev Done 列のすべてのチケットを理解して確認する必要があります。2 番目に Dev Done がバイパスされ、QA はデプロイの制御/監視を失います。また、デプロイ キューまたはクローズドが必要ですか? CI のおかげで、デプロイはワンクリックで完了しますが、すべての開発タスクを実行し、クローズドに移動する前にリビジョン番号をデプロイされたばかりのものに一致させるのは負担のように聞こえます...

何か案は？または、実際のかんばんボードとそのフロー設定の詳細な例を知っているでしょうか? 私は実際に存在するフローを計画し、それを時間の経過とともに進化/改善することになっていることを知っています (ボトルネック/問題の出現に対する反応としてのカイゼン)。しかし、新しいチーム/プロジェクトの場合、完璧なフローは何でしょうか?

4

6 に答える 6

3

複雑にしないでおく。私見あなたの実装は複雑すぎます。あなたの投稿を 3 回読みましたが、まだすべてを理解できていません ;) 次の Web ページを確認してください。

http://www.limitedwipsociety.org/2009/11/16/kanban-example/

http://blog.crisp.se/henrikkniberg/2009/06/26/1246053060000.html

于 2010-07-06T13:21:21.597 に答える
2

理想的なボードはプロジェクト/チームに依存するため、新しいプロジェクトであっても、答えは 1 つではありません。チームでプロセスについて話し合い、簡単なことから始めて、定期的に見直してください。しかし、私のものは私の投稿かんばんに一言で説明されています。

プロセスでなんらかの引き継ぎが指示されない限り、「完了」列と「キュー」列の両方は必要ありません。項目を列間で移動するのは、「押す」ではなく「引く」ことを目指します。

于 2010-07-06T12:35:51.150 に答える
2

完璧な流れはありません... 既存のチームがある場合は、現在のプロセスから始めてください。既存のチームと新しいチームの両方で、シンプルに保ち、実用的にしてください。

いくつかの場所で「完了」サブ列を使用し、作業中サブ列と完了サブ列に共通の WIP 制限を使用します。このようにして、プル動作を有効にし、ステップ全体の WIP を制限します。

キューの一般的な使用法は、フローを最適化するために、ボトルネックの前にあります。ボトルネックでない人は学習と改善のためにスラックを使用する必要がありますが、ボトルネック (特定できれば) はチーム全体のパフォーマンスを制限します。

最後の「完了」列については、チケットに関しては実用的です。ただし、列名に関しては、ボード上でより具体的に説明します。「クローズ」とは、本番環境またはテストサーバー上でのことですか? それを列名に入れるだけです。

于 2011-02-07T00:45:55.460 に答える
1

あなたの2つの質問は実際には同じです。簡単に言えば、dev キューと入力キューは同じものである必要があります。つまり、どちらか一方が必要ですが、両方は必要ありません。dev done と qa queue も同じです。同じです。キューまたはアップストリームの完了列のポイントは、実行待ちの作業があることをダウンストリーム フェーズに示すことです。これらの列は、ウィップ制限を適用するためにも使用されます。

私のアドバイスは、新しいプロジェクトであっても、チームの現在の作業方法にマッピングし、そこからカイゼンを使用することです。かんばん (およびスクラム) の要点は、作業方法を説明することではなく、問題を自分で見つけてシステムやプロセスを変更できるように、物事を目に見えて明確にすることです。これは経験的なデータに基づいて機能するため、進むべき方向が事前にわかっているとは限りません。ツール/テクニックとしてのかんばんは、試行錯誤を繰り返して物事を可視化することで、その方向性を示すために存在します。

于 2010-07-06T12:43:44.797 に答える
1

"Ready" queues (those that you call "Input Queues") are for push flow. "Done" queues (output) are for pull flows.

Most systems have both push and pull. Push will happen where there are different organizational semantics between work steps. For example, the movement of work items between a product backlog and the input queue for the team is usually a push movement. Work may be then pulled from the input queue.

It's rare that you'll have a single work step that will have both an input and an output queue.

于 2010-07-13T04:20:38.227 に答える
1

バックログ & 入力キュー & 開発キューの関係。PM は、そのリリースのバックログから MMF に優先順位を付け、それらを入力キューに移動します。dev (WIP 制限に基づく) は 1 つを取り、作業を開始します (WIP 列)。Dev Queue は何に使用されますか?

わかりませんが、最初の基本的なフローを複雑なものに変えました:)使用した参照を投稿する必要があるかもしれません。しかし、私の観点からは、それらは冗長に見えます (別のコンテキストにあるわけではないかもしれませんが、私はそれらの必要性を感じていません)。

開発者は完了/解決済みの作業項目をどこに移動し、完了と次のキュー列の関係は?

WIP アイテムがDev-Doneであれば、QA はQA-WIPにプルするはずだと思っていました。私はこれらすべてのキューを理解していません。上記と同じ答えなので、私には冗長に思えます。

何か案は？

そうではありませんが、物事を単純化します（実際には、基本的なフローにほとんどフォールバックします）。この前の回答で説明したものよりもはるかに複雑にする意味がわかりません。OK、この回答はスクラム ボードに関するものであり、純粋なかんばんではありませんが、反復を削除しても機能します。

あるいは、実際のかんばんボードとそのフロー設定の詳細な例を知っているでしょうか?

Kanban vs Scrum、One day in Kanban LandおよびKanban and Scrum - Henrik Kniberg による実用的なガイドをご覧ください。素晴らしいもの。

(...) しかし、新しいチーム/プロジェクトをやめる場合、完璧な流れは何でしょうか?

完璧な流れはありません。私たちのチームの完璧な流れはあなたのものではありません。しかし、上記のすべてのリンクからいくつかのアイデアが得られます。ただし、単純にしてください。過度に複雑にする必要はありません。

于 2010-07-06T12:50:44.300 に答える