6

ソフトウェア開発管理にかんばん方式を使用した人はいますか？

私はかんばんを技術として評価していますが、実際にそれを実際に適用した人から、それがどれほど効果的であるかを聞いてみたいと思います。is-anyone-using-kanban、kanban-vs-scrum、apply-kanban-in-an-agile-teamのような質問を見たことがありますが、それらは私の懸念に対処していません。

私が特に興味を持っているのは：

  1. ボトルネックを動的に特定するという点で、クレームが実際に利点を提供しますか？
  2. 実際に実行するのは簡単ですか、それとも管理する必要のあるロジスティック上の課題がありますか？
  3. 多くの並行作業ストリームと多くの開発者がいるプロジェクトチームにうまく対応できますか？
  4. クリティカルパス分析（MS Projectで実装されている）とどのように比較されますか？どのように異なりますか？
  5. かんばんを適用すると、他にどのようなメリットがありますか？

ありがとう。

4

6 に答える 6

3

かんばん方式は、何よりも継続的なプロセス改善の触媒です。これは、簡単な修正や一連の固定された手順/プラクティスではありません。この方法には、David J Anderson の最近のブログ投稿で説明されているように、いくつかの基本原則とコア プロパティがあり、継続的なプロセス改善への道を導くことができます。あなたの質問に:

  1. かんばん方式自体は、ボトルネックを特定しません。プロセスにストレスを与えるプロセスに進行中の制限を実装すると、最終的にプル システムが作成され、プロセスのボトルネックを特定しやすくなります。視覚的なかんばんボードや累積フロー図などのツールは、プロセスのボトルネックを特定するのに役立ちます。

  2. 基本原則とコア特性を適用し、スタミナ/忍耐/献身があれば、それほど難しくありません. すべての組織変更と同じように変更プロセスを管理する必要がありますが、かんばん方式は小規模で脅威のない変更を行うように設計されています。

  3. はい、これには多くの文書化されたケースがあります。

  4. かんばん方式は、将来の配送を計画および予測するための特定の方法を識別しません。David J Anderson は、制約理論のバックグラウンドを持っています。そして、私が読んだほとんどの文章で TOC をモデルとして使用しています。MS Project スタイルの大規模な事前計画を使用することと、多くのかんばん実装で使用される経験に基づく計画を使用することの実質的な違いは、大きな違いだと思います。プロジェクトの開始時に MS Project で設計されたプロジェクト計画を使用する場合、実際の問題領域についてほとんど知らず、仮定を立てます。これらの仮定に基づいて、計画を立てます。クリティカル パスは、これらの仮定に基づいて計算されます。安定したかんばんシステムを使用し、モデルとして TOC を使用すると、クリティカル パスに制約/ボトルネックを「のみ」配置するように計画します。制約を通過する作業の過去の変動性を考慮し、取りたい適切なリスクでボトルネックの周りにバッファーを作成します。

  5. かんばん方式の主な利点は、継続的なプロセス改善の触媒となることです。それはあなたが得たものから始まり、脅迫的ではない変更を加えます。かんばんはMade to Stickの方法

于 2010-12-12T20:58:21.807 に答える
2

PC 展開にかんばんを適用するという記事では、チームは次の機器を考慮する必要があります。

  • 160 台の新しい PC を導入
  • 40台の新しいラップトップを導入
  • 120 台の PC と 10 台のラップトップを更新して再配置

... かんばんを使用して短期の機能プロジェクトを管理することを検討しています。この例では、Kanban を使用して透明なプロセスを作成し、多くの複雑なステップを通じて機器の流れを追跡することに焦点を当てています。ソフトウェアの追跡、複雑なプロセスとトレーニング、または労力の重複に追加コストが発生することはありません。展開プロセスの均一性または品質の向上は、トラブルシューティングと修復時間の効率を向上させるだけでなく、ソフトウェアおよびライセンス標準への文書化された高レベルの準拠を保証するのにも役立ちます。

上記のページには、カンバン適用へのリンクもあります...

于 2009-12-17T19:26:04.923 に答える
1

