アジャイルサムライ第6章ユーザーストーリーを集める

第3部第6章「ユーザーストーリーを集める」を読みます。

文書化による要求分析の問題点
- 変化に対応できない
- 顧客の要求でなく仕様に合わせて作ることになる
- 文書は誤解を招きやすい
face to face で話しあう
そこでユーザーストーリーですよ
- 実装の観点からではなくユーザの始点からのシナリオに則った機能を書く
- エンドツーエンドになっている。内部の特定のレイヤの変更に着目したものでなく、横断的に、実際のユースケースにとってどういうメリットがあるかという側面で表現する
- できるだけ独立したストーリーにする
- かけるコストの交渉の余地がある
- テスト可能
- 小さい。見積可能
実例・「ビッグウェイブ・デイブのサーフィンショップのサイト構築」
- 曖昧な要求(早く、とかカッコよくとか)を「制約」として捉える
- Who, What, Why でユーザーストーリーを書く

今日は第6章の途中までです。