アジャイル開発におけるユースケース駆動の要件定義手法~ユースケース2.0
InfoQのユースケース2.0の記事をリンクしておく。
【元ネタ】
アジャイルでユースケースを利用する - ユースケース2.0,スライシング,ラミネーティング
背景はこうだ。
従来の要件定義は、プロジェクト初期段階で、クライアント、ビジネスアナリスト、プロダクトオーナーが議論して要件を確定し、要件定義書を完成させる。
その要件定義書を開発チームに渡して、WF型開発で滝が流れる如く開発していく。
アジャイル開発の時代では、要件定義はプロジェクト初期段階に限定しないし、少数のモデラーやアナリストだけに限定しない。
必要十分な要件定義になるように、詳細が必要になった時にドキュメントを作る。
すると、アジャイル開発で使われるロードマップ、バックログに要件をリンクさせる要件定義手法が必要になってくる、と。
ここで、ユースケースは、オブジェクト指向分析・設計技法で要件定義の肝となる手法。
しかし、個人的には、ユースケースは余り役立った経験がない。
ユースケース図は、Excelの機能一覧、要件一覧と同じであるに過ぎず、情報量が少なすぎる。
ユースケース定義書は、重量すぎて、無駄なOffice文書を大量に発生させる。
その修正コストは結構大きい。
InfoQの記事では、アジャイル開発で使われるバックログに使えるようなユースケース定義手法を模索しているようだ。
詳細はよく分からないが、ユースケース簡易版を使って、バックログに入れるストーリーカードを代用しているように思える。
個人的には、ImpactMappingを使って、アクターから利用シーンを導き出し、要件を抽出する方が、もっと簡単に開発チームにその意図を伝えられると思う。
| 固定リンク
« Redmineのワークフロー管理で見えるもの~いい加減なプロセスが見える化する | トップページ | ImpactMappingの感想~アジャイル開発が主流の時代のライトウェイトな要件定義手法 »
「ソフトウェア工学」カテゴリの記事
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか(2023.02.18)
- デブサミ2023の感想(2023.02.11)
- ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた(2023.02.01)
- DDPは品質管理に役立つのか(2022.12.13)
「Agile」カテゴリの記事
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
- 現代日本人の弱点はリーダーシップ不足と生産性が著しく低いこと、そしてリスク許容度が著しく低いことだ(2022.12.23)
- DDPは品質管理に役立つのか(2022.12.13)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
コメント