BDD の実例マッピングのワークショップ

BDDのプラクティス 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 2 The BDD
Books – Discovery, Seb Rose,Gáspár Nagy, 1017

実例マッピング : Example Mapping BDDの基本プラクティス：発見（DISCOVERY) EXAMPLEを洗い出す 2024/5/30 実例マッピング COPYRIGHT ©
ATSUSHI NAGATA 3 2017

BDDのいきさつ：当初のアジャイル開発 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 4 ユーザーストーリ
開発解釈・分解設計・実装コードシステムテスト手動遅い、無駄違いが分かる

BDDのいきさつ：テスト駆動開発 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 5 ユーザーストーリ
開発解釈・分解設計・実装コードシステムテスト手動⇒自動単体自動テスト距離がある

BDDのいきさつ：BDDの誕生 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 6 ユーザーストーリ
開発解釈・分解設計・実装コード振る舞いの確認単体自動テスト具体例 Example 振る舞い Goyko Adzic 2011

BDD 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 7 BDD: Behavior
Driven Development 振る舞い駆動開発システム振る舞い Behavior 具体的な例 Specification 要求価値

BDD 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 8 BDD: Behavior
Driven Development 振る舞い駆動開発システムがどのようなふるまいをすることによって顧客が要求を満たす価値を作ることができるか system 価値を生み出すシステムの振る舞いは“なに”か：What その“なに”を、ビジネス側も開発側も共有理解したい

BDDのプラクティス 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 9 Discovery 発見
Formulation 定式化 Automation 自動化シナリオの発見コラボレーションと構造化された会話によって共有理解を確立しますシステムの振る舞いの例をシナリオの形で文書化しますシステムの振る舞いを検証できるようにするためシナリオを自動化します

Behavior 振るまい 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 10 振るまい：要求を満たすためのシステムの振るまい
⇒ Specification: 仕様ビジネス側からも開発側からも、この振る舞いを誤解なく、正確に、明確に表したい BDDの目的の一つ振る舞い具体的な例 (Example)で表してみる

Example 実例、例、具体例例をシナリオで表す ◦ Given ◦ ユーザーストーリーの初期状態またはコンテキストを記述する ◦ ストーリーのステージを設定し、開発チームが要件を理解するために必要な背景情報を提供する ◦
例：ユーザーが自分のアカウントにログインしているとします ◦ When ◦ ユーザーが取るアクションを記述する。 ◦ ストーリーのトリガーを定義し、開発チームにストーリーを完了するために何が必要かをよりよく理解させる ◦ 例：ユーザーが "Submit "ボタンをクリックしたとき ◦ Then ◦ ユーザーストーリーの結果を記述する ◦ これは、Whenの部分に記述されたアクションの結果として何が起こるべきかを定義し、開発チームに、利害関係者のニーズを満たすために何を提供する必要があるかについての明確な理解を提供します。 ◦ 例：ユーザーのアカウントが正常に更新されたことを示す確認メッセージが表示されるはずです。 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 11

BDD Given,When,Then template 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 12
システム When Then 振る舞い仕様 Specification 要求価値 Given 事前条件行動

2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 13 では、いつ、どのようにこの具体例による振る舞いを出していくか要求ワークショップにおいて
実例マッピングを行う

要求ワークショップ 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 14 定期的なミーティング（通常は週に数回）次の数スプリントで行うバックログについて議論する
目的： • ユーザーストーリの明確化 • シナリオの探索 • スコープの理解 • 具体例(Example)を挙げて明確に説明する ➢ ストーリーに関する新しい詳細を発見 ➢ すぐに答えられないような質問 ⚫ 多様な視点を結集することである ⚫ 何をなすべきかを学び、より効果的に協力し合うことである Discovery 別の名で • バックログリファインメント • スリー・アミーゴスミーティング

Living Document 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 15 BDDについて聞いたことがあるなら、おそらくリビング・ドキュメントという言葉に出くわしたことがあるだ
ろう。これは、決して古くならない、少なくとも古くなったらすぐに知らせてくれるような文書ですつまり、コードといつも同期しているドキュメントなぜなら、シナリオがアプリケーションでサポートされているかどうかを常に検証できるからです。サポートされていれば、シナリオ（のテスト）はパスします。ユビキタス言語のおかげで、ビジネス担当者であっても、私たちのソリューションがどのような期待に応えられないかをすぐに知ることができます。サイボウズでは、仕様書がLiving Documentになっている

