私たちのチームでは、かんばんボードをソフトウェア開発の組織ツールとして使用することを評価しています。開発フェーズは 5 人のチームで約 6 か月かかります。クライアントと合意したすべての機能要件、ビジネス ルール、ユース ケース、つまり巨視的な要件を入力として取得します。ストーリー内のこれらのルールをかんばんボードの「アトミック」プロセス単位に変換します。かんばん自体は、パフォーマンス評価ツールおよび進捗ロードマップとして使用されます。かんばんは、各段階で一定量のストーリーを持つように「規定」していますが、ソフトウェアが新しく複雑であるため、「ストーリー」はおそらく数百になるでしょう。開発は賢明な動きではありません。
この場合のベストプラクティスは何ですか?
まず、バックログの制限を設定しているチームはほとんどありません。かんばんは、仕掛品 (WIP) の制限をアドバイスします。バックログの項目が「進行中」と見なされることはめったにありません。
第二に、多かれ少なかれ、プロジェクトの範囲を知っていることを考えると、バックログのアイテム数を人為的に制限することを自分自身に強制することはあまり意味がありません.
同時に、バックログに数百のアイテムを入れても意味がないというあなたの意見は正しいです。ボードは過密になり、その有用性は大幅に低下します。
バックログを整理するための典型的な戦略は、次のような場合です。
壮大なストーリー/機能をバックログに保持し、作業を開始したときにのみ詳細なストーリー/タスクに分割します。こうすることで、開発段階の詳細なタスクを処理できる一方で、項目がはるかに少なくなります。
アプリの同じ部分の一部になるストーリーを積み重ねる。すでにスコープを分割している場合、この情報を人為的に隠しても意味がありません。ただし、接続されている、または同時に実行される作業項目を積み重ねることはできます。バックログがきれいになり、アイテムの構築を開始すると、それらを完全に簡単にアンスタックできます。
ステージング バックログ。開発がどのように進むかの大まかな計画がある場合は、バックログのいくつかの段階を持つことができます。構築するすべての機能を格納するボックスである初期のもの (ボードに取り付けられた物理的なボックスであってもかまいません) と、次の期間のみ動作することを示す後期のものです。このようにして、ボード上に表示されるアイテムが少なくなりますが、技術的にはすべての作業がそこにあります。
もちろん、これらすべてのアイデアを混在させることは可能であり、合理的と思われる場合はいつでも推奨されます。
ところで:このプレゼンテーション(スライド 21) では、これらのテクニックのいくつかを視覚化して見ることができます。
私は反対しなければなりません: バックログの制限は可能性です。おそらく入力列にはありませんが、たとえば、プロセスにいくつかの優先順位列がある場合、最も優先順位の高い列に制限が含まれている可能性があるため、WIP はそのようなペースを維持できず、そこでハングアップするため、多くの優先順位の高いタスクにプッシュすることはできません。 .
Henrik Kniberg は、Kanban に関する彼の無料の本の中で、WIP 制限をバックログに設定することが、最も重要な機能に最初に集中するのにどのように役立つかを説明しています。
これは特にプロダクトオーナーにとって良い戦略だと思います。バックログには、次の期間に開発されるストーリーのみが含まれていますが、他のストーリーはマインドマップまたは「ウィッシュリスト」にある可能性があります.
