BDDの概念を採用したがらないチームに「販売」するために、どのような議論を使用できますか？

私は、行動駆動開発方法論（別名BDD）の声明的な支持者です。私は数年前からBDDを適用してきましたが、DotNetアプリケーションを開発する際の選択のフレームワークとしてStoryQを採用しました。私は長年ユニットテストを行っており、以前はテストファーストのアプローチに移行していましたが、BDDフレームワークを使用することでより多くの価値が得られることがわかりました。コード内の英語をクリアします。テストはテストを途中で終了することなく複数のアサーションを実行できるため、デバッグすることなく、どの特定のアサーションが合格/失敗するか一目で確認できます。

これは本当に私にとって氷山の一角でした。テストコードと実装コードの両方をより的を絞った方法でデバッグできることにも気づきました。その結果、生産性が大幅に向上し、ビルドログに出力されるために問題が統合ビルドに至るまでに発生した場合、障害が発生した場所を簡単に判断できます。さらに、StoryQ apiには、習得が容易で、非常に多くの方法で適用できる美しい流な構文があり、使用するために外部の依存関係を必要としません。

したがって、これらすべての利点があれば、チームの他のメンバーにこのコンセプトを簡単に導入できると思います。残念ながら、他のチームメンバーはStoryQを見てそれを適切に評価することを嫌がり（BDDを適用するというアイデアを楽しまないでください）、お互いの説得力のあるテストフレームワークから多くのStoryQ要素を削除しようと互いに確信していますただし、元々StoryQの使用をサポートしており、削除したいコードがテストシステムの他の部分に影響を与えることはありませんでした。そうすると、特定の作業環境でテストファーストで作業するより良い方法であり、より大きな結果につながるだけであると実際の経験から確信しているので、全体的にワークロードが大幅に増加し、実際に穀物に反することになります私のソフトウェアの品質の改善 veは、BDDを使用して最初にテストに固執する方が簡単だと感じました。さらに明確にするために、私たちが行った単体テストの大部分は非常に脆弱で維持が難しい傾向があります。テスト駆動型プロセスに固執することを嫌がって開発者が古い習慣に戻り、プロジェクトの最後にすべてのテストを行います（同じ人がアジャイルだと主張しています！）。

したがって、質問は次のようになります。

1. このチームがStoryQを使用すること、少なくともBDD方法論を採用することの方が良いと主張するために、どのような議論を使用できますか？
2. BDDを標準的な選択方法として採用するという私の主張を裏付けるために使用できる事例証拠を教えてください。
3. チームがBDDを採用することを奨励したいという私の希望が間違っている可能性があることを示唆する反論はありますか？はい、議論が健全なものであれば、間違っていることが証明されてうれしいです。

注：テスト全体を書き直すことを推奨するのではなく、将来のすべてのテスト作業のために、できればお客様と交わる方法で異なる方法で作業を開始することを推奨します。

また、BDDの詳細については、次のリンクが役立ちます。

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/Introduction

_{詳細に興味がある人のために、私たちは4人の小さなチームで約5つの大きなプロジェクトに取り組んでいます。BDDの「パイロットトライアル」は、最初は約2か月間、その後約4か月間実行されました。チームは、私がこの方法で作業を続ける必要があることを受け入れ、独自のトライアルを行うことになりました。トライアルが終了してから約2年間BDDを行っていますが、他の人は問題をうまく解決することができました。この問題について「対立」を強要するのではなく、私はチームを優しく説得して、集団の背後から抜け出し、少し時間をとる方法を探しています。}

StoryQを使用した方がよいと主張するポイントを実際に駆動するために、または少なくともBDD方法論を適用するために、どのような引数を使用できますか？

「顧客はそれを望んでいます。」

IMOは、少なくとも開発チームと同じくらい、BDDを顧客/ドメインの専門家に販売したいと考えています。

BDDは、複数の利害関係者が関与する共同の外部インプロセスです。BDDの利点は、開発者が受け入れテストからテストコードを自動的に推論するだけではなく、システムの意図された動作の価値のある明確に定義された仕様を作成するために技術者とビジネス者の間で行われる創造的な協力にもあります。

顧客/ビジネスアナリストが、各実行可能仕様を実行し、ステータスを制御し、実装の進捗を確認できるインターフェイスにアクセスできるようにすることも、一般に高く評価されています。

Dan NorthがBDDをビジネスに販売する方法についてのプレゼンテーションがあります：http : //skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. BDDの採用に消極的なチームでは、同僚を本格的な採用に「変換」するために使用できる「引数」はないでしょう。
    
   あなたができる最善のことは、彼らに試してもらうよう説得することだと思います（「煙テスト」、「ドライラン」、「パイロットプロジェクト」）-特に、結果をテストする場合はアイデアを落とすことを完全に明確にする場合負です。
2. 事例証拠を見つけるためのあなたのアプローチは、試してみるようにチームを説得するという考えに完全に適合しています。そのために、私は単に「行動駆動型開発のサクセスストーリー」のようなものをウェブで検索し、自分にとって使いやすいと思うものを選びます。
3. チームの努力をBDDに変換したいというあなたの願いが間違っている可能性があることを示唆する可能性のある反論がいくつかあります。
    
   これらはどれも特に建設的なものではありません。特に「変更支持者」の観点からは、残念ながらこの種のレトリック（BTDTGTTS）に対処する必要があるでしょう。
    
   • チーム全体の生産性が向上することを保証できません
   • BDDの採用に投資した努力が実質的なROIをもたらすことを保証することはできません
   • チームはBDDなしで十分にうまく機能していたため、現在のアプローチを変更するリスクは正当化されません
   • Google（またはMicrosoft、またはIBM-「立派な」ソフトウェアベンダーの名前を入力するだけ）は、BDDがなくても問題なく動作し、BDDが不要であることを「証明」します。
   • 非BDDアプローチは、比較テストで公平なチャンスを与えられませんでした
   • BDDは一般に問題ないかもしれませんが、これとそのモジュール/プロジェクトには適用できません

私の経験では、上記のようなカウンター引数に対処する最も簡単な方法は、提案された変更に対して限定された制御されたテストを実行することでした。

ステータスは、本質的に提供することで対抗することができ、「立派ベンダー」について1、を除いて、上記の3つの4の引数を無効にする「リミテッドは、テストの」事例証拠「ビッグバンの変更」のためではなく、の成功物語（事例証拠はなりません、おそらく仕事のを限定的なテストで十分です）。

変更が実際に価値があり、テスト実行が適切に配置されている場合、チームと管理の態度に積極的な変化が見られ、本格的な変更への移行がスムーズで痛みのないものになります。

制限されたテスト実行のもう1つの利点は、あまり多くのトラブルを引き起こすことなく、またアイデアに対する「評判の損傷」のリスクを抑えて、ターゲットプロセスの詳細を明確にし、調整できることです。このようなテストランに参加するたびに、テストランで最も重要な詳細が設定および明確化された本格的な採用に切り替えることがどれほどスムーズであるかを知って、うれしい驚きを覚えました。

経営陣を募集する時が来るかもしれません。試してみて堅実な結果が得られたが、チームがしている場合、経営陣が関与する必要があるかもしれません。

これは、企業の最も生産的なチームメンバーを傷つけている場合に特に当てはまります。反発に備えてください。経営陣に近づき、テストケースを取り出すことでチームがアンダーカットをやめさせないようにすることから始めることができます。