最小限のかんばんのようなシステムには、カード用に3つの場所があります。「実行」、「進行中」、「完了」私がウェブでスクラムとかんばんを見たように、それは多分5つか6つのカテゴリーです。
かんばんおよびスクラムJIRAボードのカテゴリの一般的なオプションにはどのようなものがありますか?
カンバンを想定すると(答えはスクラムプロセスにはあまり関係がないと思います)、使用するレーンは組織の懸念事項、およびおそらく完了の定義に依存します。開発の問題だけでなく、組織やビジネスの問題に取り組み始めると、物事の明らかな必要性が見えてくるでしょう。
私の現在の組織では、「承諾の準備」、「リリースの準備」(別名:承諾)、および「リリース」がそこにあります。私たちは、製品所有者がストーリーを承諾することを重要なゲートであると考えており、それが常に即時のものであるとは限らないためです。ビジネスに関するPOの他の義務に応じて。継続的な展開メカニズムはまだ整っていないため、リリースイベントの一部となる必要のあるもののためのレーンもあり、それに関連して私たちの一部の作業があるかもしれません。次に、主に進捗状況を認識するために「解放」しました。
別の組織では、カンバンは主要なプロセスではありませんでしたが、規制の厳しいバイオテクノロジービジネスに対応していたため、複数の組織ゲートを介して動く多くの可動部品に対処する必要がありました。一部の項目は「進行中」、つまり開発者の手にかかっていましたが、「テクニカルライターレビュー」、従来のソフトウェアテストチームによる「テスト」作業、および品質保証を通過する必要がありました。 (区別は業界標準の問題でした。従来の製造では、QAはプロセスが文書どおりに機能することを保証しますが、「テスト」は品質管理の問題です。条件についてFDAの承認を得たため、ソフトウェアはQAプロセスを通過する必要がありました。当初数年前にFDAに文書化されているように、文書化された適正製造基準に従っていることを確認しました)。つまり、言い換えれば、ソフトウェア組織は、継続的統合、自動化されたユニットおよび統合テストなどのアジャイル開発のための有効化メカニズムを実践しましたが、さまざまなビジネス上の制約により、レガシースタイルのプロジェクトを連想させる外部組織の懸念を調整する必要がありました管理。私たちの開発チームが複数の作業成果物(新機能、古い機能のリリース、複数のスクラム反復にまたがる組織的および技術的な問題への対処)を操作しようとしたとき、私たちは本質的にスクラムを放棄し、私たちが行っていることを可視化できるようにしました開発ではなく、すべてが完了したことを確認してください。私たちの仕事が外部の利益にあまり依存していなかったとき、私たちは再び従来のスクラムスタイルのプロジェクト管理を使用しました。
私が小さなチームで外部の利害関係者がほとんどいなかった場合、おそらく私のボードはかなりシンプルに保つでしょう。 「引っ張る準備ができている」、「進行中」、「プロダクションにリリースされた」はちょうどいい感じですが、プロダクションにリリースする前に製品の所有者が作業を確認するためにレーンを必要としても驚くことではありません。また、一部の組織では、顧客がどのように反応するか、または本番環境でどのようにスケーリングするかに関するデータが収集されるまで、すべての人が新しい機能を利用できないため、「In A/B」のようなレーンが表示されても驚くことではありません。テスト」または「ユーザーの10%にリリース済み」、「すべての顧客にリリース済み」が続きます。
また、「技術的負債」などの非出荷レーン項目もいくつかあり、ストーリーには不適切な承認基準が含まれている、以前の機能の他の既存の基準と矛盾している、またはカウボーイアップやおそらく無関係なコードを書く。そのような場合、問題が正常に機能している場合は、「保留中」というラベルの付いた短時間しかアクセスできないボックスがあります。
したがって、レッスンは単純です。チームが実際に何を必要としているかを理解し、それらのレーンを描画します。