かんばんを使用する場合、チームはいつ要件について話し合いますか？

私はかんばんについて少し読んでいますが、要件のトピックについて少し混乱しています。

現在のプロジェクトでは、スクラムを使用しています。スプリントの最初に、BAがストーリーのウォークスルーを行い、彼女ができる限りそれを説明するセッションがあります。次に、その話を取り、レビューし、話し合い、BAに次のスプリント計画セッションのための質問を準備します。次のセッションでは、BAがすべての質問に答え、セッションは要件を理解した（ほとんどの場合）ことで終了します。

次のステップは、技術設計を作成し、ソリューション/ストーリーを開発することです。

かんばんに関​​して、私が読んだすべては、かんばんにはスプリント計画がないことを示唆しています。私の質問は、技術の要員とビジネスマンが一緒に座って（カンバンで）ストーリーの要件について話し合うときですか？プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供しませんか？

スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はどのようにストーリーを理解するのかはわかりません。

カンバンには、スクラムのようにスプリントやスプリントプランニングの概念がないことに間違いはありません。それはより無駄のない方法論だからです。より多くのことがジャストインタイムで行われます。

計画活動のスケジュール方法を決めるのはあなた次第ですが、できる限り作業の開始時に近づけることをお勧めします。これは、チームに組み込まれたすべての主要な利害関係者の代表がいる場合に最も効果的です（これにより、スクラムがより効果的になります）。

この図は、規律のあるアジャイルデリバリーに基づいており、無駄のないソフトウェアプロセスを図で表したものだと思います。

デイリースタンドアップとスプリント計画のイベントは、調整ミーティングと補充モデリングセッション全体でキャプチャされます。調整会議はスクラムからの毎日のスタンドアップのようなものであり、補充モデリングセッションはバックログの精緻化とスプリント計画のようなものです。ただし、チームで問題がなければ、要件に関する議論を調整会議に取り入れることは問題ありません。

リーンプロセスのほとんどのことと同様に、これはジャストインタイムで発生します。タイムボックスはなく、スクラムのように特定のケイデンスでイベントが発生することはありません。チームと利害関係者に価値を追加するときに作業を行います。

規律あるアジャイル配信のコンテキストでモデル化されたスクラムに基づくプロセスの図解表現と比較できます。

2-4週間のスプリントに制限するのではなく、最初に計画を立て、毎日立ち上がって、最後にレビューと振り返りを行うのではなく、無駄のない方法論により、利害関係者が適切であると考える場合はいつでも、デモンストレーション、調整、回顧会議を実施します。 。

かんばんは、作業のバックログと進行中の作業（WIP）を管理するためのガイダンスを提供します。かんばんは一般的にそれらについて沈黙しているので、他の活動を正確に実装するために他の手法や方法に頼ることができます。

あなたはスプリント計画会議がスクラムで何をしているのかを少し誤解/誤解しています。それがあなたの混乱の原因だと思います。スプリント計画会議は、通常、ストーリーの詳細を検討するには不適切な場所です。見積もりに大きな影響を与える未解決の問題がないことを確認するためのいくつかの最終的な微調整と迅速な実行を除いて、検討されるストーリーはほとんど準備ができているはずです。そこから、スプリント計画は、缶に書かれていることを実行します。これは、次のスプリントで何が行われるかを計画します。スプリントがない場合は、スプリント計画は必要ありません。

では、ストーリーの詳細はいつ具体化されるのでしょうか。通常、バックロググルーミングを介して、または以前のスプリント中の継続的な通信で。ここでの目標は、十分に明確にすることで、合理的に信頼できる見積もりを与えることができるようにすることです。これは、事前にすべての詳細を検討する必要はありません。どれだけ試しても、実装中に常に疑問が生じます。スクラムの目標は、実装中に出てくる質問を比較的軽微なものにすることです（基本的に、推定値に影響を与えないほど十分に小さい）。

