ユーザーストーリー

１日体験の講師をやった。

エクストリームプログラミングの理解度が上がった気がする。

研修中にぽーけーと考えていた事。

• ユーザーストーリーは、要件定義のシーンのみで使われるものではなく（ジョナサンの言葉を借りれば「要件定義」という言葉自体に懐疑的なのだが）、ソフトウェア開発のすべてのシーンにおける会話のきっかけのインデックスあるいは種として使われてる。記述自体には情報としての価値少ない。
• ユーザーストーリーが使われる様々なシーンで交わされるPOと開発チーム会話例を抑えること。(ストーリー収集時、リリース計画時、見積り時、順序付け時、ストーリーの分割統合時、仕様の具体例を確認している時、進捗を把握している時、デモの時、エンドユーザの評価を得る時。。。。。)
• ユーザーストーリーをきっかけに会話し、POと開発チームの会話の質、関係の質が向上し続ければ、しめしめ。カイゼン活動が動いていない場合、ユーザーストーリーを使うことで、逆に関係が悪化していくシナリオも。
• ちまたではユーザーストーリーの分割統合で困っている。(開発チーム主体で分割統合した際の副作用（POには解らないものになっている）、PO主体で分割した際の副作用（開発チームにはわからないものになっている）)
• リリース計画時、タイムボックスは副作用がある。入れる入れないで POと開発チームとの間で緊張関係が生まれがち。
• 私の思い込みだと、初期のユーザーストーリーの8割以上は残って、後から追加削除されるイメージでいたが、スタートアップ系だと、イテレーションを通じて、顧客が本当に欲しかったものが後から見つかって、初期のユーザーストーリーの半数以上を大胆に捨てるといった選択に迫られるシーンがありそう。ユーザーストーリーはピボットをできるのかな。
• ユーザーストーリーの補助資料をどこまで用意するかは悩ましい。（POと開発チームが近くにいて関係が良好の場合、画面イメージを用意しなくても、 2-4週間イテレーションでつくれる感はある。１週間だときつそう。（イテレーション開始前にホワイトボードでおおよその内容を確認し、イテレーション初期に画面イメージ と 作成した受け入れテスト条件を確認し、後半デモでEnd to Endで確認。）関係がイマイチだと、無理っぽい。週１回のミーティングだときつそう。UIイメージを用意したくなる。）

• 受け入れ条件の質-> コードの質 -> デモの成果質 -> 関係の質 -> 会話の質 -> 受け入れ条件の質 の好循環サイクルを作れれば良いんだ。