かんばんを使用する場合、チームはいつ要件について話し合いますか？
私はかんばんについて少し読んでいますが、要件のトピックについて少し混乱しています。
現在のプロジェクトでは、スクラムを使用しています。スプリントの最初に、BAがストーリーのウォークスルーを行い、彼女ができる限りそれを説明するセッションがあります。次に、そのストーリーを取り上げてレビューし、話し合い、BAに次のスプリント計画セッションのための質問を準備します。次のセッションでは、BAがすべての質問に答え、セッションは要件を理解した（ほとんどの場合）ことで終了します。
次のステップは、技術設計を作成し、ソリューション/ストーリーを開発することです。
かんばんに関して、私が読んだすべては、かんばんにはスプリント計画がないことを示唆しています。私の質問は、技術の要員とビジネスマンが一緒に座って（カンバンで）ストーリーの要件について話し合うときですか？プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供しませんか？
スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用でき、かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はストーリーをどのように理解するのかはわかりません。
カンバンにはスクラムのようにスプリントやスプリント計画の概念がないのはあなたの言う通りです。 リーナーな方法論 だからです。さらに多くのことが行われます ジャストインタイム 。
計画活動のスケジュール方法を決めるのはあなた次第ですが、できる限り作業の開始時にそれらを実行することをお勧めします。これは、チームに組み込まれたすべての主要な利害関係者の代表がいる場合に最も効果的です（これにより、スクラムがより効果的になります）。
この図は、 Disciplined Agile Delivery に基づいており、無駄のないソフトウェアプロセスを図で表したものだと思います。
デイリースタンドアップとスプリント計画のイベントは、調整会議と補充モデリングセッション全体でキャプチャされます。調整会議はスクラムからの毎日のスタンドアップのようなものであり、補充モデリングセッションはバックログの精緻化とスプリント計画のようなものです。ただし、チームで問題がなければ、要件に関する議論を調整会議に持ち込むことは問題ありません。
リーンプロセスのほとんどのことと同様に、これはジャストインタイムで発生します。タイムボックスはなく、スクラムのように特定のケイデンスでイベントが発生することはありません。チームと利害関係者に価値を追加するときに作業を行います。
規律あるアジャイル配信のコンテキストでモデル化されたスクラムに基づくプロセスの図解表現と比較できます。
2-4週間のスプリントに制限するのではなく、最初に計画を立て、毎日立ち上がって、最後にレビューと振り返りを行うのではなく、無駄のない方法論により、利害関係者が適切であると考える場合はいつでも、デモンストレーション、調整、および遡及会議を実施します。 。
かんばんは、作業のバックログと進行中の作業（WIP）を管理するためのガイダンスを提供します。かんばんは一般にそれらについて沈黙しているため、他のアクティビティを正確に実装するには、他の手法や方法を使用できます。
あなたはスプリント計画会議がスクラムで何をしているのかを少し誤解/誤解しています。これがあなたの混乱の原因だと思います。スプリント計画会議は、通常、ストーリーの詳細を検討するには不適切な場所です。見積もりに大きな影響を与える未解決の問題がないことを確認するためのいくつかの最後の微調整と迅速な実行を除いて、考慮されるストーリーはほとんど準備ができているはずです。そこから、スプリント計画は、缶に書かれていることを実行します。これは、次のスプリントで何が行われるかを計画します。スプリントがない場合は、スプリント計画の必要はありません。
では、ストーリーの詳細はいつ具体化されるのでしょうか？通常、 Backlog Grooming を介して、または以前のスプリント中の継続的な通信で。ここでの目標は、十分に明確にして、合理的に信頼できる見積もりを与えることができるようにすることです。これは事前にevery詳細を処理する必要はありません。どんなに試しても、実装中に常に疑問が生じます。スクラムの目標は、実装中に出てくる質問を比較的軽微なものにすることです（基本的に、推定値に影響を与えないほど十分に小さい）。
かんばんでは、見積もりはオプションです。推定を行う場合、beforeの話が行われる前にの話がそれを解決するために議論されるという意味で、スクラムに似た何かをする可能性があります。見積もり。推定を行わない場合でも、実際の行動は似ていますが、話が始まるまでは話をしません。
私の経験では、私は通常、メイン開発にスクラムのようなアプローチを使用し、その後、メンテナンスフェーズをよりカンバンアプローチに切り替えたチームで作業しました。メンテナンスフェーズでの作業は散発的である傾向があり、ストーリーはab initioとより小さなスケールでより明確に定義されます。メインの開発フェーズでは、ストーリーは多くの場合、高レベルで始まり、スプリントに受け入れられるポイントに到達するように洗練および分割する必要があります。そのようなストーリーをカンバンのコンテキストで開始することはほとんど意味がなく、絶対にメトリックを低下させます。
スクラムまたはカンバンのいずれにも公式の「ビジネスアナリスト」の役割はありません。ストーリーを分析して推定するのは（== --- ==）teamです。スプリントプランニングが初めて開発チームがストーリーの詳細を聞く場合は、問題が発生しています。 BAを利用できない、またはすべての開発者がすべての要件収集会議に参加する必要があるとは言っていませんが、開発者のsome表現はスプリント計画の前の要件収集中のある時点で発生します。 BAは通常、実装の詳細について十分な知識がなく、物事のコストや、どの質問がコストに大きな影響を与えるかを知ることができません。これは、開発チームがそれらを見るまで認識されない見積もりに劇的な影響を与える可能性のある詳細があるかもしれないことを意味します。さらに、開発者は、より費用対効果の高いアプローチに向けてガイダンスを提供したり、比較的簡単に実装できる機能を提案したりすることができますが、ユーザーに多くの価値を追加する可能性があります。私があなたのケースで起こっていると思うのは、BAが要件収集（BAの質問に答えたり、桁違いの見積もりを提供するなど）を行っているときに開発者がBAを支援していて、これがバックロググルーミングにほぼ取って代わっているということです。または、比較的小さなパケットで自然に到着する作業（保守作業など）を行っている場合、かんばんの方が適切なプロセスである可能性があります。
具体的に質問に精通するために...
ストーリーの要件について話し合うために、技術者とビジネスフォークが一緒に座っているポイント（かんばん）プロダクトマネージャーまたはBAは、カンバンのストーリーのウォークスルーを提供していませんか？
David Andersonによって開拓されたカンバンメソッドには、このアクティビティがいつ発生するかについての特定のプラクティスまたは推奨事項は含まれていません。かんばん施術者が提供するであろう答えは、最初にかんばん方式を採用するとき、あなたはそれを実行するのと同じ方法でこのアクティビティを実行する必要があるということです仕事の管理方法を進化させる前に。 2週間ごとに実行する場合は、2週間ごとに実行し続ける必要があります。
あなたのチームは、スケジュールを変更する機会と価値があるかどうかを発見します。 1か月のスケジュールは1年よりも俊敏であり、2週間のスケジュールはより俊敏であること1か月より、1週間は2週間より俊敏です。この考え方により、最終的にジャストインタイムが最も機敏である 。 最も機敏であるであることは、始める前の目標条件であってはなりません。
スクラムを使用すると、BAは通常、スプリント全体で開発をサポートするために使用できます。かんばんと同じだと思います。カンバンでは、スプリントの計画がない場合、技術者はストーリーをどのように理解するのかはわかりません。
かんばん方式は、考え方および一連の実践として、スプリント、スプリント計画会議、またはその他の存在の条件または制約を課しません実践。スクラムチームとその慣行を完全に尊重しています。 Techiesが話をする今日の会議がある場合、同じスケジュールを使用して、その会議を継続します。
あなたのチームとその周りの組織を理解せずに、スケジュールがどうあるべきか、あるべきか、あるべきであるかを良心的に伝えることはできませんでした。今日これらのアクティビティを実行しない場合、これらのアクティビティの実行方法を教えるための他の多くの情報源があります。 かんばんメソッドは、あなたの選択が良いものであるかどうかを発見するように教えることに関するガイダンスを提供できます。
これら2つのシリーズのブログ投稿をお読みください。 1人は私から、もう1人はScrum.orgのチームメンバーであるSteve Porterからです。
受け取ったフィードバックに基づいて私の回答を編集して、スプリントの要件とスプリントの計画段階で、いつどのように作業すべきかをさらに理解できるようにしています。現在のプロセスにかんばん方式を適用する場合も同様です。私の回答では、「かんばん」と「かんばん方式」という用語を同じ意味で使用しています。どちらもかんばん方式の推奨を意味します。これがお役に立てば幸いです。
まず、「かんばん用」の要件開発/詳細プロセスについては何も変更しないでください。かんばんはそこで何も推奨しません。カンバンが推奨するのは、要件管理やスプリント計画など、現在のプロセスを視覚化し、WIP制限を実装し、フローを管理することです。その後、観察されたボトルネックと改善の機会に基づいて、プロセスに変更を加えます。
[まだ読んでいない場合は、David Anderson著「- Kanban：Successful Evolutionary Change for Your Technology Business 」を読んでください。 、かんばん方式のパイオニア。 （完全な免責事項-私はカンバン製品会社の共同創設者です。私はまた、リーンカンバン大学認定のカンバンコーチおよびトレーナーです。）
かんばん自体は、ソフトウェア開発/プロジェクト管理方法論ではありません。既存のプロセスがないと、かんばんを適用/実装できません。これは、現在のプロセスが何であれ、進化的（段階的、無停止）に改善するのに役立つ方法です。あなたの場合、それはスクラムです。したがって、チームがソフトウェア配信を改善できるように、スクラムプロセスにカンバンを実際に適用する必要があります。これの組み合わせは、一般的にスクラムバンとして知られています。
かんばんの3つの基本原則に従うことから始めます。
- 今していることから始めましょう
- 進化的で段階的な変更を追求することに同意する
- 現在のプロセス、役割、役職、責任を尊重する
これらを指針として、次にカンバンメソッドの標準的な方法を実装します。
- 現在のプロセス（および進行中の作業）を視覚化する
- 仕掛品の制限（仕掛品）
- フローを管理
- プロセスポリシーを明示的にする
これらの4つのプラクティスから始めます。かんばん方式では、他に2つのプラクティスが定義されており、開始してすぐに確認できます。これらは、（5）フィードバックループの実装、および（6）科学的方法を使用した共同での改善と進化です。
これは簡単な要約です-本は本当にあなたがこれらのより良い理解を得るために役立ちます。当社のウェブサイトには、包括的な かんばんガイド もあります。]
あなたの状況で焦点を当てるべき重要なことは、あなたが今日していることを（かんばんボードで）視覚化することです。現在の要件プロセスは、スプリント計画プロセス中、または視覚化するために選択できるいくつかのサブステップ中に実行する必要があります。実際、カンバンボードは、スプリント計画を全体的な開発プロセスの特定の段階として反映し、必要に応じて技術設計、開発、テストを行う必要があります。
ユーザーストーリーはスプリントの計画段階にありますが、BAが詳細を提供し、開発者が質問を準備し、技術設計段階以降に移行する前に質問に回答するなど、その中の手順に従います。
（ところで、要件プロセスに、ロードマップ計画またはバックロググルーミングの一部と見なされる可能性がある上流の側面がある場合、上流の活動をより詳細に管理できるようにする「上流のかんばん」のトピック全体があります。あなたまたはあなたのBA/POは、そのすべてのアクティビティを管理するために、別個の上流カンバンボードを使用することを検討できます。
Dev Kanbanボードフローは以下のようになります-
バックログ->スプリント計画->技術設計->開発->テスト->統合->完了
各ステージには、独自の「進行中」および「完了」のサブ列があります。ただし、1人の開発者がすべてのステージを通過する場合、各ステージでこれらのサブ列は必要ない場合があります。重要だと思う場合は、スプリント計画を3つのサブステージ（ストーリーの詳細化、明確化、完了）に分割できます。そのため、作業の各側面でボトルネックを調査できる可能性があります。たとえば、私たちの開発チームでは、コードレビューがボトルネックになることがよくあります。
2週間または3週間のスプリントサイクルの最後に、完了したすべてのユーザーストーリーをまとめて出すことができます。そして、バックログの次のストーリーセットから始めます。
一定期間、スクラムを実行する上でのいくつかの課題（ストーリーの漏洩、スプリントの締め切りの遅れなど）は、スクラムの制約/ルールの一部を廃止することで対処できると判断する場合があります。一部には礼儀正しい。私たち自身が4〜6週間のリリースを行います-スプリントは行いません。しかし、同様に、スプリントとリリースを使い続けることもできます。私たちの経験では、カンバンは、ビジネスやチームにとって適切なものを決定し、可能な限り最良の方法で作業を提供するのに役立つプロセスを採用または変更するのに役立ちます。市場投入までの時間）。
十分な数の機能が構築された（または不具合が修正された、または両方の組み合わせが）ときに、Sprintを廃止してリリースを作成するかどうか、またはSprintを維持するかどうか-Kanbanは、チームの作業をよりスムーズに行うのに役立つはずです。ボトルネックとなり、サイクルタイムのパフォーマンスが向上します。それによりリリースが頻繁になり、顧客からのフィードバックをより迅速に得ることができるようになった場合は、「より機敏な」状態に移行することになりますが、スクラム方式の従来の定義とは必ずしも一致しません。
ただし、ビジネス目標がより適切に満たされ、顧客がより幸せになり、チームが最適に機能できるようになれば、カンバンの実装という目標を達成することになります。
お役に立てれば。ご不明な点がございましたら、お気軽にお問い合わせください。
Mahesh Singhが最初に述べていることのほとんどは、Lean Kanban Incの公開されたトレーニング資料からのものです。だから、本当に...ここで議論することは何もありません。 AKTやKCPと話すと、彼/彼女は同じことを言うでしょう。
要件を明確にできる場所についての最初の質問には、さまざまなオプションがあります。
今日のことを行うことができますが、それらのステップを視覚化してバリューストリームに配置することにより、障害を特定します。次に、1つの変更を行い、それがどのように機能するかを確認します。トヨタカタコミュニティはこれを単一因子実験と呼んでいます。
要件の精緻化、分解、UX /相互作用の設計などのために上流のボードを実行します。私たちのチームでは、テーマをエピックに分解し、完全なUX設計サイクルを実行してから、ストーリーに分解します。次に、すべての利害関係者を会議に参加させることで、ストーリーに優先順位を付けます。このバリューストリームの終了により、洗練された優先順位の高いストーリーが生まれます。これが開発チームのバックログになります。実際、このフローは多くのサイクルタイムを要します。これは主に、開発チームのエピックレベル要件からスケッチまたはツェッペリンのワイヤーフレームに移行するのに時間がかかるためです。
要件から洗練されたストーリーに何かを変換するための重要なバリューストリームまたはサイクルタイムがない場合は、開発バリューストリームにステージがあるだけです（要件の明確化など）。ただし、スクラムは、見積もりとタスクへの分割について、高度な明快さを期待しています。したがって、スプリント計画会議の前に会議を行うか、拡張スプリント計画会議を行うかは、チームと組織によって異なります。
原則を覚えており、定義されたプラクティスにオープンであれば、検査と適応のサイクルがはるかに簡単になります。