私は製品に取り組んでおり、Pivotal Trackerを使用してユーザーストーリーを作成していますが、BDDとXPはまったく初めてで、Cucumberは初めてです。ですから、用語に少し混乱しています。ストーリーとキュウリの特徴の違いは何ですか？どちらも、アクター、アクション、ビジネス価値の3つの部分で構成される簡単な説明です。右？それで、私がすでにPivotal Trackerで書かれたストーリーを持っている場合、それをCucumber機能に直接コピーする必要がありますか？1つのストーリーに複数の機能を含めることはできますか？
どう思いますか？
機能は、本格的な機能であり、すぐに使用できます。たとえば、機能は、登録ページ、検証、写真などを備えたユーザープロファイルである可能性があります。
BDDの用語では、ストーリーは機能的な機能の小さなスライスであり、フィードバックを得ることができます。たとえば、プロファイルページや検証なしで登録を作成する場合があります。検証は別の話かもしれません。写真は別のものになる可能性があります。
アーキテクチャ、新しいテクノロジー、ドメイン学習などを考慮に入れて、より複雑な機能のいくつかを作成するのに数週間かかる場合があります。そのため、ストーリーにより、これよりも迅速にフィードバックを得ることができます。
分析スペースでの機能インジェクション-BDDについて学習することに興味があるかもしれません。ストーリーと機能の両方でテンプレートを頻繁に使用します。
In order to <achieve a goal>
As <the stakeholder who wants the goal>
I want <something>
できるだけ早くフィードバックを得る限り、自分がしていることが機能なのかストーリーなのかについてあまり心配することはありません。
「ストーリー」は、一緒に目標を達成する一連の開発タスクです。開発者が使用するデバイスです。
「機能」は、まあ、ビジネスの利害関係者が彼らのアプリケーションで見たい機能です。機能を実装するには、1つまたは複数のストーリーが必要になる場合があります。これは、通常、ストーリーが「大きすぎる」場合、より管理しやすい小さなストーリーに分割されるためです。
BDDは、TDD（テスト駆動開発）のバリアントです。私が理解しているように、BDDのセマンティクスは、TDDのセマンティクスよりも実装指向ではなく、「DAOによってロードされた後、ユーザーインスタンスがnullにならないようにする」ではなく、「システムはユーザーをロードする必要があります」などのフレーズを使用します。 "-実際の実装の特定の詳細ではなく、システムの動作（機能セット）を説明します。しかし、最終的には、正しく実行されれば、すべて同じことをテストします。
そして、トピックに関しては、ストーリーの概念はBDDと実際に直交しています。ストーリーがあり、BDDがない開発プラクティスがあります。
残念ながら、機能はこのスペースでは非常に過負荷の単語であり、キュウリの機能は本格的な機能とは大きく異なります。
「キュウリ機能」とユーザーストーリーの最も興味深い違いは、ユーザーストーリーは履歴ドキュメントであり、機能はアプリケーションの現在の状態を記述していることです（機能が実装されていると仮定します）。
この違いは、粒度やサイズの違いよりも（IMO）はるかに重要です。多くのユーザーストーリーによって推進/触発されたキュウリ機能を使用でき、多くのキュウリ機能を備えた単一のユーザーストーリーを使用できます。
Cucumber機能を実行できるようになると、それはコードになります。これは、リファクタリングや変更がはるかに発生しやすいことを意味します。実行するたびに、アプリケーションの現在の状態に関する情報が提供されます。ユーザーストーリーは、アプリケーションが何をすべきかについて教えてくれます。または、おそらくもっと正確に言えば、ストーリーの作成者が、ストーリーが作成されたときにアプリケーションが実行すべきだと考えていたことです。