アジャイルサムライ横浜道場 「ユーザーストーリーを集める」に参加しました

2014/9/9(火) アジャイルサムライ横浜道場　「ユーザーストーリーを集める」に参加してきました。

DoorKeeper
http://yokohama-dojo.doorkeeper.jp/events/14349

以下の書籍をターゲットとした勉強会？なのです。

アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る

場所はいつもの横浜、西公会堂　2号会議室です。
参加者は16人くらいかな。通常回にしては多かったですね～

今回は道場主曰く、「ディスカッション自体が参加への障害になっていると考え、フィッシュボール形式にしてみた」とのこと。フィシュボールって単語、初めて聞いた・・・

フィッシュボールとは
http://biz-trend.jp/kenshu/words/fishball/

机を全部部屋の後ろに追いやって、全員、部屋の前に椅子を寄せあってディスカッションする形式です。
ディスカッションを始める前に @trtraki さんによる第6章「ユーザーストーリーを集める」の発表がありました。

【アジャイルサムライ】6章_ユーザストーリーを集める from trtraki

@trtraki さんが出してくださったディスカッションのお題は以下のとおり。

【6章】アジャイルサムライ お題 from trtraki

その後のディスカッションでは、スタッフさんが議論内容を随時、部屋の前のホワイトボードに書いてくださいました。


取った写真を横浜道場のFacebookに投稿しようと思ったが、ホワイトボードが反射してよく読めないので、そのまんま書き起こしてみる。。。
（参加してない人が読んでも何のことやらわかんないと思います）

---

■ホワイトボードのメモ

• 要件の洗い出し方は？
  • ドラマ仕立てにして要求を出している。ユーザと直接話すこともある。
• 何が重要かを聞いて、要求を組み立ていく。その時にコスト面も話す。

---

• 企画の段階でプロダクトオーナーが入って、その人がストーリーを書き出す。
  • ただし開発側もストーリーを出したりする。

---

• ワークショップで見積もりはやってる？
  • ワークショップで見積もり直す。きちんと見積もりを分ける。
• ストーリーだけだと見積もりしづらい？
  • →　細分化して見積もる。

---

• ユーザーストーリーに近いものを書いている。
• Whyは必ず聞いている。　→　代案を提案できる

---

• ユーザストーリのテンプレートを最初は使っている。
  • 慣れてくるとシンプルなストーリーとしている。（プロダクトを理解してきたから）

---

• テンプレートのユーザは重要？
  • →　デザイン的にユーザが触ると作りやすい。

---

• 要件を出す時に理由を重視する。
  • XDDPがいい？
  • 情熱が重要。

---

• 企画はもっとグイグイ来て欲しい。
• 上から言われたから、というのが多い。
• 仕様書の行間が読めない。
• 「なぜ？」の深堀りは2回までが限界？
• 何故何故というより、お客さんは提案してほしいのかも？
• 「ですよね？」と聞くより「ですか？」と聞いたほうが良い。
• ある程度こちらから選択してあげるようにしている。
• 企画と開発が分断される事が多かった。これを解決していきたい。
• 交渉の余地があるとは？　→　より良い手段が提案しやすい。
• 仕様書があいまいでもOK？
  • Howの部分が固定されるとやりにくい
• テーマは、いくつかのストーリーをまとめたもの。
• エピックは、もやもやしたストーリー？（スプリント内に収まるか怪しいもの）
• INVESTの1と3と5を押さえると見積もりやすい。
• 小さくすると見積もりがしやすい。
• INVESTの4と5は関係あり。
• INVESTのValuable（価値がある）とは？
  • 作って客が嬉しい
  • 作る理由が見えている
• INVESTの1と6が大切。検証が出来る。
• PKG開発で、INVESTの3が客の声でコロコロ変化した
• 目的を持ってない人
  • 何でするのかを考えていないので無駄な作業をしている
  • INVESTの3の価値を考えていない人

---

最後の振り返り

---

今回はいつものやりかたと違ったので新鮮でした～
スタッフさん、参加者のみなさん、ありがとーございました。