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

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

Transcript

1. BDD 振る舞い駆動開発 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 1
2. BDDのプラクティス 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 2 The BDD Books – Discovery, Seb Rose,Gáspár Nagy, 1017
3. 実例マッピング : Example Mapping BDDの基本プラクティス：発見（DISCOVERY) EXAMPLEを洗い出す 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 3 2017
4. BDDのいきさつ：当初のアジャイル開発 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 4 ユーザー ストーリ 開発 解釈・分解 設計・実装 コード システム テスト 手動 遅い、無駄 違いが分かる
5. BDDのいきさつ：テスト駆動開発 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 5 ユーザー ストーリ 開発 解釈・分解 設計・実装 コード システム テスト 手動⇒自動 単体自動テスト 距離がある
6. BDDのいきさつ：BDDの誕生 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 6 ユーザー ストーリ 開発 解釈・分解 設計・実装 コード 振る舞い の確認 単体自動テスト 具体例 Example 振る舞い Goyko Adzic 2011
7. BDD 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 7 BDD: Behavior Driven Development 振る舞い駆動開発 システム 振る舞い Behavior 具体的な 例 Specification 要求 価値
8. BDD 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 8 BDD: Behavior Driven Development 振る舞い駆動開発 システムがどのようなふるまいをすることによって 顧客が要求を満たす価値を作ることができるか system 価値を生み出すシステムの振る舞いは“なに”か：What その“なに”を、ビジネス側も開発側も共有理解したい
9. BDDのプラクティス 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 9 Discovery 発見 Formulation 定式化 Automation 自動化 シナリオの発見 コラボレーションと 構造化された会話によって 共有理解を確立します システムの 振る舞いの例を シナリオの形で 文書化します システムの振る舞いを 検証できるようにするため シナリオを 自動化します
10. Behavior 振るまい 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 10 振るまい：要求を満たすためのシステムの振るまい ⇒ Specification: 仕様 ビジネス側からも開発側からも、この振る舞いを誤解なく、正確に、明確に表したい BDDの目的の一つ 振る舞い 具体的な例 (Example)で表してみる
11. Example 実例、例、具体例 例をシナリオで表す ◦ Given ◦ ユーザーストーリーの初期状態またはコンテキストを記述する ◦ ストーリーのステージを設定し、開発チームが要件を理解するために必要な背景情報を提供する ◦ 例： ユーザーが自分のアカウントにログインしているとします ◦ When ◦ ユーザーが取るアクションを記述する。 ◦ ストーリーのトリガーを定義し、開発チームにストーリーを完了するために何が必要かをよりよく理解させる ◦ 例： ユーザーが "Submit "ボタンをクリックしたとき ◦ Then ◦ ユーザーストーリーの結果を記述する ◦ これは、Whenの部分に記述されたアクションの結果として何が起こるべきかを定義し、開発チームに、 利害関係者のニーズを満たすために何を提供する必要があるかについての明確な理解を提供します。 ◦ 例：ユーザーのアカウントが正常に更新されたことを示す確認メッセージが表示されるはずです。 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 11
12. BDD Given,When,Then template 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 12 システム When Then 振る舞い 仕様 Specification 要求 価値 Given 事前条件 行動
13. 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 13 では、いつ、どのように この具体例による振る舞いを出していくか 要求ワークショップにおいて 実例マッピングを行う
14. 要求ワークショップ 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 14 定期的なミーティング（通常は週に数回） 次の数スプリントで行うバックログについて議論する 目的： • ユーザーストーリの明確化 • シナリオの探索 • スコープの理解 • 具体例(Example)を挙げて明確に説明する ➢ ストーリーに関する新しい詳細を発見 ➢ すぐに答えられないような質問 ⚫ 多様な視点を結集することである ⚫ 何をなすべきかを学び、より効果的に協力し合うことである Discovery 別の名で • バックログリファインメント • スリー・アミーゴス ミーティング
15. Living Document 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 15 BDDについて聞いたことがあるなら、おそらくリビング・ドキュメントという言葉に出くわしたことがあるだ ろう。 これは、決して古くならない、少なくとも古くなったらすぐに知らせてくれるような文書です つまり、コードといつも同期しているドキュメント なぜなら、シナリオがアプリケーションでサポートされているかどうかを常に検証できるからです。 サポートされていれば、シナリオ（のテスト）はパスします。 ユビキタス言語のおかげで、ビジネス担当者であっても、私たちのソリューションがどのような期待に 応えられないかをすぐに知ることができます。 サイボウズでは、仕様書がLiving Documentになっている
16. 構造化された会話：Structured conversation 要求ワークショップをファシリテートして、具体的な例を探り出す 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 16
17. 事例 ピザのデリバリ 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 17 要件ワークショップ参加者 PO、開発者2名、テスト、インターン ピザ配達管理アプリケーション 開発対象 PO ： ストーリーの読み上げ 間違った配送先住所を修正するために、 クライアントとして、 注文後に配送先住所を変更できるようにしたい。 PO ： 説明 • 配送先住所を変更できるかどうかを確認できる必要があります • 新しい住所が現在の住所からそれほど遠くないことを確認する必要があります、 • また、注文の状態も確認する必要があります
18. 注意 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 18 典型的な間違いの1 つは、BDD をツールと見なすこと Given/When/Thenのテンプレートに記入するなどの機械的な プロセスであると考えること よくある間違え 具体的な例を考え出す：Discovery すべてのチームメンバーが ユーザーストーリーの理解に積極的に挑戦する
19. 具体例の収集 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 19 まずは顧客が配送先住所を変更できるようにすべきというハッピーパスから ペルソナを置いてみる：Peterさん 28歳 エンジニア 彼は定期的に自宅とオフィスでピザを注文しています。 彼はおそらく配達先住所を時々混同してしまうでしょう
20. 具体例 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 20 • Peterさんはオフィスにいるのに、マルゲリータのピザを誤って家に注文したとします • 注文が完了し、店舗で準備を開始します • Perterさんは数分後にメールにあるトラッキングのリンクをクリックし、配達先を間違ったことに気づきまし た。 • 彼はメールにあるトラッキングのリンクをクリックし、トラッキングページで「住所変更」を選択します • 彼は、配送先を職場に変更し、変更を送信します。 • 変更は受け入れられました。 開発者:「 数分後」とはどういう意味ですか？ PO : 注文を受けたばかりなので、ピザの準備がまだできていない時です。」 QA :ああ、わかりました。ピザがオーブンに入っているかもしれないが、配達の準備ができていない 時でしょうか？ PO :ええ、そうです
21. 具体例の付箋 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 21 Given コンテキスト When アクション Then 結果 注文の品
22. 付箋に書いてみて 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 22 インターン: 私が気になるのは、「準備ができていない」と「準備中」どちらなのかでしょうか？ 具体例のタイトルでは「準備中」と表現し、具体例の2 番目のステップでは「準備ができていない」 と表現しています。 開発者: これらの2 つの言葉は本質的には同じことを意味します。ピザの準備中の 場合は、明らかに準備ができていません インターン: 大学でUML モジュールの中で状態遷移図について学びました。ここで使ってみませんか？ 開発者: 完全なUML の状態遷移図は必要ありませんが、イベントだけでなく、状態の概要も役立つと思い ます
23. 状態遷移図 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 23
24. 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 24 QA では、配達員がピザを受け取るまでに、住所を変更させてみませんか。 PO それは良いですね。 実際、重要なターニングポイントは、配達員が注文したピザを受け取るときです。つまり、 配送先住所を確認してルートを計画するときです QA OK。具体例の付箋を修正します
25. 修正された具体例 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 25 注文の品の受取りを待っています
26. ルールを表す 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 26 QA この具体例はどのようなルールを表していますか？ PO まだ配達員が注文を受け取っていない場合は住所変更を許可する」ですかね
27. シナリオとルールと具体例 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 27 ルール 具体例 シナリオ
28. ルールから具体例を探る 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 28 QA このルールについて、他にどのような具体例がありそうですか？ 反例はありますか？ 開発者 あります！ 注文したピザを既に配達員が受け取っている場合は、 すぐに分かるようにエラーメッセージで応答すべきです。簡単だね…… もう一人の開発者 もう一人のペルソナ、林さんを考えてみましょう。 彼は初めての購入者なので、配送先住所を入力する必要があります。 彼が小さな間違いをした場合はどうなりますか？ PO ピザが最初の配達先住所の玄関口に既にある場合は、住所を完 全に別の場所に変更させることはできません……
29. 議論の行き詰まり 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 29 開発者 遅いタイミングでの配送先住所の変更に対処する方法はたくさんあります が、どれも単純ではありません。本当に今これを行う必要がありますか？ QA 今はこれを解決できないようです。なので赤の付箋を作成し、統計を チェックして、これが発生する頻度と、このようなミスによって発生する追加コ ストを確認しましょう 問題点の一時的な回避策を考え出せますか？ 開発者 エラーメッセージを変更して、お客様にオペレーターへ電話するようにアド バイスすることもできます PO とても良いですね！ 忘れる前に、すぐに書き残しておきましょう！
30. 2つ目の具体例の付箋 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 30
31. 反例と質問 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 31
32. さらに3つ目の具体例 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 32 QA もう1 つあります！ Tim が住所変更画面に新しい住所を入力している ときに配達員がピザを受け取った場合はどうなりますか？
33. さらに3つ目の具体例 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 33 QA もう1 つあります！ Tim が住所変更画面に新しい住所を入力している ときに配達員がピザを受け取った場合はどうなりますか？
34. 最終的な実例マッピング 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 34
35. 計画的な発見 Deliberate discovery 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 35 ソフトウェアの開発中に発生する発見 偶発的な発見 要件ワークショップ中に発生する発見 計画な発見 開発前に、重要な振る舞いの問題を発見し学ぶ方法 実例マッピング
36. テストとBBD 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 36 Agile Testing : Shift Left テスト（QA)の責任 欠陥予防 検証：欠陥検出 バグを防止するために すべてのプロジェクトの イベントの議論に参加する バグをとらえるために プロダクトを検証する 表現をより明確にする エッジケースの検討 問題 ユーザストーリ（要求） に対する誤解 あいまいな表現 要求の理解 具体例 エッジケース 妥当なテスト設計 受け入れテスト リグレッションテスト 探索的テスト
37. BDD アプローチのタスクとアクティビティ 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 37 The BDD Books – Formulation, Seb Rose,Gáspár Nagy, 1021
38. BDDサイクル 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 38 The BDD Books – Discovery, Seb Rose,Gáspár Nagy, 1017
39. 2024/5/30 実例マッピング COPYRIGHT © ATSUSHI NAGATA 39 おしまい