.2 ストーリーの仕上げ
目的
ストーリーの仕上げは、ジャストインタイム/ちょうど良い（just‐enough）方式でユーザーストーリのための詳細設計および受け入れ基準を定義するために使用されるテクニックです。ストーリーの仕上げは進行中の活動で、開発プロセスの一部です。
概説
ストーリーの仕上げは、ストーリーを最低のレベルに分割し、ストーリー文を数個の作業に分解するプロセスです。しばしばチームの中で強いビジネスアナリシススキル、特にファシリテーションとコミュニケーションスキルを持っている人によって実行されます。ストーリーの仕上げは、詳細な要求を引き出し、プロジェクト・チームに伝えるテクニックです。
各イテレーション中に、ストーリーのスケジュール時間で仕事をするチームは、詳細を理解するためストーリーを拡張します。しばしば(しかし常にではありませんが)、これは、短時間のワークショップの中で完成し、そのワークショップはストーリーに取り組むプログラマ、ストーリーを必要とするビジネスSMEか顧客、ストーリーをテストする人、ストーリーをファシリテートし挑戦するビジネスアナリストを務める誰かが関与します。典型的には、ストーリーの仕上げはストーリーの開発の数日前に先立って試みられます。
ストーリーの仕上げは、必要に応じてジャストインタイムベースで、次のイテレーションにあるとわかったストーリーで行われるべきです。もし集められた情報が古くて旧式かもしれない場合や、問題のリリースに対して計画されていない場合は、プロジェクト・チームは、仕上げのためにストーリーの調査を行うべきではありません。
ストーリーの仕上げは正しいプロダクトを確実に構築することを支援するコミュニケーションテクニックです。アジャイルなプロジェクトでは、詳細な要求はストーリーを仕上げることによって作成されます。しかしながら、計画駆動アプローチに対峙し、アジャイルのジャストインタイム哲学に基づくものして、ストーリーの仕上げの間に定義された詳細な要求は、次期リリースで完成することになっている作業に必要な詳細な要求だけを含んでいます。
要素
ストーリーの仕上げの結果は、参加者の間の共有された理解ですが、ストーリーが意味するものの理解と、このストーリーの「結果の」状態を達成するために伝えるべきものの、理解です。ダイナミックな要求の開発とコミュニケーションにおけるビジネスアナリストの役割は、ファシリテーションとコミュニケーション双方における高度のテクニックを必要とします。
いくつかのチームは、ユーザーストーリーのそれらの分析をコミュニケーションする方法として、タスクを使用します。有効なストーリーの仕上げのアウトプットはチームを成功に導く、次期イテレーションに関するタスクを記述し、かつ/あるいはドキュメントを作成することです。これらのアウトプット出力は下記を含みます?
- タスク定義とその分解
- 顧客のストーリに関する意図を説明するサンプルとシナリオ、
- テクニカルデザインか、プロセスデザイン(例えばデータモデル、またデータ・フロー・ダイアグラム)を明確にするローファイ（low-fidelity）モデル、
- スクリーンあるいは報告書のモックアップ、
- ストーリーがしばしばどのようにテストされるか明確にする受け入れ基準(テスト設計仕様書)<given><when><then>ビヘイビア駆動の開発フォーマット、
- インプット/アウトプットのデータテーブル、そして
- このストーリーの開発およびテストに役立つ他の成果物。
使用上の注意
長所
- ストーリーの仕上げの主な長所は、現在のフィーチャーに注目することによって、引き出しとおそらくドキュメンテーションに要する時間を削減できることです。本当に必要なときにだけ要求をさらに詳しく調べるようにするので、チームは決して構築されないかもしれないフィーチャーや、インプリメンテーションの準備ができる時までに変更の必要がないフィーチャーの要求を引き出す仕事を回避することができます。
短所
- アジャイルなアプローチにあまり慣れていない人々にとって、ストーリーの仕上げを行う最良のタイミングを決定するのは難しいかもしれません。もしあまりにも早く行えば、情報は与えられたリリースにはもはや正確でないかもしれないし、再度要求の引き出しを行う必要があるでしょう。また、要求の収集が遅すぎれば、開発プロジェクト・チームの進行を遅らせることになってしまいます。
- ストーリーの仕上げの実行に対する別の挑戦は、要求として開発され、テストされ、受け入れ基準と比較できるような適正水準の詳細を引き出す能力です。
.3 ストーリーマッピング
目的
ストーリーマッピングは、ソリューションが支援する活動の順序についての視覚的・物理的な見方を提供します。横軸はプロダクトのキーの要素のシーケンスとグループ分けを示し、縦軸はストーリーの詳細およびプライオリティを示す、2次元の格子構造を使用します。
概説
ストーリーマッピングはプロダクト機能についての理解を作成するのを支援するツールで、使用法のフロー、また優先順位を付けるプロダクトデリバリー(リリース計画など)で支援します。さらに、端から端まで（end‐to‐end）のビューで始まり、詳細なユーザーストーリーにドリルダウンする、プロダクト進化の理解を考慮する分割テクニックです。
ストーリーマッピングは、情報ラジエーターであるように設計されていて、使用法とプライオリティのコンテキストにおけるプロダクトのリクエストを視覚化するために使用されます。ストーリーマッピングは、通常プロジェクト・チームのためにリリース計画セッションの間にディスプレイとして置かれます。ストーリーマッピングの分析によって、チームは、ユーザーストーリーによって意図したフローの結果生成された依存性をより容易に識別することができます。マップもストーリーがビジネス価値を伝えるコンテキストでどのようにして相互に働く必要があるか調べることにより、リスクのアセスメントとマネジメントに使用することができます。
下図はストーリーマッピングの例です。
要素
ストーリーマッピングにはプロダクトを構築する要素の中央のバックボーン（背骨）があります。この背骨の上には、プロジェクトライフサイクルにおいてデリバリーする必要のある大きなフィーチャーセット(活動)があります。背骨はソフトウェアがもたらす連続するタスクの集まりです。背骨の下に、タスクが遂行されることを可能にするために特定の機能をインプリメントする詳細なストーリーがあります。
使用上の注意
長所
- プロダクトのより大きなコンテキストが説明されない場合、アジャイルプロジェクトは詳細の泥沼にはまりこんで無力となり、端から端まで（end‐to‐end）のビジネス価値を作成するために有効にコンポーネントをつなぎ合わせることができなくなってしまいます。しかし、ストーリーマッピングは、ユーザーストーリーの詳細に没頭したり、ビッグピクチャコンテキストを失うというリスクに共通の問題を回避するのを支援してくれます。
短所
- プロダクトが非常に大きくなると、大規模なプログラムをカバーする多くのストーリーを構築することを要求されるので、ストーリーマッピングは面倒くさいものになってしまいます。ストーリーマッピングはフローを説明していますが、要求(その分析をファシリテートするのを支援するために使用することができますが)間の依存性を分析しないし説明もしてくれません。
- プロセス志向でない環境では、ストーリーマップはそれほど役に立ちません。
.3 ユーザーストーリー （省略）
.4 ストーリーボーディング（省略）