4.5.2 顧客として考える
顧客のように考えることはアジャイルなビジネスアナリシスの主要な要素です。
顧客とは、私たちが作っているプロダクトから価値を得る人です。
私たちは顧客ゴールのハイ・レベルな視点から始めて、それをより詳細に分解しながら順次、プロダクトが満たすべき特定ニーズについて理解を深めていきます。
アジャイルなプロセスには、その理解の妥当性を確認するために連続的なフィードバックループが組込まれます。プロダクトのデリバリーが進行するにつれ、顧客とチームのニーズへの理解が深まり、それが今後のチームの仕事に影響を与え、定義することが大事です。
アジャイルな分析は、プロジェクトライフサイクルにおいて現実的にビジネス価値をインクリメントにデリバリーするために、最も小さく細切れにします。
チームが、デリバリーするべきプロダクトの全体を理解するのを支援するために、アジャイルな分析を全体的な観点から始めることは重要です。チームは、期待通りのユーザー・エクスペリエンスが実現できるように、顧客と協働します。
分析の一つのゴールは、顧客(特にエンドユーザー)の声（Voice of Customer）が確実に引き出され、プロダクトとして実現されることです。
バックログアイテムは、なすべき仕事を表わし、顧客思考を伝え、そしてプロトタイプ、ユーザーストーリー、ユースケース、最小市場性フィーチャー（MMF）、フィーチャー、エピックあるいは作業項目によって表わすことができます。
次のセクションでは、この原則において一般的に用いられているテクニックについて概説します。
下にリストされた技術は、ユーザーストーリーに基づきます:
- ストーリー分割、
- ストーリー入念化
- ストーリーマッピング、そして
- ユーザーストーリー
ユーザ・インターフェースのプロトタイプを作り、詳細な要求を定義するために使用するテクニックは次のとおりです:
- ストーリーボーディング
BABOKガイドのアジャイル拡張版、BABOKガイドには他のテクニックがあります
さらにここで同様に利用することができる他の特別なテクニックもあります。
.1 ストーリー分割
目的
ストーリー分割は、機能分解のような既存の要求分析テクニックからの派生です。アジャイルなコンテキストでは、ストーリーはチームの仕事およびその仕事の要求(あるいは受け入れ基準)を表わすためにしばしば使用されます。ストーリー分割は、プロダクトへの要求が適切な詳細レベルで表わされ、価値のあるビジネス目標に基づくことを確実にします。
このテクニックは、様々な要求の素を次第により小さなレベルの粒度で定義するための構造を提供します。それは広いシステム・コンテキストから始めて、複数レベルの中で個々のユーザーストーリーにドリルダウンし、最終的に詳細な受けいれ基準を定義します。
概説
ストーリー分割への最も一般的なアジャイルアプローチは「深さより広く（breadth‐before‐depth）」と評することができます:
- 達成するべきビジネスゴールを示す非常にハイ・レベルのピクチャーから始めて、
- それらをより小さなコンポーネントに分割し、価値ある機能(しばしば、市場性のある最小のフィーチャーセットあるいはMMFと呼ばれる。実行可能な最小のプロダクト、MVPは多数のMMFの集まりです。)をインクリメントに提供します、そして
- コンポーネントをユーザーストーリーに分割し、最終的に受け入れ基準を備えたユーザーストーリーを入念に作成します。68ページの「ストーリー入念化（Elaboration）」を見てください。
ストーリーとしては大きすぎるか、理解が不十分で詳述しずらく、見積もることもできなく、ストーリーにしずらいものはしばしばエピックと呼ばれます。エピックは使用する場合、後により小さなストーリーに分割されます。
【図をクリックで拡大】
異なるチームは、異なる方法でこのテクニックを適用します。
例えば、いくつかのチームは上記の図形の中で示されるように、モデルを直線的に使用します。一方他のチームは自分たちの環境の中でベストなやり方でテクニックを活用します。例えば、一旦チームがMMF(しばしばフィーチャーグループと呼ばれる)を開発したならば、ストーリーの代わりにユースケースを活用するかもしれません。
ここでアナリストの役割は、プロダクトを開発し提供するために要求されるものを受け入れるために、ダイナミックな協働、ファシリテーション、コミュニケーションに注力することです。
次のテーブルは、ストーリー分割の異なるレベルについての概説です。
|
レベル |
概説 |
| システムゴール | プロダクトゴールはビジネス要求の最高レベルのもの。当該プロジェクトのビジネス・ドライバーを表わし、詳細なレベルのニーズがすべてアセスメントされる論理的根拠を形成する。 |
| MMF/コンポーネント | MMFはMinimal Marketable Feeature（最少市場性フィーチュア）の略。 実行可能な最小プロダクトあるいはMVPは多数のMMFの集まりである。 これらは、リリースする価値があるプロダクトが提供する機能と能力の論理的なグループ分けである。しばし、これらは、単一リリースのテーマを形成し、開発されるプロダクトに総括的なビッグピクチャコンテキストを提供するであろう。 |
| エピック | ユーザが、明白に識別されたビジネス目標を達成することを可能にする一つの機能。多くの場合、エピックは基本のビジネスプロセスのレベルにある — 特定の作戦目標を達成するためにひとつの場所で、ひとりによって実施されるひとつの当該作業。エピックは多くの場合大きすぎて、イテレーションに入れることができないユーザーストーリーである。したがってイテレーションサイズ未満のストーリーに分割する必要がある。 |
| ユーザーストーリー | デリバリされたシステムで実行されるべきユーザ要求を表わしている。 ユーザーストーリーはアジャイルなプロジェクトの中で使用される最も一般的なバックログアイテムである。 |
| 受け入れ基準 | ユーザーストーリーの妥当性を確認する充足の条件または基準は、アイテム、仕様書あるいはユーザ受け入れテスト(あるいはそれらのコンビネーション)のリストとして書くことができる。詳細な要求は、受け入れ基準として表わされ妥当性を確認される。 |
使用上の注意
ストーリー分割は順次に試みられます。
アジャイルなプロジェクトと計画駆動プロジェクト最も著しい差は、詳細な要求の定義方法です。
アジャイルなプロジェクトの最初の分析活動は、ゴール、MMF、多くのエピックを識別することです。ユーザーストーリー(恐らくプロダクトの最初のリリース用の)の最初のセットは、プロジェクト開始活動の中で行われます。これらのストーリーが変わり、チームの要求についての理解が時間とともに発展するだろうという明確な理解があります。したがって、プロジェクト初期において、詳細なローレベルにまで分割することは、無駄な活動になりがちです。
長所
この分割テクニックは、ユーザーストーリーの詳細に没頭し、ビッグピクチャコンテキストを見失う共通の問題を回避するのを助けます。
・チーム・メンバーがプロジェクトのゴールおよび目標を忘れないようにすることは重要です。また、分割アプローチを使用している間は、要求され実装される機能が、動くビジネス目標にトレースバックすることが可能です。
・プロダクトをMMFとエピックへ分解することによりリリースレベルの計画を支援し、開発計画を見える化し、そして組織的変革マネジメントやユーザー・トレーニングのような外部プログラム活動の調整を支援します。
短所
共通する失敗パターンは、初期に詳細な要求定義を行う戻る道としてストーリー分割を扱う誘惑です。ちょうど良い（just‐enough）とジャストインタイムを連続的に、強調することを確実に行うこと。すなわちいつ分割をやめるべきか知ること。