BDD in Action 2nd Edition 第5章
5章を読み終えましたので、学んだことをまとめてみます。
5章は、BDDの活動サイクルの中の Illustrateフェーズでの作業として、3〜4章の Speculateフェーズで特定し、詳細化したフィーチャー、あるいはユーザーストーリーを明確にしていきます。
フィーチャーの内容を明確にするための手段は「例を使ったビジネス側との会話」です。
例を使って話し合う
話し合いは、ユーザやステークホルダーも参加して、フィーチャーの受け入れ基準を理解し、定義し、合意していく。
話し合いでは、良く適切な質問ができなかったり、脱線したりして、思うように進まずに長引くことがある。
フィーチャーに対して、ビジネス側の言葉を使った例で説明することで、話し合いが円滑に進む。
例を使って話う会う時は反例も出すことで矛盾や誤解を知り、不確実なことを洗い出して明確にすることができる。
例を使って理解したことを確認したり拡張したりするために追加の例を使う。
表を使って例を整理する
表はインプットと期待する結果が簡単に説明できるような要件に適している、データ中心的なアプローチ
デシジョンテーブルを作るイメージ。だけどこの段階では網羅することよりも要件の理解を優先する
実例マッピング (Example Mapping)
フィーチャー（ストーリー）に紐づくビジネスルールや制約、そしてルールに対する例と反例のリストを特定していく。
目的は、フィーチャーやルール(受け入れ基準)の共通理解を得ること
挙げられたルール、または例の数が多いと、フィーチャーが大きいか、複雑なことを示していて分割した方が良いかもしれない。
話し合いは一つのフィーチャー（ストーリー）に対して、25-30分のタイムボックスで行い、そのフィーチャーに集中する。
話し合いの最後に「作業を始めるために十分な理解を得られたか？」「更に話し合う必要があるか？」を投票して決める。
話し合いで回答できない例や質問は、別に記録しておいて、その話し合いではそれ以上議論しないようにする。
例を追加していく時は「もしこうだった場合は？」「そのルールはいつもそうなのか？」「ルールが適用できない場合はあるか？」などの視点で質問すると良い。
フィーチャーマッピング
大きく、不明確なフィーチャーに適している。
実例マッピングと違う点は「例をステップ単位に分けて説明する」「ステップの最後に期待する結果となる結論(Consequence)を書く」などがある。
実例マッピングが「ビジネスルールを基に例を挙げていく」ように進めるとしたら、フィーチャーマッピングはどちらかといえば「ストーリーから想定される例を上げていって、ビジネスルールや制約を特定する」ようなイメージに読み取れた。
フィーチャーマッピング自体は、大きなフィーチャー（あるいはエピック）をルールや制約単位に分割することも目的の一つのなので、その後実例マッピングを使って理解を深めていくと良さそう。
スリーアミーゴス
例を使った話し合いでは、テスター、プロダクトオーナー (ビジネスアナリスト)、開発の3つの役割を持ったメンバーがそれぞれの視点でルールや例を質問していくと良い。
テスターは、細部に注意を払い、検証することに着目して、エッジケースなど見落としがちなシナリオを指摘する
プロダクトオーナー は、ビジネス視点の妥当性や相対的な価値に着目して、シナリオを指摘する
開発者は、技術的な検討事項を指摘する。
まとめ（感想）
顧客と要件定義を行う時に、わからないことがあれば例を使って話し合うことがたまにあったが、それを意図的に利用して要件の理解を深めることが目的。
付箋あるいはホワイトボードツールを使って、ルールと例を整理する。
ここで作ったルールや例のうち主要なものは、Gherkinのシナリオ(Given...When...Then)として使うことになる。だけどこの時点ではそれを意識して書く必要はない。実際このフェーズで上がった例のほとんどはシナリオとしては使わないらしい。
この5章は、初版には載っていなかった（あるいは前後の章の中で少し触れていた程度だった）が、2nd Editionになって、「フィーチャーやストーリーを定義する」と「Gherkinのためのシナリオファイルを書く」の間にこの章が作られたことを考えると、これまでフィーチャーからシナリオファイルに変換する作業が難しかったので、例を用いた様々なテクニックが使われるようになったのかなと推測した。
次の6章は、要件定義について解説した第2部の最後に当たり、成果物としていよいよシナリオを書いてFeatureファイルを完成させていくようなので楽しみ。
