role business analysts scrum
YouTubeのビデオをmp3にダウンロードするウェブサイト
SCRUMにおけるビジネスアナリストの重要な役割:
間もなくBAと呼ばれるビジネスアナリストは、 スクラム 。
この人は、製品の所有者/顧客と技術ITチームの間のリンクです。 BAのウェブサイトでいくつかのチュートリアルに出くわしましたが、このチュートリアルはどういうわけかユニークなものであり、スクラムにおけるBAの重要性を説明します。
探検しよう!
=> ここですべてのビジネスアナリストチュートリアルを確認してください。
学習内容:
- BAの責任
- プロダクトオーナーとしてのビジネスアナリスト
- チームメンバーとしてのビジネスアナリスト
- SCRUMチームにおけるビジネスアナリストの重要性と役割
- QAがこの仕事に最適なのはなぜですか?
- 推奨読書
BAの責任
スクラムにはビジネスアナリストの役割がいくつかあり、BAが従うべき特定の責任があります。
それらの中からいくつかの選択的なものを以下に述べます。
- 製品所有者によって提供された優先順位に基づいて製品バックログをグルーミングします。
- 顧客のニーズを分析し、それらに対処するためのソリューションを見つけます。
- 適切な受け入れ基準を使用して、ユーザーストーリーの形式で要件を作成します。
- ユーザーストーリーが(受け入れ基準を使用して)製品所有者によってすでに作成されている場合は、それらをレビューして、すべてのビジネスルールがカバーされ、受け入れ基準がユーザーストーリーの機能を満たしていることを確認します。
- 製品の所有者および利害関係者と協力して範囲を理解し、要件の改善を提案するなど。
- 必要に応じて、ワイヤーフレーム、デザインフロー、UIなどのドキュメントを準備します。
これとは別に、 ビジネスアナリスト チームが今後のスプリントのバックログについて話し合うために集まるブレーンストーミングセッションの重要な参加者です。 BAはチームをガイドし、チームが要件を理解するのを支援し、場合によっては実装を承認する必要があります。
また、テストカバレッジの分析、実際のユースケースのテストケースへの変換、複雑な機能をテストするための洞察の提供など、QAと緊密に連携します。また、BAは計画会議に参加して、チームの見積もりを支援します。フロー、複雑さ、および依存関係を理解します。
BAは常に市場で起こっている新しいトレンドについて学び続け、革新を続け、製品が製造された事業分野について常に最新の状態に保つ必要があります。
プロダクトオーナーとしてのビジネスアナリスト
顧客や会社によっては、ビジネスアナリストを製品の所有者としている会社もあります。このような場合、BAはすべてのクエリの連絡先になります。その後、BAはチームと利害関係者の間の仲介者になります。
BAは、利害関係者の要件、ビジネスを先に進めることについての彼らの考え、およびビジネスを成長させる必要があるもの(および方法)を理解する必要があります。次に、利害関係者の要件に基づいて、BAはドキュメント、ユーザーストーリーの作成、ストーリーの優先順位付け、チームの理解の支援、同じことに関する質問への回答などを行う必要があります。
ここで注意すべき最も重要なことは、BAが物理的に利用可能であり、「通信のギャップ」を回避するために別のタイムゾーンに地理的に配置されていない場合にこれが推奨されることです。
製品所有者のようにBAが別のタイムゾーンに地理的に配置されている場合、毎回彼に連絡することはできず、通信する唯一の方法は電子メール、チャット、または電話であるため、不足、ギャップ、さらには時々誤解。
私の経験によると、BAがあなたのオフィスのチームの隣に座っているときは、これに従う必要があります。そうすれば、あなたの仕事が妨げられず、彼は簡単に親しみやすくなります。 BAの観点から、彼らは利害関係者/顧客に代わって製品を所有し、適切な決定を下し、開発のいくつかの技術を学ぶことを含む新しいスキルを学ぶ必要さえあります。
ビジネスアナリストが製品を非常によく理解しており、タスクの優先順位付けとスコーピングも交渉できるため、ビジネスアナリストをプロダクトオーナーとして持つことは追加の利点です。
チームメンバーとしてのビジネスアナリスト
もう1つのオプションは、プロダクトオーナーが毎回対応できるとは限らないため、ビジネスアナリストをチームメンバーにすることです。ビジネスアナリストがチームメンバーである場合、彼らはバックロググルーミングで仲間を助けます。
ビジネスアナリストをチームメンバーとして持つことは、技術チームが明確化や議論のためにBAとコミュニケーションをとることが簡単で快適であると感じるため、より有利です。 BAはまた、QAチームと緊密に連携してテストを行います。つまり、カバレッジ、対象となるユースケース、隠れた要件、信頼性、または効果を分析します。
製品の所有者によって書かれた受け入れ基準が曖昧で明確でない場合があります。その場合、チームメンバーとして、精巧で十分に説明された受け入れ基準を書くことはBAの責任になります。チームがより多くの情報を必要とする場合、BAは、チームが要件を理解するのに役立つワイヤーフレームドキュメント、フロードキュメントなども作成します。
モジュールがチーム間で分散されている大規模なプロジェクトでは、複数のチームのBAを持つことも追加の利点です。 BAはチーム間で同じであるため、モジュールの相互運用性、新機能や更新が他のモジュールにどのように影響するかなどについて考えることができます。
したがって、これは、技術チームがそのような側面を検討するのに大いに役立ちます。ユーザーストーリーや受け入れ基準がそのようなことを常に言及しているわけではありません。
SCRUMチームにおけるビジネスアナリストの重要性と役割
SCRUMにおけるビジネスアナリストの役割は、プロジェクトの成功において非常に重要です。彼らの関与は、顧客のニーズを理解することからスプリントデモに始まります。これらは、説明のための技術チームの最初の連絡先です。これらは、新しいプロジェクトや大規模なプロジェクトの初期段階ではさらに重要です。
プロダクトオーナーは必ずしも優れたライターであるとは限りません。技術的なバックグラウンドを持っている場合もあるため、ストーリー、受け入れ、ワイヤーフレームなどを書くのはビジネスアナリストの責任になります。
私のプロジェクトでは、私たちのPOはドキュメントがあまり良くなく、書かれたユーザーストーリーでさえ、2〜3ライナーを超えることはありませんでしたが、受け入れ基準は1ライナーのみでした。それらを修正し、より説明的で精巧なものにしたのはビジネスアナリストでした。
時々、私たちのPOが21以上のストーリーポイントを持つユーザーストーリーを書いたことがありました。そのため、ビジネスアナリストはそれらを分解し、プロダクトオーナーに優先順位を付けるために余分な時間と労力を費やす必要がありました。
ビジネスアナリストがいなくて、プロダクトオーナーが「顧客として、自分のアカウントですべての銀行業務を実行したい」などのユーザーストーリーを、次のような承認基準で作成した場合はどうなるか想像できます。
- 顧客はログインできるはずです。
- 顧客は私のアカウントで取引を行うことができるはずです。
- 顧客は私の履歴ステートメントなどをダウンロードできるはずです。
さて、私の意見では、このユーザーストーリーは34ストーリーポイント以上を保持するため、さらに細かく分類する必要があります。適切なフロー図とUI画面(作成される)が提供されていない場合、技術チームの状況は悪化します。
これはスプリントの失敗につながり、ひいてはプロジェクトの失敗につながります。 プロダクトオーナーが訓練を受けた/実践的なビジネスアナリストでない限り、チームに1人いる必要があります。
QAがこの仕事に最適なのはなぜですか?
QAは、問題/要件について提案されたソリューションをテストすることによって検証する人です。したがって、ビジネスアナリスト/利害関係者/製品所有者は、QAのフィードバックについて知りたがっています。テストへのBAの関与は、開発中のものにすぎません。
ビジネスアナリストは、QAと緊密に連携して、隠れたフローまたは要件/効果への洞察を提供するテストケースカバレッジを確認します。したがって、この種の知識共有(BAによる)により、製品の機能、ビジネスルール、顧客の期待、フロー、依存関係、およびすべてを完全に理解できます。
QAは常に、製品を使用するエンドカスタマーの観点からテストします。したがって、製品の改善や機能強化について顧客を支援する可能性は高くなります(開発者と比較した場合)。開発者は、特定のユーザーストーリーと一連の受け入れ基準に合わせて製品を開発しますが、顧客が製品をどのように使用するかを常に考えているわけではありません。 。
開発では、製品の実装、フロー、およびルールが明確に定義されていますが、テストは完全に論理的思考とエンドユーザーの観点から考える能力に基づいています。
QAは、日常業務で提示される多くの機会のために、SCRUMでビジネスアナリストの役割を開始することができます。
推奨読書=> テスターからBAへのキャリアシフト
QAが次のような役割を担うのは非常に簡単です。
- 要件を非常に深く研究し、レビュー会議やブレーンストーミングセッションなどのギャップを指摘します。より良い解決策を考え、チームやBAと同じことについて話し合うようにしてください。
- プロダクトオーナーとの電話に注意を払い、質問をして、調査結果を共有します。これにより、製品への関心を示す製品所有者の信頼が高まります。
- BAと開発チームの間に自分自身を合わせてください。説明や疑問がある場合は、開発者の連絡先になる必要があります。
- テストプロセスをセットアップし、それを革新し続け、スプリントを成功させるのに役立つように変更します。
- 派手なUIを備えた製品の場合は、新しいトレンドに注目し、そのような改善を提案します。
- 製品を完全に理解します。
- 利害関係者とその期待についての強力な知識を構築し、経験を彼らと共有します。
これはまた、BAの役割に入るには、スキルを向上させる必要があることを意味します。初級レベルと上級レベルの両方を含むいくつかのコースが市場に出回っています。
あなたはBA / QAですか?私たちはあなたの役割についてすべて正しく指摘しましたか?または私たちが逃したと思いますか あなたがユニークに実行する何か?ご連絡をお待ちしております。下記のコメント欄でお気軽にシェアしてください!!
=> すべてのビジネスアナリストシリーズを見るには、こちらにアクセスしてください。