アジャイル開発におけるユースケース駆動の要件定義手法~ユースケース2.0
InfoQのユースケース2.0の記事をリンクしておく。
【元ネタ】
アジャイルでユースケースを利用する - ユースケース2.0,スライシング,ラミネーティング
背景はこうだ。
従来の要件定義は、プロジェクト初期段階で、クライアント、ビジネスアナリスト、プロダクトオーナーが議論して要件を確定し、要件定義書を完成させる。
その要件定義書を開発チームに渡して、WF型開発で滝が流れる如く開発していく。
アジャイル開発の時代では、要件定義はプロジェクト初期段階に限定しないし、少数のモデラーやアナリストだけに限定しない。
必要十分な要件定義になるように、詳細が必要になった時にドキュメントを作る。
すると、アジャイル開発で使われるロードマップ、バックログに要件をリンクさせる要件定義手法が必要になってくる、と。
ここで、ユースケースは、オブジェクト指向分析・設計技法で要件定義の肝となる手法。
しかし、個人的には、ユースケースは余り役立った経験がない。
ユースケース図は、Excelの機能一覧、要件一覧と同じであるに過ぎず、情報量が少なすぎる。
ユースケース定義書は、重量すぎて、無駄なOffice文書を大量に発生させる。
その修正コストは結構大きい。
InfoQの記事では、アジャイル開発で使われるバックログに使えるようなユースケース定義手法を模索しているようだ。
詳細はよく分からないが、ユースケース簡易版を使って、バックログに入れるストーリーカードを代用しているように思える。
個人的には、ImpactMappingを使って、アクターから利用シーンを導き出し、要件を抽出する方が、もっと簡単に開発チームにその意図を伝えられると思う。
| 固定リンク
« Redmineのワークフロー管理で見えるもの~いい加減なプロセスが見える化する | トップページ | ImpactMappingの感想~アジャイル開発が主流の時代のライトウェイトな要件定義手法 »
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
「Agile」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- 沢渡さんの資料「テレワークに役立つ8つのスキル」はいいね(2021.04.04)
- 要件定義プロセスはDXで終焉するのか(2021.04.01)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
コメント