2.4 アジャイルアプローチにおける計画のレベル
アジャイルアプローチの動的性質である流動性により、異なる計画テクニックおよび計画の各レベルの適切な詳細さをいつ、どのように適用するべきであるか理解することは重要です。アジャイル開発の環境の中で使用されるテクニックの多くが従来のテクニックに似ていることに注目することは重要です;異なるのはいつ、どのようにテクニックを応用するかです。
ビジネスに一貫して妥当な、必要な要求だけをジャストインタイムで。これがビジネスアナリストのアジャイルアプローチにおける役割の中心となります。アジャイルな世界において計画の練習を経験する場合、アナリストの役割が計画駆動開発手法とどのように異なるか考えることは有用です。アジャイルの中で、ビジネスアナリストの役割はプロジェクトのバリューを中心に考えることです。すべてのプロジェクト・ステイクホルダーとの対話を促進することによりビジネスバリューを最大化することに重要な役割があります。並外れたコミュニケーション能力、ファシリテーションおよびネゴシエーションスキルは、アジャイル環境の中においてビジネスアナリストのための重要なツールセットです。
成功するアジャイルプロジェクトは以下の一貫した計画のリズムがあります。
- 戦略、
- リリース、
- イテレーション、
- 日次（毎日）、
- 連続的
このリズムによって、プロジェクトの要求は、次第に適正な詳細レベルに入念に作られます。個々のステップでは安定した概念が捕捉され、コンテキストが捕捉され、学習の機会が識別されます。アジャイルの基本的考え方の1つが各計画レベルに十分なレベルの分析を行なうことです。初期フェーズにおける過度の分析は、次のようなドキュメントの生成に帰着する場合があります。そのドキュメントは変更の対象になることが多くて、ニーズについて何度も説明することをビジネスユーザーに要求し、結局はプロジェクトのゴールを達成するのには必要でないかもしれないものです。逆に初期フェーズの分析があまりにも少ないと無責任なコミットメントで、手戻りが必要となり、顧客バリューの焦点が欠けたものに帰着することになります。ほとんどのアジャイルチームは日次作業、イテレーション、リリースの計画に注目します。
2.4.1 戦略計画
プロジェクトおよび製品開発の活動は、ビジネスの方向性かニーズのビジョンで始まります。ビジョンはWhy（なぜ）、What（何をするのか）、そして結果の成功基準を含みます。ビジョンはしばしばロードマップにも関係します。ロードマップはハイレベルなスコープを含み、初期アーキテクチャーもあるかもしれません。ビジョン、スコープ、ロードマップを確立するような活動に加えて、アジャイルなプロジェクトにおける戦略的作業は、最初のフィーチャに関する要求リストの作成も含まれます。例えば、スクラムではプロダクトバックログに、またXPではユーザーストーリーの中に最初のリクエストの種をまく必要があります。これは計画駆動プロジェクトにおける、スコーピングとフェーズ分けに関する議論を促進するために使用されるプロジェクト以前の、基礎的なステークホルダー要求を引き出すことに類似しています。
戦略計画レベルでは、プロダクトのオーナー、もしくはイニシアチブのリーダーは、デリバリーチームを以下のように支援します。
- 望ましいビジネスバリューを識別し、
- ビジネス・コンテキストを定義し、
- 必要とされるソリューションのコンテキストを定義し、
- またデリバリーチームとのビジョンを実現するステップを識別、概説し、
- 仕事を優先的にする場合、使用されるべき法則を識別し、そして
- 製品ロードマップを定義します。
有効にアジャイルプロジェクト用の戦略を計画できる、強いエンタープライズビジネスアナリストスキルが要求されます。いくつかの方法で、これらのスキルがアジャイルアプローチにおいてより重要になると主張することができるでしょう。ビジネスバリューに基づいた方向性と、明確に定義されたスコープがないままだとアジャイルプロジェクトは、顧客グループに対する最終フィーチャーがインクリメンタルには形成できず、端から端まで（end‐to‐end）のバリューを届けられないリスクがあるからです。さらに、プロダクトのロードマップおよび成功基準がないと、アジャイルプロジェクトは考えられる限りのプロセスに時間、金銭および他のリソースを永久に浪費し続けることでしょう。
2.4.2 リリース計画
リリース計画はプロダクトグループ活動の責任を持ち、チームにそれらを割り付ける人のアクティビティです。チームは責任を持ってリリースの余地のあるスコープにコミットできるのに十分な詳細の定義に取り組みます。リリースを考慮する場合、チームはビジネス状況とオペレーション上の準備状況を考慮します。チームは、デリバリーのベネフィットがリリースに関連したコストより上回る場合にリリースするべきです。そのリリースは日程、戦略テーマ、計画されたフィーチャーセットによって定義されます。リリース日はカンフェランスやコンプライアンス要求のようなイベントにリンクすることができます。リリース計画において目標スコープは合意され、プロダクトバックログのような、フィーチャー要求の優先順位付けリストが計画の基礎としてに使用されます。
2.4.3 イテレーション計画
多くのアジャイルチームがスプリントまたはイテレーションと呼ばれる一定期間のウィンドウで作業します。イテレーション計画のイベントは、各イテレーションのスタート時もしくはその直前に実施されます。イテレーション計画ミーティングに先立って、イテレーションのために考慮されている、要求フィーチャーのリストの中の項目を十分に理解し、チームが責任を持って実行を約束できるようにする必要があります。スクラムでは、バックログの仕込みとして知られています。カンバンのような連続的モデルでは、コミットされる前に、フィーチャー・リストはまだ仕込み中です。しかし、計画リズムは定義された期間で行われのではなく、オンデマンドに基づいてなされます。あるチームでは、プロダクトオーナーもしくは顧客が、イテレーション計画に先立ってデリバリーチームにリクエスト・リストを協働で仕込むことがあります。その一方で他のチームは、イテレーション計画に先立って開催されたワークショップ中に開発された未熟の仕様書を使用しています。この仕事は、必要に応じた追加の引き出しとドキュメンテーションと共に、要求コミュニケーションと分析で構成されます。
イテレーション計画において、スプリント中に行なわれる仕事が識別され、見積もられ、レビューされ、完成がコミットされます。要求と受け入れ基準を理解し、かつ仕様書をより明瞭にするために、デリバリーチームは、顧客あるいはプロダクトオーナーに会います。ビジネスアナリストがステークホルダーに要求を伝えることに関しては、計画駆動プロジェクトでの仕事と類似しています。イテレーション計画の終わりに、デリバリーチームはインクリメンタルな作業により、テスト済みの、実際に動作する展開可能なコードを作成することをコミットします。イテレーションが完成した後、イテレーションレビューかプロダクトデモンストレーションが開催されます。プロダクトデモンストレーションの結果はイテレーション計画の次のサイクルにフィードバックされます。プロダクトデモンストレーションのミーティングは簡易型のユーザ受入テストに似ていて、通常最大4時間に制限されます。
プロダクトデモンストレーションの中では、
- デリバリーチームは、開発されたコードがどのようにその受け入れ基準を満足するかデモし、
- プロダクトオーナーは、フィーチャーリスト上のどのアイテムがイテレーションの中で完成したか決定し、
- 最新のプロダクトを見た結果、顧客から発生するどんな新しいリクエストも、フィーチャーリクエスト・リストに加えられ、そして
- プロダクトオーナーおよびデリバリーチームはビジネス、マーケット、技術の状態をレビューし、次のイテレーションのためのフィーチャーリクエスト・リストの優先順位付け再度行います。
イテレーションレビューミーティングの後、プロセスは再びスタートします。動作するプロダクトが各イテレーションの予想通りの出力であれば、多くのアジャイルチームは、いくつかのイテレーションの価値ある仕事が完成するまで、製品をリリースするのを待つでしょう。チームは、最新のプロダクトを開発するコストと、顧客ベースに届けられる新機能、もしくは改善された機能の量との間で、釣り合う適切なポイントを決定しなければなりません。十分なフィーチャーが完成し、製品をリリースするまでイテレーションは進みます。
2.4.4 日次の作業計画
多くのアジャイルチームが、作業を調整するために日次のチームミーティングを行ないます。日次のミーティングは、通常仕事の状態を明確にすることを目指した15分のミーティングです。
日次のミーティングで、チームは、
- プロジェクトのグローバルなスナップショット（その瞬間のチームの状態）を得、
- どんな新しい依存性も発見し、
- 傾倒した個人のどんな個人的ニーズにも対応し、そして
- その日のニーズを満たし、かつチームがイテレーションコミットメントで確実に伝えることができるために作業計画を調整します。
2.4.5 連続的作業計画
アジャイルプロジェクトの計画活動中に発生する多くのダイナミックなアクティビティ、努力、そして挑戦があります。
ここに、ビジネスアナリシスが役に立つかもしれないいくつかの指針があります:
- バリューから始まり、チームをバリューに忠実にしておく。ビジネスアナリシスの役割を保持する個人がプロジェクトのビジネスバリューに細心の注意を払っていることは重大です。
- 未熟の成果物はコンテキストの作成および共有理解の生成によりビジネスバリューのイネブラーとしては役に立ちます。しかしながら、有効な協働およびコミュニケーションに代えることはできませんし、まして優先することはありえません。
- ビジネスアナリシスは議論と理解の促進に関係します。ビジネスアナリストは、ビジネスに関してビジネス・スポンサーほどの深い知識を持ってはいませんし、また技術チームほど技術に関しての知識を持ってもいません。
- 時間上でビジネスの最大の利益で業務してください。バリューと届けるべきキャパシティーのバランスに責任を持ちましょう。
- ビジネスと技術の理解の間の競合関係とギャップを識別しコミュミケーションします。共通の理解に到達していることを確実にしてください。
- リソースは制限されて価値があります。常にバリューを長期にわたって最大限にすることを支援しましょう。
- チームがアクションを講ずるのを支援してください。次のステップを取る際、何が要求されているのか有効にコミュニケーションしてください。フィードバックが明白に理解されチームが受け取ったことを確認してください。
- 漸増的に反復して伝えてください。恐らく最も小さく作業できる、最も単純なことをしてください。最小のバリューを繰り返してください。仮説を試し、受け入れ基準を明瞭に表現する間に少しずつ詳述してください。
- チームの必要性を満たす最小のドキュメントを作成し、ジャストインタイムで伝えてください。