第 4 章：具体例を用いて開発を導く

導入部。

「具体例を使用する」という方法が長年使われてきたが、「開発を導くためのもの」としてだけでなく「チームが成功するためのもの」へと発展していっている。
その一つは「実例マッピング」
具体例はチームで共有された理解構築、そして適切なフィーチャーの構築に役立つ
開発を導く実行可能なテストを作成するために、テスターは具体的な例を質問することで貢献する

具体例ベースの方法

具体例に基づいてフィーチャーやストーリーを構築するバリエーション

振る舞い駆動開発 (Behavior-driven development BBD)
- 自然なドメイン固有言語で具体例のシナリオを捉える
- 顧客が望むものをいつ提供したかを知るのに役立つ
- 重複しないシナリオを書くためにテストを簡素化するのは練習が必要
受け入れテスト駆動開発 (Acceptance test-driven development ATDD)
- 厳密な言語やルールのない具体例を使用して開発を導く一般的な形式
- 機能テストに使用される場合が多いが、セキュリティやアクセシビリティなどの他の品質特性の要件も含められることがある
  - アクセシビリティについては freee アクセシビリティー・ガイドラインがよきと読書会の中で話に出た
    - https://a11y-guidelines.freee.co.jp/index.html
- いくつかの具体例は、チームがいつ完成したかを判断するのに役立つ実行可能なテストに変換される
  - Done の定義に使えたらいいなー
- ATDD でのフィーチャーとストーリーの分割
  - ここでは、書籍内の図も用いて多くの手法が出てくる
    - ストーリーの準備ワークショップ
    - バックログリファインメント
    - 「スリーアミーゴス」ディスカッション
実例による仕様 (Specification by Example, SBE)
- インパクトマッピングを用いてストーリー周りのゴール特定から始める
- 仕様ワークショップ具体例を導く
- 具体例を洗練させて、実行可能な仕様に変換され検証可能になる
- 「実行可能な具体例」はBDD/ATDD と同様に生きたドキュメントになる
  - この具体例も BDD/ATDD と同様に成果物として扱うということかな。なんとなく、BDD/ATDD の前処理的なものと捉えていた。

具体例が役立つ理由

具体例を導くプロセスの中で多くの視点が入ることで、顧客がその機能から得る価値をチームが正確に把握できるようになるとある。
確かに経験的にも、開発とテスターが話すだけでも仕様漏れなんかはドバドバ出るので、それをチームで実践できればより価値があると思う。

チームが具体例を引き出しやすい会話を構成するための方法

ストーリーマッピング
- チーム全体がプロダクトを通じてユーザーの旅をする
実例マッピング
- 特定のビジネスルールだけでなく、それが示す具体例を捉える
プロダクトに対する7 つの側面
- 構造化された会話により、価値の様々な側面の具体例を得る
- これ全然聞いたこともなかったのでさっと見つけた参考になりそうなリンクと書籍
- DtoDに基づくアジャイル要求入門第2回 | オブジェクトの広場
- 発見から納品へ:アジャイルなプロダクトの計画策定と分析

具体例を用いることが基礎となる

以下の２つが具体例を収集することにより可能になるとあるが、個人的にアンダーラインを引いた部分は特に難しいことだよなと思う。

コーディングを始める前に重要な理解の共有を構築できる
誰もが現実に根ざした状態でいられるようにしてくれる

第 5 章；協調を可能にする

顧客と協調する

顧客の真のニーズを理解する
(質問により) 顧客は使い方と関連するリスクを考えるようになる
- 読書会をしならが、顧客がリスクを考えてくれるってのはすごいことだよなという話になった。サービス開発をしていると、顧客といっても社内のチーム外で仕様を決定する人とかになるけど、案外自社製品のはずなのに、例外パターンやリスクについて無頓着だったりする。結構、サポートデスクの人とかがユーザーからの問い合わせに対面しているから、リスクに敏感だったりする。
テスターは開発者と顧客のコミュニケーションを促進できるが、邪魔にならないことが重要
- 邪魔にならないってのは、あくまで良き質問者以上にはならないってことなのかいな
質問が出てきた時は、いつでも「テスター」「プログラマー」「ビジネスエキスパート」を集める
- テストが失敗した場合には、テストの振る舞いや理解が間違っていないか確認する。プロダクトオーナーも交えて速やかに会話する。
- こういうのって、コミュニケーションがあまり無いチームや、時間に追われていると、そのままにされたりしがちだよなぁ

インパクトマッピング

どのフィーチャーを構築するか決定したり、優先順位を決定するのに役立つ
ここは書籍の図も見るといい
- まずフィーチャーの目標 (Why)
- 次に、その目標を達成するのに役立つ人と、邪魔をする人 (Who)
- それぞれの Who に対して目標を達成するのにどうやって助けたり、妨げたりできるか尋ねる (Impact)
- 最後に、各 Impact からどのような成果物が生じる可能性があるか (What)
5W1H のような分析は QA としてもよくやるが、それはあくまで「Who 誰が使うか」「When いつ使うか」みたいなもので、こういうツリー状にはなっていない。そもそもテストの分析とは目的が違うけど、面白い手法だなと思った。

質問する

最初に尋ねる質問は「なぜこのフィーチャーを行うのですか？」
- これを聞けるだけで良いチームだと思う
QA は「Question Asker」の略。テスターは誰も質問しないと思う質問を定期的に出す。
- これまでも全体を見る役目見たいのがテスターにあったけど、質問するための疑問を持てるのがテスターの重要な部分なのかもなぁ
ビジネス関係者は、多くの場合、技術チームがどの品質特性が重要であるかをすでに知っていると誤って想定している
- これは、ほんとそうというか、認識すらしていない場合もある。「よしなに」みたく思われてると余計にタチが悪い

実例マッピング

実例マッピングの紹介。以下は書籍で参考として書かれていた発表資料。

事例から学ぶ実例マッピングのやり方 / Example Mapping - Speaker Deck

とうか、The BDD Books 書いたのが SpecFlow 作者ってのを知らなかった。.NET 系はテストは若干遅れ気味だと思ってたけど、SpecFlow は昔から頑張ってたもんなぁ。すげぇ。

実例マッピングに関しては、疑問点を Spike Task にするのは良いなと思った。また、青の付箋がそのまま受け入れテストになるというのもよき。
BDD ツールを利用しても開発アプローチが BDD になるわけじゃ無いってのはそうだなと思う。RSpec 使ってても、BDD like に書けるぐらいでしかなかったなと。

見せることで信頼を構築する

顧客に見せる、意見を求めることで、「信頼を築く」「信頼を高める」。

全体像に注目することは、テスターがアジャイルチームにもたらす強みの一つ

いろんな手法やツールを使い、可視化であったり、整理をすることで、チームに理解やコミュニケーションをもたらすってのが大きな役割でもあるのかな。
デリバリーはチーム全体で責任を持つにしろ、テスターはいつも全体を見るのが強みってのは、そう思ったことがなかった。

次は 6 章から。