かんばんでは、見積もりはオプションです。見積もりを行う場合は、ストーリーが取り上げられる前に、見積もりを算出するために話し合うという意味で、スクラムと同様のことを行う可能性があります。推定を行わない場合でも、実際の動作は似ていますが、話が始まるまでは話をしません。

私の経験では、私は通常、メイン開発にスクラムのようなアプローチを使用し、その後、メンテナンスフェーズをよりカンバンアプローチに切り替えたチームで作業しました。メンテナンスフェーズでの作業は散発的である傾向があり、ストーリーはab initioとスケールがより明確に定義されます。メインの開発フェーズでは、ストーリーは多くの場合、高レベルで始まり、スプリントに受け入れられるポイントに到達するように洗練および分割する必要があります。このようなストーリーをカンバンのコンテキストで開始することはほとんど意味がなく、メトリックを完全に低下させます。

スクラムまたはカンバンのいずれにも公式の「ビジネスアナリスト」の役割はありません。ストーリーを分析して推定するのはチームです。スプリント計画が初めて開発チームがストーリーの詳細を聞く場合、何かがうまくいっていません。BAを利用できない、またはすべての開発者がすべての要件収集ミーティングに参加する必要があると言っているわけではありませんが、開発者の表現は、スプリント計画の前の要件収集のある時点で発生する必要があります。BAは通常、実装の詳細について十分な知識がなく、物事のコストや、どの質問がコストに大きな影響を与えるかを知ることができません。これは、開発チームがそれらを見るまで認識されない推定に劇的な影響を与える可能性のある詳細があるかもしれないことを意味します。さらに、開発者は、より費用対効果の高いアプローチに向けたガイダンスを提供したり、比較的簡単に実装できる機能を提案したりすることができますが、ユーザーに多くの価値を追加する可能性があります。私があなたの場合に起こっていると思うのは、BAが要件収集を行っているときに開発者がBAを支援しているということです（たとえば、BAの質問に答えたり、桁違いの見積もりを提供したりします）。これは、大まかにバックロググルーミングに取って代わります。あるいは、比較的小さなパケットで自然に到着する作業（保守作業など）を行っている場合、かんばんの方が適切なプロセスである可能性があります。

受け取ったフィードバックに基づいて回答を編集して、スプリントの要件とスプリントの計画段階で、いつどのように作業する必要があるかをさらに理解できるようにします。現在のプロセスにかんばん方式を適用する場合も同様です。私の回答では、「かんばん」と「かんばん方式」という用語を同じ意味で使用しています。どちらもかんばん方式の推奨事項を意味します。これがお役に立てば幸いです。

まず、「かんばん用」の要件開発/詳細プロセスについては何も変更しないでください。かんばんはそこで何も推奨しません。カンバンが推奨するのは、要件管理やスプリント計画など、現在のプロセスを視覚化し、WIP制限を実装し、フローを管理することです。その後、観察されたボトルネックと改善の機会に基づいて、プロセスに変更を加えます。

[まだ読んでいない場合は、カンバンメソッドのパイオニアであるデビッドアンダーソンの本「カンバン：テクノロジービジネスの成功する進化的変化」を読んでください。（完全な免責事項-私はカンバン製品会社の共同創設者です。私はまた、リーンカンバン大学認定のカンバンコーチおよびトレーナーです。）

かんばん自体は、ソフトウェア開発/プロジェクト管理方法論ではありません。既存のプロセスがないと、かんばんを適用/実装できません。これは、現在のプロセスが何であれ、進化的（段階的、無停止）に改善するのに役立つ方法です。あなたの場合、それはスクラムです。したがって、チームがソフトウェア配信を改善するのを支援するために、スクラムプロセスにカンバンを実際に適用する必要があります。これの組み合わせは、一般的にスクラムバンとして知られています。

かんばんの3つの基本原則に従うことから始めます。

1. 今していることから始めましょう
2. 進化的で段階的な変更を追求することに同意する
3. 現在のプロセス、役割、役職、責任を尊重する

これらを指針として、次にカンバンメソッドの標準的な方法を実装します。

1. 現在のプロセス（および進行中の作業）を視覚化する
2. WIP（作業中）を制限する
3. フローを管理
4. プロセスポリシーを明示的にする

これらの4つのプラクティスから始めます。かんばん方式では、他に2つのプラクティスが定義されており、開始してすぐに確認できます。これらは、（5）フィードバックループの実装、および（6）科学的方法を使用した共同での改善と進化です。

これは簡単な要約です-本は本当にあなたがこれらをよりよく理解するのを助けるでしょう。当社のウェブサイトには包括的なかんばんガイドもあります。]

