スクラムにアジャイルBAの役割はない
組織におけるアジャイルの影響力は拡大し続けており、当初のソフトウェア開発の本拠地を超えている。 スクラムのようなアジャイルソフトウェア開発手法は、多くのビジネス分野で変革プロジェクトに取り入れられている。
従来のプロジェクトにおけるビジネスアナリシスのプロセスは、プロジェクトの初期段階、特に現在のビジネスプロセスとシステムを分析し、費用対効果の高い解決策を特定する段階で行われるのが一般的であった。 この場合、開発作業のサインオフを得る前に、利害関係者と議論してビジネスニーズを特定し、文書化する必要があることが多い。
アジャイル・プロジェクトでは、その性質上反復的であるため、プロジェクトの最初に「1つの大きな分析段階」があるわけではない。 現行のシステムとプロセスの分析は行わなければならないが、開発中の製品に対するユーザーのフィードバックに基づいてソリューションが進化するため、現在では複数の反復にまたがって行われる。
したがって、ビジネスアナリストの役割を含む従来のプロジェクトの役割は、新しいガイダンス、コンセプト、テクニックを学ばなければならない。
実際、スクラムでは、アジャイルチームにおけるビジネスアナリストの役割すら定義されていない。 スクラムでは、開発チームのメンバー自身がジェネラリストであり、コーディング、設計、テストを少しはこなせることが期待されている。 スクラムでは、ユーザーストーリーを書くのはプロダクトオーナーである。 プロダクトオーナーは、開発チームのためにプロダクトバックログのユーザーストーリーに優先順位をつける。
これは、アジャイルビジネスアナリストが、その経験、洞察、知識をユーザーストーリーを書くために必要な共同作業に持ち込むことによって、スクラムのような既存のアジャイルメソッドをどのように補完できるかの例である。 したがって、開発チームのメンバーは、アジャイルチームでの分析作業に適用できるビジネス分析テクニックと手法を学ぶことで、大きな利益を得ることができる。