アジャイル開発におけるユースケース駆動の要件定義手法~ユースケース2.0
InfoQのユースケース2.0の記事をリンクしておく。
【元ネタ】
アジャイルでユースケースを利用する - ユースケース2.0,スライシング,ラミネーティング
背景はこうだ。
従来の要件定義は、プロジェクト初期段階で、クライアント、ビジネスアナリスト、プロダクトオーナーが議論して要件を確定し、要件定義書を完成させる。
その要件定義書を開発チームに渡して、WF型開発で滝が流れる如く開発していく。
アジャイル開発の時代では、要件定義はプロジェクト初期段階に限定しないし、少数のモデラーやアナリストだけに限定しない。
必要十分な要件定義になるように、詳細が必要になった時にドキュメントを作る。
すると、アジャイル開発で使われるロードマップ、バックログに要件をリンクさせる要件定義手法が必要になってくる、と。
ここで、ユースケースは、オブジェクト指向分析・設計技法で要件定義の肝となる手法。
しかし、個人的には、ユースケースは余り役立った経験がない。
ユースケース図は、Excelの機能一覧、要件一覧と同じであるに過ぎず、情報量が少なすぎる。
ユースケース定義書は、重量すぎて、無駄なOffice文書を大量に発生させる。
その修正コストは結構大きい。
InfoQの記事では、アジャイル開発で使われるバックログに使えるようなユースケース定義手法を模索しているようだ。
詳細はよく分からないが、ユースケース簡易版を使って、バックログに入れるストーリーカードを代用しているように思える。
個人的には、ImpactMappingを使って、アクターから利用シーンを導き出し、要件を抽出する方が、もっと簡単に開発チームにその意図を伝えられると思う。
| 固定リンク
« Redmineのワークフロー管理で見えるもの~いい加減なプロセスが見える化する | トップページ | ImpactMappingの感想~アジャイル開発が主流の時代のライトウェイトな要件定義手法 »
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント