ユーザストーリーの概要
by Scott
W. Ambler, Copyright 2003
ユーザストーリー(Beck 2000)は、XPプロジェクトチームの主たる開発成果物の1つにあげられています。ユーザストーリーとは要求を非常に高いレベルで定義したもので、開発者が実装作業をそれなりに見積もれるぎりぎりの情報だけを含みます。ユーザストーリーは、顧客(XPのプロジェクトでは利害関係者は顧客と呼ばれます)と話をするためのメモと考えるとよいでしょう。図1を見ると分かりますが、ユーザストーリーは小さいものです。ユースケースよりもずっと小さいものです。XPでは、ユーザストーリーは2人のメンバーで1つの反復/サイクルの間に実装できるものでなければなりません。そのため、1週間単位で反復を行なっている場合には、ユーザストーリーに記述するのは1週間分よりも少ない作業にしなければなりません。
図1. ユーザストーリーの例
- 学生は1ヶ月間の駐車券をオンラインで購入することができる
- 駐車券はクレジットカードで支払うことができる
- 駐車券はPayPalTMで支払うことができる
- 教授は学生の評価をつけることができる
- 学生は現在のゼミスケジュールを取得することができる
- 学生は正式な成績証明書を注文することができる
- 学生は前提条件を満たしたゼミにしか登録することができない
- 成績証明書は標準のブラウザを使ってオンラインで見ることができる
|
図1の文それぞれが1つのユーザストーリーになっています。ユーザストーリーは図2のようにインデックスカードに記述することもよくあります。インデックスカードは非常に扱いやすいため、モデリング時にはさまざまな使い方をすることができます。束の中でカードを動かすことで、要求の優先度を簡単に管理することができます。図のユーザストーリーカードには優先度が付けられています。私はたいてい、1(もっとも優先度が高い)から10までの段階に分けて順位を付けています。他のつけ方も可能です。数値の代わりに高/中/低を使うこともよくありますし、人によっては独自の優先度の番号をカードに割り振ることもあります(344、345、…など)。自分のチームに合った方法を選んでください。
図2. ユーザストーリーカード.
また、この図では、これまでのどこかの時点で優先度が変わっていることが分かります。これはよくあることなので、その場合にはカードを束の中の別の場所に移します。つまり、優先度を扱うには、この種の動きに対応できなければならないということです。私のアドバイスは「簡潔にしておくこと」です。
このカードには、ユーザストーリーに一意の識別番号(173)と、ユーザストーリーを実装する工数の見積もりが付けられています。見積もり方の1つは、カードごとにユーザストーリーポイントを付け、それでプログラマのペアがそのストーリーを実装するのにかかる時間を相対的に表すという方法です。このチームは現在のところ1ポイントに対して平均で2.5時間かかることが分かっているため、図2のカードを実装するには大体10時間かかることになります。
ここで重要なのは、ユーザストーリーを書くのが開発者ではなくプロジェクトの利害関係者だということです。ユーザストーリーは非常に単純なので、2、3分もあれば書き方を覚えることができます。そのため、領域の専門家(利害関係者)がユーザストーリーを書くことは理にかなっています。
多くの場合、サイクル0でひと通りのユーザストーリーを作って、システムの対象範囲を明らかにします。開発サイクルを通じて、新しいユーザストーリーが見つかったり、既存のユーザストーリーが大きすぎて1サイクルで実装できないと分かった場合には分割したり、既存のストーリーの優先度を付け直したり、対象範囲外だと思われるストーリーを除去したりします。重要なのは、他の種類の要求モデルが進化するのと同じように、時間がたてばユーザストーリーも進化するということです。ユーザストーリーの大きな利点は、非常に簡単な技法(インデックスカード)で記述されることが多いため、またユーザストーリーは小さいため、非常に扱いやすく進化させやすい点です。
ユーザストーリーを使って、非常に広範な種類の要求事項を記述することができます。たとえば、図1の「学生は1ヶ月間の駐車券をオンラインで購入することができる」というユーザストーリーはユースケースによく似た利用に即した要求表現ですが、「成績証明書は標準のブラウザを使ってオンラインで見ることができる」はむしろ技術要求事項に近いものです。「ユーザストーリー」という名前は「ユースケース」に似ているので、ユーザストーリーとはユースケースを小さくしただけのものだと思われがちですが、実際のところはそうではないということに気をつけてください。
ユーザストーリーにはわずかな情報しか含まれていないため、最初にそれを使うときには少し肉付けする必要があります。見積もり作業の時には、ユーザストーリーを実装するのに必要なプログラミング作業をリストアップするのが普通です。ユーザストーリーの実装をはじめる時には、何を構築するかの簡単な下絵(画面の絵や、関連するビジネスロジックを表すUMLアクティビティ図など)を作成することになるかもしれません。ユーザストーリーは出発点にすぎないのです。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including
The Object Primer, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since November 17, 2003.
|
