振る舞い駆動開発（BDD）を知るために、以下の本を読んだ
振る舞い駆動開発（BDD）は、ビジネスチームとデリバリーチームが協調してソフトウェア開発を行うためのアジャイルなアプローチらしいが、
ビジネスチームとデリバリーチームが協調というのがもうすでに良い
何をやるにも最近はステークホルダーとの協業ができていないと何事も先に進めないと感じている
BDDは、システムの振る舞いに明確な具体例を用いることで、要件のあいまいさを排除し、共通理解を深めることを行う手法
要件とソフトウェアの間に存在する「具体例」という架け橋がこれまでのソフトウェア開発に欠けていたので、具体例を使おうというのが特徴
具体例の抽出には実例マッピングなどの手法を用いて、構造化された会話を通じて行われる
そして、抽出された具体例というは、コンテキスト、アクション、結果の3つの要素で構成されているものらしい
以下は、本の各章のまとめ
■ 第１章 BDDとは何か
第１章ではBDDとは何か、どのように機能するか、テストとの関係、そしてBDDがもたらす利点について説明されている
概要
- BDDは、ビジネスチームとデリバリーチームが協力してソフトウェアの動作を定義する、アジャイルソフトウェア開発へのアプローチの1つ。明確な具体例を用いて要件を明確化し、誤解を減らすことを目的としている
- BDDでは、具体例を用いてユーザーストーリーを詳細に定義することから始める。 具体例とは、「Peterはオフィスにいるのに、マルゲリータのピザを誤って自宅に注文したとします。」のように、特定の状況におけるシステムの動作を具体的に記述したもの
- 具体例は、Given/When/Thenキーワードを使ってシナリオとして記述される
- シナリオは、アプリケーションコードの一部と見なすことができ、アプリケーションの特定のバージョンの検証に使用される
- BDDは、テスト駆動開発（TDD）を補完するものであり、置き換えるものではない。TDDはコードレベルの設計を重視するのに対し、BDDはビジネス要件を満たすソフトウェアの設計を重視する
- BDDの利点には、開発者、テスター、ビジネス担当者の間で共通理解を促進すること、開発の早い段階でフィードバックを得られるようにすること、分かりやすいドキュメントを作成できることなどが挙げられる
- BDDは、従来のテストに取って代わるものではなく、補完するもの。BDDは、テスターが要件の議論に参加し、明確な具体例を作成することで、バグの発生を未然に防ぐのに役立つ
- BDDでは、誰もが理解できるユビキタス言語の使用を推奨している。ユビキタス言語とは、ビジネス用語と技術用語を統一したもので、チーム内でのコミュニケーションを円滑にするのに役立つ
- BDDでは、シナリオを生きたドキュメントとして使用する。 生きたドキュメントとは、常に最新の状態に保たれたドキュメントのことで、シナリオが自動化されると、シナリオの実行結果がドキュメントの一部となる。
3つのプラクティス
BDDは以下の3つのプラクティスで構成される
- 発見
- 定式化
- 自動化
発見とは、協調作業と構造化された会話によって共通理解を確立すること
定式化は、システムの振る舞いの例を、シナリオの形で文章化すること
自動化は、システムの振る舞いを検証できるようにするためにシナリオを自動化すること
この順番行うことが重要で、どれが欠けてもならないと説明されている
BDDのメリット
- BDDのテストが成功すると、開発チームはビジネスが求めているものをデリバリーしたことを確信できる
- テストはコードを変更する時に開発チームにとってのセーフティネットになる
- テストは生きているドキュメントを形成し、最新であることを保証する
TDDとの違い
TDDとの違いは、テストのシナリオがより抽象度が高いレベルで表現されることが多いが、サイクルは基本TDDと一緒
- 開発者へ、実装の正確さに関するフィードバックを提供
- プロダクトオーナーへ、解決策に関するフィードバックを提供
- ビジネスアナリストが既存の機能を理解するのに役立つ、実装済みの振る舞いについて説明できる
- フィーチャーをテストする準備ができていることを、手動の探索的テスターにお知らせる
- 開発者にセーフティネットを提供し、変更による望ましくない副作用を特定できる
- サポートチーム向けのアプリケーションの詳細なドキュメントを提供できる
- 誰もが理解できるドメイン言語を定義する
■ 第２章 構造化された会話
第2章では、「発見」のプラクティスについて具体的な手法である「実例マッピング」と、要件ワークショップを効果的に行うための「構造化された会話」を用いて解説している
実例マッピングは、Matt Wynne氏が提唱する要件ワークショップの手法
この手法では、色分けした付箋を用いて、ユーザーストーリーを、ルール（受け入れ基準）、具体例、疑問点に分解していく
- 黄色の付箋: ユーザーストーリーを記述
- 緑色の付箋: 具体例を記述
- 青色の付箋: ルール（受け入れ基準）を記述
- 赤色の付箋: 疑問点や仮説を記述
実例マッピングでは、これらの付箋をテーブルなどの上に並べながら、チーム全体で議論を進める
付箋を視覚的に配置することで、議論の内容を共有しやすくなるだけでなく、議論が堂々巡りになることを防ぐ
構造化された会話とは、あらかじめ定義された形式に準拠することで、円滑なアイデアの交換を促進する会話方式
要件ワークショップにおいて、以下の5つの特徴を持つ会話を「構造化された会話」と定義している
- 協調作業: 全員が積極的に議論に参加している
- 多様な視点: ビジネス担当者、開発者、テスターなど、様々な視点を持つ人が参加している
- 短い: 集中力を維持するために、1回のワークショップは30分以内に収めることが推奨されている
- 進めることに焦点を当てる: 議論の内容を記録し、共通認識を形成しながら進める
- コンセンサス: アウトプットの正しさ、フィーチャーの理解度、隠された知識がないこと、疑問点への対応などを全員が合意する
■ 第３章 具体例とは何か？
第3章では、具体例の役割と、効果的な具体例を作成するためのアドバイスがされている
- 具体例の構成：具体例は、「コンテキスト」、「アクション」、「結果」の3つの部分で構成される
- コンテキスト: アクションが実行される前のシステムの状態
- アクション: 振る舞いを引き起こすイベント
- 結果: 振る舞いが発生した後のシステムの状態
- 具体例のレベル：具体例は明確かつ具体的であるべきだが、すべてのコンテキストデータを指定する必要はない。振る舞いに直接関連する具体的なデータのみを含めるべき
- 具体例の数：ルールを明確にするのに十分な数でよい。すべてのプログラミングミスを捉えるために、考えられるすべての組み合わせを網羅する必要はない
- ルールとの使い分け：具体例はルールを説明するが、置き換えるものではない。ルールは抽象的な説明を、具体例は具体的な説明を提供する
- 複数のルールに関連する具体例：1つの具体例が複数のルールを表すことがあるが、ワークショップでは、それぞれが1つのルールに焦点を当てているかを確認することが重要
- 全体像の把握：システム全体の動作の概要を示すには、ワイヤーフレームやページフローなどの他のドキュメントも有用
■ 第４章 誰がいつ何をするか
第4章では、BDDをさまざまな開発プロセスに統合する方法を解説し、具体的なタスク、役割分担、期待される結果について説明している
まず、BDDアプローチ全体のワークフローを、8つの主要なタスクとアクティビティに分解して示す
- ユーザーストーリーを選ぶ: 要件を明確化し、優先順位を決める
- タイミング: 要件ワークショップの前
- 担当者: プロダクトオーナー、ビジネスアナリスト、顧客、主要なステークホルダー
- 結果: 明確な具体例を用いて範囲を調査できるレベルまで詳細化されたユーザーストーリー
- 要件ワークショップ: ルールと具体例に焦点を当て、ユーザーストーリーについて議論する
- タイミング: プロジェクト全体を通して定期的に開催
- 担当者: ビジネス、テスト、開発チームの代表者（スリーアミーゴス）
- 結果: ルールと具体例とともに、洗練されたユーザーストーリー
- 定式化する: 具体例をシナリオに落とし込む
- タイミング: ストーリーの実装開始前
- 担当者: チーム全体、または開発者とテスターのペア
- 結果: ソース管理可能な、ビジネスチームにとって読みやすいシナリオ
- レビュー: シナリオが期待するビジネスの振る舞いを正しく説明しているかを確認する
- タイミング: シナリオの作成または変更時
- 担当者: プロダクトオーナー、ビジネスアナリスト、顧客、主要なステークホルダー
- 結果: ビジネス要件に対する共通理解と、適切な用語を用いたシナリオの表現
- 自動化: シナリオを自動化するためのテストコードを記述する
- タイミング: 実装開始前（テスト駆動のアプローチ）
- 担当者: 開発者またはテスト自動化の専門家
- 結果: ローカル環境とCI環境で実行可能な自動化されたシナリオ
- 実装: 自動化されたシナリオが成功するようにアプリケーションコードを実装する
- タイミング: 最初のシナリオが自動化された後
- 担当者: 開発者
- 結果: 指定どおりに動作し、自動的に検証可能なアプリケーション
- 補足的なテスト: テスト戦略に基づいた、手動テストやその他のテストを行う
- タイミング: シナリオが完了した後
- 担当者: テスター
- 結果: 高品質なアプリケーション
- リリース: 出荷可能なインクリメントを生成する
- タイミング: すべてのテストが成功した後
- 担当者: 開発チーム
- 結果: インストール可能なリリースパッケージ
あとは、このBDDアプローチを、
- スクラム
- リーン/カンバン
- 分散型チーム
- スコープを固定したプロジェクト
- 規制された環境でのプロジェクト
といった、異なる開発プロセスや環境に適用した具体的な例を挙げて説明している
第５章 ビジネスチームのメンバーを参加させる方法
第5章では、BDDへのビジネスチームの巻き込み方、特に彼らが直面しがちな課題とその解決策に焦点を当てている
BDDはチーム全体の協力が不可欠だが、ビジネスチームが参加したがらない、あるいはどのように参加すればよいかわからないケースがある
その原因として、現状維持を望む、BDDをオーバーヘッドと捉える、学習コストやインフラコストを懸念する、チームとの間に距離がある、BDDを単なるテスト手法と誤解する、といった点が挙げられる
ビジネスチームを巻き込むための鍵は、BDDが彼らの問題を解決し、開発を効率化し、より良い結果をもたらすことを示すこと
そのためには、まず現状のプロセスにおける課題や機会を明確にする必要がある
例えば、プロダクトオーナーの負担軽減という課題に対して、BDDでは要件ワークショップへの参加、シナリオのレビュー、実装されたアプリケーションへのフィードバックといった役割が期待される
従来の開発プロセスと比較すると、BDDでは協調やレビューに時間をかける一方、同じ内容を何度も議論する必要がなくなり、作業がチーム全体に分散される
他にも、本番環境での問題、デリバリーの難航、顧客の反応の悪さ、締め切りの超過、進捗状況の把握の難しさ、予期せぬ副作用、バグか機能かの議論、レビュー時の要求変更など、さまざまな課題に対して、BDDは具体的な解決策を提供する
ビジネスチームがシナリオを読んでくれない場合、シナリオへのアクセスしやすさ、表現の分かりやすさ、情報の見つけやすさなどを改善する必要がある
彼らが生きているドキュメントを効果的に使えるようになるまで、辛抱強くサポートすることが大切である
ビジネスチームをBDDに巻き込むためのヒントとして、開発者専用/テスター専用のBDDを一時的な解決策と捉える、シナリオをビジネスの具体例として考える、要件の議論を具体例に集中させる、結果と方法を定期的に提示する、といった点が挙げられている
最終的には、ビジネスチーム自身がBDDの価値を理解し、積極的に参加してくれることが重要
