Readingagilesamuraiinhde20130903

範囲：P.101-124

第6章 ユーザーストーリーを集める

文書化が上手く機能したことはない (P.101)

• 文書のみでやりとりするのではなく、ワークショップを行うのは有効
• 重厚な文書を作ることを目的とするのでは上手くいかない ** 要求定義書を成果物とするのではない
• がっちり決めて文書化するのではうまくいかない

エンドツーエンド、分かりやすく言うならケーキをスライスするように・・(P.108)

• 全然分かりやすくない！（イラッ）
• 一部の方の層の話だけではダメ
• 使う部分から中身まで含んだ話でないとダメ

わくわくするようなストーリーを書こう (P.108)

• その通り！
• 技術屋的なストーリーでは面白くない
• 「誰に対して」ということを考えるのは大事
• この段階で「処理何秒」というレベルまで決められるもの？ ** あくまでお互いのイメージを合わせておくレベル
• INVEST ... 現状は「価値のある」という部分ができていないと思う

今の時点で優先すべきは幅だ (P.121)

• 細かい実装を考えるよりは、ユーザが必要とすることを出来るだけ多くとっておく
• ブレインストーミングで色んな所を考えておくのは大事

私は彼女がお金を盗んだとは言っていない (P.104)

• 面白い例
• 「彼女が盗んだのは・・私の心です」（銭形！？英語では？）
• どの業界でも人と人が話すということは重要 ** 営業成績の統計データで、お客さんと接している時間が長い人の方が成績がよい

ユーザーストーリーを集める (P.101)

• 「どうやって」が結局わからなかった
• 信頼 → P.103 Face to face で行うこと。文書のみだと信頼がない
• 新鮮 → 「重厚な仕様書」を時間かけて作らないこと
• ユーザーストーリー集めは、1回だけでなく、継続的に行う→新鮮

全体像をつかむこと (P.118)

• ユーザーストーリーを集める目的 ** 色々でてきて期待のマネジメントが大変そう

インデックスカードには簡潔にしか記述しない

• 本質＋会話が必要となるので、よいアイデア

ユーザーストーリーのテスト (P.116)

• 新鮮な考え方
• テスト可能な状態に書き換える
• 製品の機能テストに落とし込める

リストを磨き上げる (P.122)

• ユーザーストーリーリストの成果物としては、ToDoリストをまとめたもの（シンプル）

• Pivotal Tracker http://www.pivotaltracker.com/