スクラムでは、BAはスタンドアップに招待されますか、それともニワトリまたはブタですか？
私はスクラムの共同創設者であるジェフ・サザーランドからこの答えを興味深く読んだ：
Q：Business Analystについてのあなたの見方とそれがスクラムとどのように関連しているか？役割の場所はありますか、それともその職種のスキルセットをチーム全体に分散または所有させる必要がありますか
A：ビジネスアナリストは、チームの要件を明確にする責任があります。そのため、この取り組みの一部はプロダクトオーナーに、一部はチームに属します。私は通常、ビジネス分析を割り当てて、バックログの準備ができるまでプロダクトオーナーと協力し、チームと協力してそれが適切に実装されていることを確認します。
そして この記事 はBAのこれらの役割をリストします：
利害関係者との関係を管理し、それらの会話を促進することによって要件を収集します。
可能な限り多くの価値をできるだけ早くリリースするために、何を構築するかについてのガイダンスを提供します。
スクラムチームが過去を振り返って作業方法を計画し、改善するのを支援する。
チームが行う作業を確実にすることは、より広範なビジネス戦略と一致します。
これは、スクラムのビジネスアナリストが pig としてスタンドアップ会議に参加する必要があることを意味しますか？
スタンドアップミーティング では、すべての参加者に3つの質問が寄せられます。彼らです：
- 開発チームがスプリントの目標を達成するのを助けた昨日は何をしましたか？
- 開発チームがスプリントの目標を達成するために、今日私は何をしますか？
- 私または開発チームがスプリントの目標を達成するのを妨げる障害はありますか？
「要件の明確化」は3つの質問の一部ではないことに注意してください。
会議全体の所要時間は15分以内です。その時間枠では、可能性があります質問3が要件仕様で問題を引き起こす可能性がありますが、その問題の解決が行われますBAがいるスタンドアップミーティングの外部。
「BAはチームの要件を明確にする責任があります」
毎日のスタンドアップミーティング以外でBAに説明を求めるのは、スクラムマスターの責任です。 BAを個々のスプリントの計画会議に含めることは意味がありますが、毎日のスタンドアップ会議には含めません。
鶏と豚の類推がスクラムのBAにどのように適用されるのか理解できません。
鶏と豚の寓話、および「鶏」と「豚」の用語全体が スクラムガイド から削除されました。
デイリースクラムの目的は、開発チームがアクティビティを確認して調整することです。つまり、スプリントバックログでの作業の完了に向けて彼らがどのようにしているか、およびスプリントの目標を達成するためにどのようにしているかを見てください。デイリースクラムの1つのルールは、開発チームのメンバーのみが参加することであり、スクラムマスターは、開発チームの外部からの参加者がイベントを中断しないことを保証します。
では、開発チームのメンバーは誰ですか？スクラムの3つの役割は、プロダクトオーナー、スクラムマスター、および開発チームです。開発チームは、「各スプリントの最後にリリース可能な「完了」製品のリリースの可能性を提供する作業を行う専門家で構成されています。」これが誰であるかは、組織によって異なります。ビジネスアナリストが、チームの定義の完了を満たすために必要な作業を行っている場合、それらは開発チームの一部です。ただし、彼らが定義の達成につながる作業を行っていない場合、彼らは開発チームのメンバーではありません。
質問では、リストされているビジネスアナリストには4つの役割があります。
- 利害関係者との関係を管理し、それらの会話を促進することによって要件を収集します。
- 可能な限り多くの価値をできるだけ早くリリースするために、何を構築するかについてのガイダンスを提供します。
これは、製品バックログを精査する継続的な活動の一部です。これはスプリントとは関係ありませんが、さまざまな利害関係者のニーズの変化です。これは、Daily Scrumでは実際には場所がありません。アイテムは、それらの決定を行う権限を与えられた人々によって、製品バックログで継続的に追加、削除、および再注文する必要があります。それはおそらくビジネスアナリストを含みます。
- スクラムチームが過去を振り返って作業方法を計画し、改善するのを支援する。
これはデイリースクラムの一部ではなく、回顧展です。 Retrospectiveは、プロダクトオーナーを含むスクラムチーム全体が参加できます。ビジネスアナリストがプロダクトオーナーと緊密に連携してチームをサポートしている場合、彼らも同席する可能性が高いことは理にかなっています。
- チームが行う作業を確実にすることは、より広範なビジネス戦略と一致します。
これは、Daily Scrumで役立つ可能性があります。オブザーバーとして、ビジネスアナリストは、スプリントの目標を達成し、スプリントバックログを完了して将来の作業を計画する際に遅延をもたらす可能性があります。スプリントの目標が危険にさらされている場合、デイリースクラムの直後にそれらを利用して、残りの作業に優先順位を付けて利害関係者に最大の価値を追加する方法についてチームと調整できます。デイリースクラムは15分にタイムボックス化されていますが、デイリースクラムに続いて適切な人々とのより詳細なディスカッションにすぐに移動することも珍しくありません。
スクラムごとに、BAは定義済みの達成に向けた作業を行わない限り、デイリースクラムの参加者ではありません。ただし、参加と出席は異なります。 BAを参加させるかどうかを評価し、デイリースクラムに時間を割いた後、必要に応じてディスカッションに参加できるようにする必要があります。
ISスクラムチームに組み込まれ、毎日のスタンドアップに参加するBAとして、私は個人的な経験から少し洞察を提供したいと思いました。一般的に、BAは、アジャイルスクラムプロジェクトです。特に、多くのチームがある大規模なプロジェクトでは、プロダクトオーナーが一度にどこにでもいることができない場合でも、非常に役立ちます。BAは、下位の「代行」POとして機能できます。多くの場合、要件についての質問に答えることができ、アプリと顧客のビジネスプロセスの使用目的をよく理解しているチームの近くにいる人がいると役立ちます。
これは、スクラムチームにBAを組み込むことが理想的であるという意味ではありません。要件についてチームとのコミュニケーションを円滑化するのに役立ちます。BAは、顧客と開発者（顧客に直接連絡することに消極的であるか、知らない可能性がある）の間のコミュニケーションを促進するのに役立つ便利な導管として機能します。何かを明確にするために正確に誰に何を尋ねる必要があるか）。しかし、一般的に、これは朝のスタンドアップミーティングに参加する十分な理由にはなりません。 BAには通常、チームにとって有用な更新がありません。特に、その形式で質問に回答するのに必要ではありません。特に、開発者は一日中いつでも利用できるはずです。
私たちのケースでは、BAはチームのユーザーストーリーを作成し、ユーザーストーリーが合意されたスコープFLI（機能的ラインアイテム）にリンクされていることを確認し、完了したストーリーの機能を「サインオフ」のようなものとして確認してから、正式なテストプロセスに。 BAをスクラムチームに「埋め込む」ことには多くのメリットがあると思いますが、実際に、私のプロジェクトがこれを行う理由は、政府の顧客がいて、同時に「機敏」であることが望まれているという事実によるものです。アジャイルソフトウェア開発を実際に実践する私たちの能力を妨げます。自分の立場は、残念ながら、「スクラムフォール」タイプの妥協の結果だと思います。
私はBAがスクラムプロセスの一部であってはならないことを主張します。彼らはスクラムチームのメンバーではありません。代わりに、スクラムチームのメンバーであるプロダクトオーナー向けのリソースです。最終的に、プロダクトオーナーは、バックログに何がどのような順序で入るか、およびそれらのPBIの受け入れ基準を決定する責任があります。次に、BAはプロダクトオーナーがこれらの決定を下すのを支援しますが、それは彼らが現在スクラムチームの一員であることを意味しません。
私は個人的に、ニワトリとブタの類比（および使用）が役立つものだと思います。私が一緒に仕事をしているチームは、それをもう使用していません。
イモそれはスタンドアップを集中するために発明されました。だからここにあるもの：スタンドアップは配達を容易にするためにそこにあります。主にチームのブロックを解除します。覚えておいてください、それはステータスの更新ではありません。これは、チームが確実に実行できるようにするための迅速な実行です。
このため、PO、BA、QA、Dev、UXなど、チーム全体をスタンドアップに含めました...
ただし、強調するブロッカーまたは依存関係がある場合にのみ話すことも知っています。
スクラムの周りには、多くの官僚的で見当違いの「プロセスに従うだけ」という考え方があり、法律の書簡に従うため、チームの価値が低くなることがよくあります。柔軟性があり、本の内容ではなく、チームに役立つことを行う...