あなたの状況で焦点を当てるべき重要なことは、あなたが今日していることを（かんばんボードで）視覚化することです。現在の要件プロセスは、スプリント計画プロセス中、または視覚化するために選択できるいくつかのサブステップ中に実行する必要があります。実際、カンバンボードは、全体的な開発プロセスの特定の段階としてスプリント計画を反映し、必要に応じて技術設計、開発、テストを反映する必要があります。

ユーザーストーリーはスプリントの計画段階ですが、BAが詳細を提供し、開発者が質問を準備し、ストーリーが技術設計段階以降に進む前に質問に回答するなど、その中の手順に従います。

（ところで、要件プロセスに、ロードマップ計画またはバックロググルーミングの一部と見なされる上流の側面がある場合、上流のアクティビティをより詳細に管理するのに役立つ「上流のかんばん」のトピック全体があります。あなたまたはあなたのBA / POは、そのすべてのアクティビティを管理するために、別個の上流のかんばんボードを使用することを検討することができます。

Dev Kanbanボードフローは以下のようになります-

バックログ->スプリント計画->技術設計->開発->テスト->統合->完了

各ステージには、独自の「進行中」および「完了」のサブ列があります。ただし、1人の開発者がすべてのステージを通過する場合、各ステージでこれらのサブ列は必要ない場合があります。重要だと思う場合は、スプリント計画を3つのサブステージ（ストーリーの詳細化、明確化、完了）に分割できます。そのため、作業の各側面でボトルネックを調査できる可能性があります。たとえば、私たちの開発チームでは、コードレビューがボトルネックになることがよくあります。

2週間または3週間のスプリントサイクルの最後に、完了したすべてのユーザーストーリーをまとめて出すことができます。そして、バックログの次のストーリーセットから始めます。

一定期間、スクラムを実行する上でのいくつかの課題（ストーリーの漏れ、スプリントの締め切りの遅れなど）は、スクラムの制約/ルールの一部を廃止することで対処できると判断する場合があります。一部には礼儀正しい。私たち自身が4〜6週間のリリースを行い、スプリントは行いません。しかし、同様に、スプリントとリリースを引き続き使用することもできます。私たちの経験では、ここで、カンバンはビジネスやチームにとって適切なものを決定し、プロセスを採用または変更して、フロー、スループット/速度を最大化し、デリバリーリードタイムを短縮します。市場投入までの時間）。

十分な数の機能が構築された（または不具合が修正された、または両方の組み合わせが）ときに、Sprintsを廃止してリリースを作成するかどうか、またはSprintsを維持するかどうか-かんばんは、チームの作業をよりスムーズに行うのに役立ち、排除しますボトルネックを解消し、サイクルタイムのパフォーマンスを向上させます。これにより、より頻繁なリリースが可能になり、顧客からのフィードバックをより迅速に得ることができるようになった場合は、「より機敏な」状態に移行することになりますが、スクラム方式の従来の定義に必ずしも適合しない場合があります。

ただし、ビジネス目標がより適切に満たされ、顧客がより幸せになり、チームが最適に機能できる場合は、かんばんの実装という目標を達成することになります。

