ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
要求開発アライアンス西日本勉強会#2に行ってきた。 - Fight the Future
ビジネス設計の勘所 『実践UML』などを翻訳された、依田さん。 時間短かったなあ。もっと長く聞きたかった。 ビジネス設計 = 要求開発である。 ビジョン分析をする。 プロジェクト目標設定書を作成する。 このとき、具体的な数値を設定する。 こうすることで(失礼だが)初めてお客様がイメージし始める。 要求開発の初期に作成する。 ユーザー以外の利害関係者(ステークホルダー)を調査し、意図を知る。 ビジネスのフロー、プロセスを書く。 どこから切り込めばいいか？ そのカテゴリの一般的な用語とユーザー独自の用語を対応付けて議論のきっかけにする。 フローを作成する。 ケースが多すぎて書けない？ 大抵の場合商品やユーザーで例外フローがある。 基本フローをまず押さえる。 EA(Enterprise Archtect)や旧JUDE(astah*)で清書する。 アクターを定義する。 アクターとは役割である。 シ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
