Readingagilesamuraiinhiroshima20150729 - agile-samurai-ja/support GitHub Wiki
アジャイルサムライ読書会 in 廣島道場 ２回目（第6回）
記録
２回目より「すごい広島」と共催？させていただいております、場所はムービンオンになります。 先日、すくすくスクラム広島で「見積もり」をやったのだが、そもそもプロジェクトの環境がバラバラ、想定もバラバラの状態では田原義彦よろしく話にならない（わかる人には分かって欲しいw）。読書会とは別だが、あちらではエンタープライズアジャイルを主としての勉強会に持っていきたいということになった。西本さんが加わってくれました。
第３部 アジャイルな計画づくり 99
第６章 ユーザーストーリーを集める 101
ユーザーストーリーの書き方は実は難しい。ユーザーの（理解できる）言葉で表現し、なおかつ客観的な表現でないと曖昧になってしまう。 要求の集め方ということは、要求開発に近いことを想定している。そしてアジャイルな計画の部分までを想定しながら進めることが重要で、スムースに最初のイテレーション（スプリント）に入れるかどうかが掛かっている。
6.1 文書化の難しさ........................... 101
仕様凍結の頃に初めて顧客が要求しているものがわかり始める（プロジェクトあるあるネタ） アジャイル開発の原則「情報を伝える最も効率的で効果的なことはFace to faceで話をすることです。」今でもそうだろうかチャットワークやSlackなどは、そこを何とかしようとしている。
6.2 そこでユーザーストーリーですよ ................. 105
インデックスカードに記載するユーザーストーリーだと詳細は顧客との会話の中に埋もれてしまう。この段階ではフューチャーの本質を捉えるキーワードを書き留めておくこと。記憶を共有するのは、もう少し先の分析と設計：作業の段取りまでで良い ユーザーストーリーは「会話の約束」、この段階では詳細な話は行わずに、ビジネス上の必要性などを理解する。
6.3 よく書けているユーザーストーリーとは.............. 107
顧客にとって何かしらの価値が書かれていること（ビジネスの観点から評価できるように顧客に理解できる言葉での表現に限られる） お客さんがワクワクするようなストーリーを書こう、感性のストーリーを考えよう。 独立している、交渉の余地がある、テストできる、小さい見積もれる。 制約のストーリー、色を変えて作ると良い。 WHO,WHAT,WHY 誰のための、何をしたいのか、なぜそうしたいのか？
6.4 ストーリー収集ワークショップを開催しよう ........... 117
１、大きくて見通しの良い部屋を用意する。 ２、図をたくさん描く（ペルソナはこの段階で） ３、ユーザーストーリーをたくさん書く、大きなストーリーをエピックという ４、その他もろもろをブレインストーミング、データ移行、負荷テスト、本番環境運用手順書など ５、リストを磨きあげる、まだプロジェクトの計画を立てる段階ではない
フューチャーとストーリーとエピックの関係がわからない。 ストーリー＜エピックである、フューチャーはタスク洗い出しをしてからできるものかも （リリースプランニングのためのアジャイルな見積もりではフィーチャーをビッグストーリーと呼んでいる） 要件定義が文書で出てきてやることもある、文書だけじゃなくてドロップボックスごと渡されることもある。
忘れないためのメモ、次回は付箋を用意して各自記入するようにする。