ユーザーストーリー – 明日の予習

明日はアジャイルサムライ読書会に参加予定。
ということで、たまには予習をしながらブログを書いてみるなど。

まず最初に、文書化の難しさ。

大量のドキュメントを作ったところで、時間が経てばやりたいことも変わってくるし、人が書いた文書を正しく理解するのは難しい。あるいは文書で他人に正確にものごとを伝えるのもなかなか難しい。

「要件」を信じない。

要件定義にかかれている項目のうち80%は必須ではない?
(参考文献 XPエクストリームプログラミング入門 第2版
必ず実現しないといけないことと、そうでないことの切り分けをしないまま「要件」としてまとめてしまっているので、本筋が見えにくい、という感じかな。

そこで「ユーザーストーリー」

インデックスカードに書き出す。
フィーチャーの本質となるキーワードを書く。
わかりやすくシンプル。
ぱっと読んでおいしいと思えるもの。

「6つの要素」

Independent, Negotiable, Valuable, Estimatable, Small, Testable

ユーザーストーリー vs 要件定義書・仕様書

「要件定義」はそれを作る時点での情報を固定化してしまうところを問題視している感じ。
それにくらべてユーザーストーリーは柔軟で無駄がない。

ユーザーストーリーの「テンプレート」

だれのためのストーリーで
なにをしたいのか
なぜそうしたいのか

そして「ストーリー収集ワークショップ」の開催

フィーチャーリストの作成。
ワークショップでは開発チームと顧客が一緒になってユーザーストーリーを書く。

と、こんな感じの内容です。

アジャイルサムライ読書会#7のふりかえり

先週末の9月1日にアジャイルサムライ読書会#7に参加しました。内容はインセプションデッキの後半(5.2~5.5)でした。

5.2「夜も眠れなくなる問題は何だろう?」
 プロジェクトが進みだすと、不安なことがあっても口に出しにくかったり、質問しにくい雰囲気になったりしますよね。どうしようもなくなって「実は…」となるよりは最初からそういう要素を洗い出して明記して共有すること。

5.3「期間を見極める」
 開発プロジェクトの期間は6ヶ月以内がのぞましい。もちろんあらゆるプロジェクトが6ヶ月でできるわけではないが、3ヶ月あるいは6ヶ月といったできるだけ短い期間におさまるように分割して計画を立てる。

5.4「トレードオフ・スライダー」
 あらゆるプロジェクトは次の4つのフォース(力)によって統治される。

  1. 時間
  2. 予算
  3. 品質
  4. スコープ

言い替えれば大きく4つの制約があるということ。
この時間、予算、品質を動かすことができないとすれば、調整可能な要素はスコープ(範囲)のみ。
「どれも最優先」とか「これとこれは同じレベル」というのは禁止。
このルールによって諦めるものを明確にすることができる。
あと、上記の4つ以外でプロジェクトの重要な要素をスライダーの項目に追加する。
顧客と共にスライダーを設定する。

5.5「何がどれだけ必要なのか」
期間、メンバー、予算。
この部分はいろいろ議論がありました。
そもそもメンバーは社内で手が空いている人で、おのずと決まっているとか、
予算も期間も決まった後でアサインされて、そこから作業規模を洗い出したところでどうにもならない、など。
日常の仕事を考えれば、確かにそのような状況が一般的かも知れませんが、
新たなプロジェクトに対してチームを編成することを考えると、果たしてそれでプロジェクトがうまく行くのか。
まったくリソースが足りてないところで、無理やりチーム編成をして進めてしまっているのではないか。
とても考えさせられる内容でした。
単価の話もしました。その場では「上流だったらこれぐらいかなぁ」という話もありましたが、後で考えてみると上流とか下流という時点でアジャイルではないようにも思いました。

さて、次回のアジャイルサムライ読書会は10月6日(土曜日)の予定です。
http://agile459.doorkeeper.jp/
随時 #agile459 というハッシュタグでTwitterで情報が流れていますのでよろしければご利用ください。

それと補足の資料。

読書会の中で「そもそもウォーターフォールって…?」のような議論があったので、
前にForkwellで見かけた記事を貼っておきます。
“History of Waterfall”