BDD仕様ワークショップで成功するにはどうすればよいですか？

今日、仕様ワークショップを開催することにより、ソフトウェア開発プロセスにBDDを導入しようとしました。

このワークショップには、2人の開発者、1人のテスター、1人のビジネスアナリストがいました。ワークショップは1時間30分続き、その終わりまでに、新機能のいくつかのBDDシナリオを理解することができました。私たちは見逃す可能性のあるシナリオと難しいシナリオを見つけることに焦点を当てようとしました。

ワークショップの最後には、実際にワークショップに不満を抱く人もいました。

ある開発者は、ビジネスアナリストから直接シナリオを渡され、彼女と一緒にそれらをレビューするのに慣れていたので、自分の時間を浪費していると感じました。ビジネスアナリストは、私たちのシナリオのカバレッジに自信がありませんでした（他の重要なことを見逃している可能性があると感じていました）。しかし、より重要なのは、このワークショップは自分でこれらのシナリオすべてを理解できたので、時間の無駄でもあると感じました。そして、より短い期間で。

この実験的なワークショップは1時間30分続きましたが、その終わりまでに、私たちがやったことについて十分な自信が持てませんでした。 BAの脳からのルール。

だから私の質問は、そのようなワークショップが実際にどのように機能するかです。理論的には、開発する新しい機能がある場合、ツリー「amigos」（dev / tester / ba）を同じ部屋に配置して、例を使用して新しい機能のさまざまな要件を共同で作成できるようにします。そのメリットはすべてわかります。特に知識の共有と共通の製品/最終目標/達成済みのビジョンに関して。

この実験から、私たちの結論は、実際にはそれ以上に効果的な費用であるということであった最初の例で彼自身の仕事にBAを持っているだけで、その後見直し/ 3「アミーゴ」で再加工するシナリオを持っています。BAが自分で作業できるようにすることで、実際に何かを見落とすことが少なくなり、後でシナリオを確認して再確認できるようになります。新しい機能のすべての要件を真剣にカバーするには、単純な1回のブレインストーミング/意図的なディスカバリーセッションで十分だとは考えていません。ビジネスアナリストは、実際にはその種のものに最適な人物です。私たちにできる最善のことは、彼女が書いたものをレビューして、共通の理解があるかどうかを確認することです（それにより、彼女のシナリオの一部を書き直したり、見逃した可能性のある新しいシナリオを追加したりできます）。

それで、実際にそれを効果的に機能させるにはどうすればよいですか？

説明からシナリオを導き出すことができれば、完了です。

私がBDDでよく目にするアンチパターンは、すべてのシナリオを詳細に話し合い、書き留める必要性を感じている人々です。

一部のシナリオは非常によく理解されているので、簡単な説明からそれらを導き出すのに十分です。たとえば、「今週のログイン機能が欲しい」と言ったら、それがどのように見えるかわかります。あなたは正しいパスワード、間違ったパスワード、間違ったユーザー名のシナリオがあることを知っています。それらについて話し合ったり、詳細にキャプチャしたりする必要はありません。

同様に、「ここにユーザー登録のフォームがあります。新しいユーザーを作成し、詳細を編集させ、自分自身を削除できるようにする必要があります。ただし、実際に削除するのではなく、削除済みとしてマークする必要があります。必要に応じてアカウントを復元できます。」

そして、「アカウント復旧はこの機能の一部ですか？」と尋ねることができます。

「必要に応じて、2つの機能にすることができます。」

「それでは、作成、読み取り、更新、削除のシナリオを用意しました。これは十分簡単なはずです。アカウントの復旧について話しましょう。これはもっと興味深いですね。」

一般的に、開発チームがシナリオを導き出すのに動作の説明が十分である場合、それらについて説明する必要はありません。疑わしい場合はそうすることができますが、何かをキャプチャーする場合は、覚えておく必要のあるシナリオをキャプチャーすることもできます。

これまでに一度も行ったことがない場合、または確信が持てない場合は、シナリオについて説明します。

特にこれまでに行ったことのない機能がある場合は特に、異常な領域に焦点を当てます。これらは、会話をしたり、出てきた驚くべき例を書き留めたりするのに最適な場所です。通常、BDDテンプレートに基づいて、2つの質問をします。