お役に立てれば。ご不明な点がございましたら、お気軽にお問い合わせください。

特にあなたの質問に精通するために...

ストーリーの要件について話し合うために、技術者とビジネスフォークが一緒に座っている（かんばんの）点は何ですか？プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供していませんか？

デビッド・アンダーソンが開拓したカンバン法には、この活動がいつ起こるかについての特定の慣行や勧告は含まれていません。かんばんの実践者が提供する答えは、最初にかんばん方式を採用するとき、作業の管理方法を進化させることを決定する前に、それを実行するのと同じ方法でこのアクティビティを実行する必要があるということです。2週間ごとに実行する場合は、2週間ごとに実行し続ける必要があります。

チームは、スケジュールを変更する機会と価値があるかどうかを発見します。1か月のスケジュールは1年よりも機敏であり、2週間のスケジュールは1か月より機敏であり、1週間は2週間より機敏です。この考え方により、最終的には、ジャストインタイムが最も機敏であることがわかります。ビーイング最も機敏なことはあなたも開始する前に、ターゲットの状態であってはなりません。

スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はどのようにストーリーを理解するのかはわかりません。

考え方および一連のプラクティスとしてのカンバンメソッドは、スプリント、スプリント計画会議、またはその他のプラクティスの存在に条件や制約を課しません。それはスクラムチームとその慣行を完全に尊重しています。Techiesが話をする今日の会議がある場合、同じスケジュールを使用して、その会議を継続します。

あなたのチームとその周りの組織を理解することなく、スケジュールがどうあるべきか、あるべきか、あるべきであるかを良心的に伝えることはできませんでした。今日これらのアクティビティを実行しない場合、これらのアクティビティを実行する方法を教える他の多くの情報源があります。かんばんメソッドは、あなたの選択が良いものであるかどうかを発見するようにあなたに教えることに関するガイダンスを提供することができます。

この2つのシリーズのブログ投稿をお読みください。1人は私から、もう1人はScrum.orgのチームメンバーであるSteve Porterからです。

かんばんの何もスクラムを妨げない-Dave White-WesternDevs.com

スクラムとかんばん-より強く一緒に-スティーブポーター-Scrum.org

Mahesh Singhが最初に述べていることのほとんどは、Lean Kanban Incの公開されたトレーニング資料からです。つまり、本当に...ここで議論することは何もありません。AKTやKCPと話すと、彼/彼女は同じことを言うでしょう。

要件を明確にできる場所についての最初の質問には、さまざまなオプションがあります。

1. 今日のことを行うことができますが、それらのステップを視覚化してバリューストリームに配置することにより、障害を特定します。次に、1つの変更を行い、それがどのように機能するかを確認します。トヨタカタコミュニティはこれを単一因子実験と呼んでいます。

2. 要件の精緻化、分解、UX /相互作用の設計などのために上流のボードを実行します。私たちのチームでは、テーマをエピックに分解し、完全なUX設計サイクルを実行してから、ストーリーに分解します。次に、すべての利害関係者を会議に参加させることにより、ストーリーが優先されます。このバリューストリームの終了により、洗練された優先順位の高いストーリーが生まれます。これが開発チームのバックログになります。実際、このフローは多くのサイクルタイムを要します。これは主に、Devチームのエピックレベル要件からスケッチまたはツェッペリンのワイヤーフレームに移行するのに時間がかかるためです。

3. 何かを要求から洗練されたストーリーに変換するための重要なバリューストリームまたはサイクルタイムがない場合は、開発バリューストリームにステージがあるだけです（要件の明確化など）。ただし、スクラムは、見積もりとタスクへの分割について、高いレベルの明確性を期待しています。したがって、スプリント計画会議の前に会議を行うか、拡張スプリント計画会議を行うかは、チームと組織によって異なります。

原則を覚えており、定義されたプラクティスにオープンであれば、検査と適応のサイクルがはるかに簡単になります。