いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる。ユースケースとユーザーストーリーについての説明がすごい腑に落ちたので勢い余って書き付けるもの。アジャイル開発プロセスとユースケースの関係について。
- ソフトウェア要求 第3版に関する他の記事はこちら
ユースケースとユーザーストーリー
ユースケースとユーザーストーリーは、非常によく似ている。両方ともに、異なる種類のユーザーが、ソフトウェアシステムとの相互作用を通じて、何を成し遂げる必要があるかを理解しようとしている。しかし、この2つのプロセスは、図に示すように、似たような出発点から始まって、異なる方向に進んでいく。
ソフトウェア要求 第3版 第8章 ユーザー要求の理解
ユーザーストーリーはユースケースの簡略バージョン、というイメージを少し持っていたけれどもそれだけではないことがよくわかる。しっくりきた。
複雑さとユーザーストーリー
「アジャイルソフトウェア要求」では二つをソフトウェアの複雑度によって使い分けるように、と書かれている。これはその通りであるけれども、前述のソフトウェア要求の説明を踏まえたほうがより深く理解できる。
ユーザーストーリーは、確かに扱いやすいものであり、小さなユーザーストーリーはアジャイル開発を特徴付ける極端な漸進主義を我々が推し進めることを助ける。
しかしながら、複数の他のシステムから構成されるシステムや、ハードウェアデバイスとソフトウェアコンポーネントを含むシステム、ユーザーにさらに高い価値を提供するために連携する複数のアプリケーション群のような複雑なシステムに事が至ると、ユーザーストーリーで賄えるというのは言いすぎになる。ここでは、フィーチャーもユーザーストーリーもこの複雑な集約された振る舞いを記述するのには不十分である。これらのシステムでは、複数のアクターの間のやり取りと、この振る舞いを届けるために連携する様々なシステムを記述するためのものが必要になる。こうした場合、我々はユースケースとユースケースモデリングを主たる要求発見テクニックとして適用することをお勧めする。これは非常に重要な手段なので、第19章をまるまるこの方法の説明に充てる。
アジャイルソフトウェア要求 第12章 要求発見ツールキット
- タイトルレベルではユースケースもユーザーストーリーも似たようなレベルの概念である
- ソフトウェア要求に記載されている例
- ユースケース：フライトにチェックインする
- ユーザーストーリー：私は旅行者として、目的地まで飛行できるように、フライトにチェックインしたい
- ソフトウェア要求に記載されている例
- ユーザーストーリーは機能の詳細化の方向性に向いていない。複数のシステムが相互関係するような複雑なユーザーストーリーを扱うのには不向きな印象(もしくは、ユーザーストーリーを分割する)
- ユースケースは階層化した分析を表現しやすいため、複数のシステムが相互関係するようなストーリーを表現することが容易である
- もちろん本質的に分析(設計)すべき事項は同じだから、どちらの手法を使おうとも表現方法の問題とも言える。ただユーザーストーリーを選択すると、いろいろと現場で工夫をする必要があるのが大変そう。
最近出たこの書籍ではどんなことが書いてあるのが興味があるが、未購入。
ユースケース 2.0
ユーザーストーリーとユースケースのよいところをうまくミックスした「ユースケース2.0」という手法もあるようだけれども、これはどうだろう。
ユースケースを「断片ユースケース」に分割して、それぞれの「断片ユースケース(Use-Case Slice」が1つのユーザーストーリーに相当するに使うといった手法のようだ。ちょっと工夫をしすぎている気もする。
たしかに、アジャイル開発で扱うにはユースケースは大きくなりがちで、1イテレーションに収まらない場合も多いのでこういった工夫がアリのような気もするけど、単純に断片化するだけではなく「正常系」「異常(例外)系」といった分割の方法もあるような気がする。