コンテキストが与えられた
場合イベントが発生
すると、結果が発生します。

• 同じイベントで異なる結果を生み出す他のコンテキストはありますか？
• 他にも重要な結果はありますか？

テーブルにいる全員が退屈に見える場合、あなたが話している機能はおそらくよく理解されています。「Xのように動作するはずですが、代わりにYを使用する」と言うだけで十分な場合がよくあります。これは、ダンノースがジンジャーケーキパターンと呼んでいるものです。チョコレートケーキのレシピみたいですが、チョコレートの代わりに生姜を使っています。

ビジネスの利害関係者が自分でシナリオを導き出すことができたとしても、開発チームが彼と話し、彼の言語を拾い、内面化できることが非常に重要です。その後、その言語がコードに取り込まれ、将来的に会話が改善され、プロジェクトの新規参入者が何が起こっているのかを理解するのに役立ちます。開発者が言語を話せない場合、その言語は使用されません。

ビジネスの利害関係者またはアナリストがセッションで物事をキャプチャすることに時間を費やしたくない場合は、開発者がテスターと協力してシナリオを書き留めてから、レビューを依頼します。これは、逆の方法よりも誤解を明らかにする可能性が高くなります。

BDDが機能しない場合があります。

もう1つの可能性は、ビジネスの利害関係者が不確かなシナリオを見つけることです。「ああ、私はそのことを考えていなかった！よくわからない。」この時点でBDDを放棄し、簡単なことを試してフィードバックを得て、ビジネスに反復可能な何かを与えることは、ビジネスを釘付けにしてビジネスを確実に罰するのではなく、価値があるかもしれません。簡単に変更できるようにし、何が起こっているのかをよりよく理解したら、シナリオを記述します。

BDDがうまく機能すれば、不確実性のある場所を明らかにすることができます。行う価値のあるすべてのプロジェクトには、これまでにない新しい側面があり、どこかで不確実性があります。意図的に無知を発見するのに役立つシナリオの使用に重点を置くと、学習が速くなり、通常、学習はプロジェクトに費やされる時間の大部分を占めます。

さらに、この方法で協力する開発チームが増えるほど、ビジネスが不確実性をもって彼らを信頼する準備が整い、より多くのイノベーションが発生し始めることがわかりました。革新的な企業は、その性質上、プロジェクトに多くの不確実性を持っています。

しばらく前にCynefinに関するブログ投稿を書きましたが、会話が最も効果的な場所を理解するのに本当に役立ちます。あなたがそれを読んで4つのドメインを理解しているなら、ここに私が使うルールがあります：

• 単純で複雑なもの（既知）はよく理解されており、シナリオを詳細に説明する必要はありません。

• 非常に複雑なもの（不明）はまったく理解されていません。シナリオを通して話すことによってこれを発見するかもしれません。確実性の欠如は、BDDがここで機能しないことを意味します。そのため、変更が簡単なものを繰り返し、代わりに迅速なフィードバックを取得します。ABテストのように、オプションを保持するプラクティスもこの分野では優れています。

• BDDは、知識を伝達し、他の2つの空間を明らかにするためのメカニズムとして、（認識可能な）間の空間で見事に機能します。それはハンマーではなく、すべてが釘ではありません。実際、会話に費やした時間を何かに集中できるとしたら、それはあなたが見つけることができる例ではありません。それはあなたができない例を見つけることです。

会議の長さはあなたの問題ではありません。これらの会議が長時間続くことは問題ありません。しかし、誰もが自信を持ってそれから抜け出す必要があります。彼らがしなかったことはあなたの問題です。

要件について話し合うための短い会議を提案します。数日後に2番目の会議をスケジュールし、それまでに準備が必要であることを誰もが知っているようにします。

次に、BAとテスターはそれぞれ非常に異なる方法でソフトウェアを検討するため、それぞれのシナリオを考え出す必要があります。それらをカードに書いてもらい、少なくとも2回目の会議の前日にボード上のどこかに貼り付けてもらい、全員が自分の時間に目を通して、考え直してもらいます。重複を破棄し、考慮されなかったシナリオをすべて貼り付けます。

同意しないものを捨てないでください。それを書いた人との非常に短い会話が役立つ場合は、それを行いますが、主にそれを保存します。