私もまだ経験が浅いですが、少しでも参考になれば幸いです。1 & 4: かんばんボードと CPM などの他の手法との主な違いは、かんばんボードを正しく実装すると、進行中の作業制限を課す必要があることです。これにより、キャパシティがある場合にのみ新しいアイテムがワーカーによって受け入れられるため、プル システムが作成されます。これは、タスクが事前にワーカーに割り当てられる (つまり、プッシュされる) MS プロジェクト タイプのプロジェクトとは異なります。

プロセスのある段階で作業項目がキューに入れられるため、プル システムのボトルネックを特定するのははるかに簡単です。プッシュ システムでは、作業がシステムを通じてプッシュされるため (「完了」しているかどうかに関係なく)、ボトルネックを見つけるのは困難です。

プル システムのもう 1 つの利点は、予測ではなく、実際の結果 (リードおよびサイクル タイム) に基づいて作業タイムラインを開始できることです。はい、ストーリーのサイズと粒度はこれに影響しますが、累積フロー図などの手法を使用すると、これはそれほど重要ではなくなります。

2: ほとんどの実装は非常に単純であり、そこにこの手法の強みがあります。技術のロジスティクスに問題がある場合は、間違っていると思います。素敵な「キックスタートの例」については、こちらをご覧ください。

于 2009-12-17T12:36:30.850 に答える
0

ソフトウェアでかんばんを使用した経験は特にありませんが、製造の観点からは慣れているので、実装に興味がありました。あなたのリンクを読んで、考えられる問題として私を驚かせたのは、作業単位（機能、ストーリーなど）の同じサイズについての根本的な仮定のように感じたものです。物事を「ストーリーサイズ」に保つことは良い目標ですが、多くの場合、大きなストーリーと小さなストーリーが混在しているため、パイプラインの少数の制約は人為的なものに見えます。ボトルネックを浮き彫りにすることが目標であれば、スタンドアップとスプリントの計画と回顧展で十分だと思います。優先順位付けを容易にすることが目標である場合、タイプごとにタスクの数に制約を課すことはできないと思います。

私はそれがどのような価値を付加するのか実際にはわからないと思います。そうは言っても、私はそれを試して、うまくいくものを採用することに害はないと思います。

于 2009-12-16T20:17:52.333 に答える
0

1. ボトルネックを動的に特定するという点で、実際に利点が主張されているか?

これは私の経験です。利用可能なキャパシティを反映するように WIP 制限を設定することにより、そのキャパシティを利用する必要があるが、それが利用可能になるのを待たなければならない作業がある場合、作業のキューがボトルネックの前にバックアップされるため、それが表示されます。これは、QA に見られる可能性がないにもかかわらず生産を続ける上流の開発チームと過労の QA チームがある場合に発生するのを見てきました。これに対して私たちが取った解決策は、開発者の何人かを QA チームに貸し出し、ボトルネックの緩和を支援することでした。

2. 実際に実行するのは簡単ですか、それとも管理が必要なロジスティクス上の課題がありますか?

これは、適用するコンテキストに固有の多くの要因に依存します。かんばんの大きな強みの 1 つは、現在の作業方法から即座に「オール オア ナッシング」の変更を必要としないことです。David Anderson の「Kanban」の本の「A Recipe for Success」の章は、「Focus on Quality」から始めて、変化に取り組むための優れた方法を提供します。

3. 多くの並列作業ストリームと多くの開発者を持つプロジェクト チームにうまく拡張できますか?

私が最初にそれを使用したプロジェクトでは、最終的に 17 人の開発者のチームになり、4 人の QA チームも私たちのチームに移動しました。また、Kanban を使用してモデル化した多くの外部依存関係もありました。

4. クリティカル パス分析 (MS Project に実装されている) と比較して、どのように違いますか?

使用したことがないため合格

5.かんばんを適用することで得られるその他の利点は何ですか?

たくさんありますが、私が強調したいのは、チームと利害関係者やチーム外の他の人々の両方と議論し、仕事を進めるのに真に役立つ指標を提供するということです. 具体的には、「スループット」と「サイクル タイム」を使用すると、作業がいつ完了するかのキャストの確率を得るのに役立ちます。

于 2012-10-29T18:04:24.443 に答える