ユーザーストーリー

ユーザーストーリーとはソフトウェアシステムの期待される動作の塊です。アジャイルソフトウェア手法で、大量の機能をより小さな部分に分割してプランニングすることを目的に広く使用されています。同じ概念が機能とも呼ばれることがありますが、今日のアジャイルサークルでは「ストーリー」または「ユーザーストーリー」という用語が一般的になっています。

Kent Beckがエクストリーム・プログラミングの一部として最初にこの用語を導入しました。これは長文の仕様書よりも、要求の聞き取りに非公式で会話的な形式を使用することを促進するためです。ストーリーの本質は1つのノートカードに書くことができます（Kentと私は3インチx 5インチを好みます）。ストーリーは、開発の準備ができるまで詳細を詰めずに意識的に作成します。他のストーリーとの優先順位付けに十分理解できれば十分です。

Bill Wakeは、INVEST覚え方を提案しました。これは優れたストーリーの特徴について言及しています。

• 独立性：ストーリーは任意の順序で配信できます。
• 交渉可能性：ストーリーに含まれる詳細情報は、開発中にプログラマーと顧客が共同で作成します。
• 価値：ソフトウェアの顧客またはユーザーからみてその機能は価値があると認められます。
• 見積もり可能性：プログラマーはストーリーを構築するために合理的な見積もりを導き出すことができます。
• 小ささ：ストーリーは短期間（通常は数日程度）で構築する必要があります。1つの反復期間内で複数のストーリーを構築できる必要があるはずです。
• テスト可能性：このストーリーのソフトウェアが正しく機能することを検証するためのテストを記述できる必要があります。

ストーリーのよくある構成方法は、「～として、私は～が欲しい。～ために。」という形式です。「～として」の句はストーリーを求める人を指し、「私は～が欲しい」は機能を説明し、「～するために。」はなぜその機能が欲しいのかを説明します。「～するために。」の部分は、顧客が望んでいると思うものから実際に必要なものを提供するために理解する上で重要なコンテキストを提供します。

Mike Cohnは現在、ユーザーストーリーを書くための標準書籍を執筆しました。XPにおけるユーザーストーリーのルーツを理解するには、ホワイトブックまたは青と緑が上品な本を参照してください。以前のブリキのエントリでは、ユースケースとストーリーの違いについて説明しました。