アジャイル開発におけるユースケース駆動の要件定義手法～ユースケース2.0

InfoQのユースケース2.0の記事をリンクしておく。

【元ネタ】
アジャイルでユースケースを利用する - ユースケース2.0，スライシング，ラミネーティング

背景はこうだ。
従来の要件定義は、プロジェクト初期段階で、クライアント、ビジネスアナリスト、プロダクトオーナーが議論して要件を確定し、要件定義書を完成させる。
その要件定義書を開発チームに渡して、WF型開発で滝が流れる如く開発していく。

アジャイル開発の時代では、要件定義はプロジェクト初期段階に限定しないし、少数のモデラーやアナリストだけに限定しない。
必要十分な要件定義になるように、詳細が必要になった時にドキュメントを作る。
すると、アジャイル開発で使われるロードマップ、バックログに要件をリンクさせる要件定義手法が必要になってくる、と。

ここで、ユースケースは、オブジェクト指向分析・設計技法で要件定義の肝となる手法。
しかし、個人的には、ユースケースは余り役立った経験がない。
ユースケース図は、Excelの機能一覧、要件一覧と同じであるに過ぎず、情報量が少なすぎる。
ユースケース定義書は、重量すぎて、無駄なOffice文書を大量に発生させる。
その修正コストは結構大きい。

InfoQの記事では、アジャイル開発で使われるバックログに使えるようなユースケース定義手法を模索しているようだ。
詳細はよく分からないが、ユースケース簡易版を使って、バックログに入れるストーリーカードを代用しているように思える。

個人的には、ImpactMappingを使って、アクターから利用シーンを導き出し、要件を抽出する方が、もっと簡単に開発チームにその意図を伝えられると思う。