2

議論のポイントのように思われるので、この質問を提起したいと思います。コミュニティの考えを知りたいです。

私が所属しているチームの運営方法の背景を少し説明し、この質問の背景を説明するために、「Three Amigos」というセッションで RESTful API のキュウリを書いています。3 人のアミーゴとは、基本的には、ストーリーの受け入れ基準を具体化するために、テック リード、開発者 (1 人以上)、BA (1 人以上) が関与することを意味します。このセッションの一環として、BA は通常、きゅうりのガーキンを書きます。

これを開始する例を次に示します。車に関する情報を取得するための RESTful API がある場合、次のようなシナリオが考えられます:-

Scenario: Engine size should appear in the car
Given a car exists
When I request the car
Then the car should have a "1700cc" engine capacity

または、次のように書くこともできます

Scenario: Engine size should appear in the car
Given a "Mazda/ModelABC" car exists with an engine capacity
When I GET "Mazda/ModelABC"
Then the response should contain "1700cc" engine capacity

今では、最初に目にしたものは全体的に読みやすくなっていますが、コードの再利用を促進するものではありません (これは大したことですか?)。2 つ目はコードの再利用を促進し、関係者、つまり開発者の観点から書かれていますが、ビジネス アナリスト (BA) はこのようには書かないため、Three Amigos セッションはかなり無意味になります。

より強く推奨される選択である2つのアプローチを考えると? 私の場合は最初のアプローチを選択しましたが、どちらの方法の引数が何であるか、または提案を裏付けることができるまともな記事があれば、どのアプローチを実際に使用する必要があるかを示唆することに興味があります。

ありがとう。

4

1 に答える 1

2

この回答の各段落の後に「IMHO」を付けることができます。これは、BDD / 仕様書を例として 4 年間行った後の私の経験です。

BDD はコミュニケーションに関するものです。BDD は、チーム全体でお互いを理解することです。

きゅうりは（ただの）コミュニケーションを円滑にするツールです。Cucumber (およびそれが追加する追加の抽象化) を使用する唯一の理由は、他の形式よりもお互いを理解しやすくするためです。私たちがチーム内の開発者だけだったら、おそらくコードを使用したほうがよいでしょう。

したがって、あなたの質問に答えるために、BA と顧客が GET や POST などを理解していれば、それを仕様で使用するのが適切かもしれません。ただし、仕様を実装に結び付けただけであることに注意してください。変更は Cucumber シナリオにも反映されます。

おそらく最初の例は、顧客と BA が直接関係を持ち、理解できる形式です。

ただし、もちろん、技術に詳しくないチーム メンバーが使用している技術的な詳細のレベルによって異なります。誰でも簡単に理解できるようにします。

BDD はコミュニケーションに関するものです。

以下は、私が役に立ち、ある場合には完全に面白いと思った、このテーマに関するいくつかのプレゼンテーションです。

于 2013-09-05T17:41:58.287 に答える