スクラムでは、各スプリントの後にデモを作成できることは明らかです。
かんばんにはスプリントの概念がないため、デモを作成する方法がわかりません(間違っている可能性があります)。
かんばんでリリースする方法について教えていただけますか?
助けと時間をありがとう。
私が最後の仕事でかんばんを実装していたとき、リリースは次の3つの方法のいずれかになりました。
本当に、かなりオープンエンドでした。
かんばんは、作業の流れを管理し、進行中の作業を制限する方法を述べていますが、リリースの頻度については何も述べていません。ただし、製品の機能する統合バージョンを常に維持し、新しい機能が完了したと見なされたらすぐに追加する必要があるため、非常に要求が厳しくなります(完了、ボードの最後の列)。
頻繁に使用される概念は、「ケイデンス」があるということです。これは、この「準備完了製品」が取得され、実際にライブシステムに展開/出荷される定期的な間隔です。
ただし、スクラムで非常に明確な1つの概念がここでも役立つと思います。スクラムでは、各スプリントの最後に「出荷可能な製品の増分」(DONEの定義を確認)が必要であると明確に言われています。実際に出荷/展開するかどうかは、最終的にはビジネス上の決定であるため、開発プロセスの範囲外です。同じことがかんばんにも当てはまると思います。開発プロセスとその管理の範囲外のビジネス上の意思決定として実際に使用するかどうかに関係なく、いつでもすぐに統合できる製品を利用できます。
単一の定義はありません。通常、かんばんではMMF(Minimal Marketable Features)を追加します。これは、定義上、すべての機能が顧客に付加価値をもたらすため、すべての機能を個別にリリースできる必要があることを意味します。
これは、各機能を個別にリリースする必要があるという意味ではないため、さまざまなアプローチが見つかります(Davidはそれらのいくつかについて言及しています)。かんばんチームがタイムボックスアプローチの1つに従った場合よりも頻繁にリリースするのは、よくあるケースです。
かんばんのデモはオプションですが、クライアントがそれらを喜んで持っている場合は、すべての機能を個別にリリースする場合でも、展開時に機能をデモできます。理論的には、すべての機能が付加価値をもたらすため、このアプローチはうまく機能するはずです。
デモを「テスト中」から「リリース準備完了」に移行する条件にします。したがって、これはスプリントごとではなく機能ごとであり、機能の性質によってデモの性質が決まります。開発中のビジネスへの関与が大きければ大きいほど、これがとにかく問題になることは少なくなります。
簡単なデモを手配できるDODにサインオフステップを追加してみることができます。ただし、違いは、1対1のデモになるのに対し、スクラムスプリントレビューでは、デモはすべての参加者を対象としているということです。
リリースサイクルに関しては、以前の回答ですでに述べました。もう1点付け加えたいのですが、まだリリースされていないアイテムに制限があるかもしれません。たとえば、リリースの準備ができているボードに10個のMMFがある場合、リリースプロセスをその場で開始できます。
この方法は、ある意味でスループットを追跡するのに役立つ場合があります。