事例ピザのデリバリ 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 17 要件ワークショップ参加者
PO、開発者2名、テスト、インターンピザ配達管理アプリケーション開発対象 PO ：ストーリーの読み上げ間違った配送先住所を修正するために、クライアントとして、注文後に配送先住所を変更できるようにしたい。 PO ：説明 • 配送先住所を変更できるかどうかを確認できる必要があります • 新しい住所が現在の住所からそれほど遠くないことを確認する必要があります、 • また、注文の状態も確認する必要があります

注意 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 18 典型的な間違いの1 つは、BDD
をツールと見なすこと Given/When/Thenのテンプレートに記入するなどの機械的なプロセスであると考えることよくある間違え具体的な例を考え出す：Discovery すべてのチームメンバーがユーザーストーリーの理解に積極的に挑戦する

具体例の収集 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 19 まずは顧客が配送先住所を変更できるようにすべきというハッピーパスからペルソナを置いてみる：Peterさん
28歳エンジニア彼は定期的に自宅とオフィスでピザを注文しています。彼はおそらく配達先住所を時々混同してしまうでしょう

具体例 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 20 • Peterさんはオフィスにいるのに、マルゲリータのピザを誤って家に注文したとします
• 注文が完了し、店舗で準備を開始します • Perterさんは数分後にメールにあるトラッキングのリンクをクリックし、配達先を間違ったことに気づきました。 • 彼はメールにあるトラッキングのリンクをクリックし、トラッキングページで「住所変更」を選択します • 彼は、配送先を職場に変更し、変更を送信します。 • 変更は受け入れられました。開発者:「数分後」とはどういう意味ですか？ PO : 注文を受けたばかりなので、ピザの準備がまだできていない時です。」 QA :ああ、わかりました。ピザがオーブンに入っているかもしれないが、配達の準備ができていない時でしょうか？ PO :ええ、そうです

具体例の付箋 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 21 Given コンテキスト
When アクション Then 結果注文の品

付箋に書いてみて 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 22 インターン: 私が気になるのは、「準備ができていない」と「準備中」どちらなのかでしょうか？
具体例のタイトルでは「準備中」と表現し、具体例の2 番目のステップでは「準備ができていない」と表現しています。開発者: これらの2 つの言葉は本質的には同じことを意味します。ピザの準備中の場合は、明らかに準備ができていませんインターン: 大学でUML モジュールの中で状態遷移図について学びました。ここで使ってみませんか？開発者: 完全なUML の状態遷移図は必要ありませんが、イベントだけでなく、状態の概要も役立つと思います

2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 24 QA では、配達員がピザを受け取るまでに、住所を変更させてみませんか。 PO
それは良いですね。実際、重要なターニングポイントは、配達員が注文したピザを受け取るときです。つまり、配送先住所を確認してルートを計画するときです QA OK。具体例の付箋を修正します

ルールから具体例を探る 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 28 QA このルールについて、他にどのような具体例がありそうですか？
反例はありますか？開発者あります！注文したピザを既に配達員が受け取っている場合は、すぐに分かるようにエラーメッセージで応答すべきです。簡単だね…… もう一人の開発者もう一人のペルソナ、林さんを考えてみましょう。彼は初めての購入者なので、配送先住所を入力する必要があります。彼が小さな間違いをした場合はどうなりますか？ PO ピザが最初の配達先住所の玄関口に既にある場合は、住所を完全に別の場所に変更させることはできません……

議論の行き詰まり 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 29 開発者遅いタイミングでの配送先住所の変更に対処する方法はたくさんあります
が、どれも単純ではありません。本当に今これを行う必要がありますか？ QA 今はこれを解決できないようです。なので赤の付箋を作成し、統計をチェックして、これが発生する頻度と、このようなミスによって発生する追加コストを確認しましょう問題点の一時的な回避策を考え出せますか？開発者エラーメッセージを変更して、お客様にオペレーターへ電話するようにアドバイスすることもできます PO とても良いですね！忘れる前に、すぐに書き残しておきましょう！

テストとBBD 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 36 Agile Testing
: Shift Left テスト（QA)の責任欠陥予防検証：欠陥検出バグを防止するためにすべてのプロジェクトのイベントの議論に参加するバグをとらえるためにプロダクトを検証する表現をより明確にするエッジケースの検討問題ユーザストーリ（要求）に対する誤解あいまいな表現要求の理解具体例エッジケース妥当なテスト設計受け入れテストリグレッションテスト探索的テスト

BDD の実例マッピングのワークショップ

BDD の実例マッピングのワークショップ

More Decks by Atsushi Nagata

Featured

Transcript