次に、計画/設計ミーティングを行います。その会議のしっかりした議題を持ち（カードの山から始め、論争のあるものを一番上に置きます）、それが予定外の放浪を許可しないようにします。会議のすべての論点が解決されたことを確認してください。

会議の全員がその会議の主題に備える準備ができていることを常に確認してください！

ミーティングで一緒に何かを「ブレインストーミング」しないでください。それはみんなの時間を無駄にします。

効果的な会議の一般的なレシピ：

• 議論するアイテムを誰かに準備させる
• すべての参加者にそれらの項目を調べた（読むだけではない）
• 事前にコメントを収集し、すべての参加者にそれらを検討する（読むだけでなく）ことを要求する
• 決定を下すために会議を開催する

苦情について...

これらから始めましょう：

ある開発者は、ビジネスアナリストから直接シナリオを渡され、彼女と一緒にそれらをレビューするのに慣れていたので、自分の時間を浪費していると感じました。

それは彼がワークショップでやっていたことです。だからそれは私にとって不機嫌で悪い言い訳のようです。私は、この開発者がワークショップの精査とそのスケジューリングの制約のいずれか（または両方）を好まないのではないかと思います。

ビジネスアナリストは、私たちのシナリオのカバレッジに自信がありませんでした（他の重要なものを見逃していた可能性があると感じていました）

これは、より多くの人が見たという事実を除いて、彼女が彼女の側でそれを行い、開発者によってレビューされたときとどう違うのですか？これはワークショップが少し混沌とした結果だと思います。テストを実装して統合することで、十分なテストがあることを確信できます。すべてのバグを確実に発見したかどうかは決してわかりません。カバレッジに関しては、ユーザーストーリーでそれらを図化するのが最善の方法です。

しかし、より重要なのは、このワークショップは自分でこれらのシナリオをすべて短時間で理解できたので、このワークショップも時間の無駄だと感じたことです。

はい、完全に彼女自身で、彼女の壁に囲まれた庭で、知識を共有することなく。これに対して、将来のワークショップは、すべての参加者がこれらに取り組む方法について少し知識を得ているので、生産性が向上する可能性があります。

今回の会議は遅かったのかもしれませんが、いつもそうなるとは限りません。そして、外部の個人として、私はこれを正しくするためにいくつかのトレーニングを与えられ、一人の独裁者とは異なる考え方を持つ3人の参加者によるワークショップの方がカバレッジが優れていたという確信が高まったでしょう。

また、開発者が彼女と一緒にこれらのシナリオを確認する必要が既にあった場合、ワークショップでのやり取りは、「私は自分の仕事を一人でやり、あなた、あなたはそれを一人でレビューして、私に戻ってこれをもう一度やってみましょう」というアプローチ。

提案

• ポジティブになり、プロセスが正しければ、上手くなると強調します。

• ワークショップを合理化し、軌道に乗せるようにしてください。

• ワークショップを開始し、全員が独自にいくつかのシナリオを設計することでワークショップを開始し（さらに、ワークショップの前に）、トリアージしてマージすることで、「孤独な狼」分析の余地を与えるかもしれません。

そして、あなたがそのブレーンストーミングのことをする必要があると思わない場合は、結構です：BAを一人で働かせますが、少なくともワークショップとしてレビューを行います。眼球が多いほど、エリックS.レイモンドのライナスの法則を引用するとよいでしょう。

Given enough eyeballs, all bugs are shallow.

ここにはかなり良い答えがいくつかあるので、これまで見過ごされてきた1つの小さな側面に焦点を当てます。3人のAmigoのそれぞれの役割は、セッションに提供できる必要があります。彼らはそれぞれ異なる方法で価値を提供し、それぞれが異なる制約のセットを理解しています。

一般に、BAはセッションに主要なハッピーパスをもたらすことができるはずであり、ビジネスの観点から主な障害シナリオも提供できるはずです。テストの専門知識は、システムがすべての状況で機能することを証明するために必要なエッジケースと追加のシナリオを特定できる必要があります。開発者の仕事は、実際にはシナリオを追加することではありませんが、技術的な障害が発生することはよくありますが、彼らの仕事も要件の完全な理解を確実にし、影響を伝え、最小限の追加のコミュニケーションで要件を実装します。