“特征”和“特征”有什么区别？和一个“故事”行为驱动开发？
我正在开发一个产品，并使用 Pivotal Tracker 来编写用户故事，但我对 BDD 和 XP 很陌生，对 Cucumber 也比较陌生。所以我对这些术语有点困惑。故事和黄瓜特征有什么区别？两者都是简单的描述，由三部分组成——参与者、行动和商业价值。正确的？因此，如果我已经用 Pivotal Tracker 编写了一个故事，我是否应该将其直接复制到 Cucumber 功能中？一个故事可以有多种功能吗？
你怎么认为？
I am working on a product and I am using Pivotal Tracker to write user stories, but I am quite new to BDD and XP, and newer to Cucumber. So I am getting confused by the terminology a little bit. What is the difference between a story and a cucumber feature? Both are simple descriptions consisting of three parts--actor, action and business value. Right? So if I already have a story written in Pivotal Tracker, should I just copy that directly into the Cucumber feature? Can one story have multiple features?
What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
功能是一项成熟的功能，随时可以上线。例如，一个功能可能是一个用户个人资料，包括注册页面、验证、图片等。
在 BDD 术语中，故事是功能中的一小部分，它是功能性的，我们可以在其中获得反馈。例如，我们可能会在没有个人资料页面且没有验证的情况下生成注册。验证可能是另一个故事。图片可以是另一个。
考虑到架构、新技术、领域学习等，生成一些更复杂的功能可能需要几周的时间 - 因此故事可以让我们比这更快地获得反馈。
您可能有兴趣了解分析领域的功能注入 - BDD。我们在故事和功能上都大量使用该模板：
我倾向于不太担心我正在做的事情是功能还是故事，只要我尽快得到反馈即可。
A feature is a fully-fledged piece of functionality, ready to go live. For instance, a feature might be a user profile, complete with registration page, validation, pictures, etc.
In BDD-terminology, a story is a small slice through the feature which is functional, and on which we can get feedback. For instance, we might produce the registration without a profile page, and without validation. Validation might be another story. Pictures can be another.
It can take weeks to produce some of the more complex features, taking into account architecture, new technologies, domain learning, etc. - so a story lets us get feedback more quickly than this.
You might be interested in learning about Feature Injection - BDD in the analysis space. We use the template quite a lot for both stories and features:
I tend not to worry too much about whether what I'm doing is a feature or a story, as long as I'm getting feedback as quickly as possible.
“故事”是一系列共同完成一个目标的开发任务。它是开发人员使用的设备。
“功能”是业务利益相关者希望在其应用程序中看到的功能。要实现一项功能，您可能需要一个或多个故事，因为通常如果一个故事“太大”，它就会被分解为更易于管理的较小故事。
BDD 是 TDD（测试驱动开发）的变体。据我了解，BDD 的语义比 TDD 的语义更少面向实现，因为您使用诸如“系统应该加载用户”之类的短语，而不是“用户实例在被 DAO 加载后不应为空” “——它们描述系统行为（功能集），而不是实际实现的具体细节。但最终，如果做得正确的话，他们都会测试同样的事情。
而且，就主题而言，故事的概念与 BDD 确实是正交的；有些开发实践有故事但没有 BDD。
"Story" is a series of development tasks which together accomplish a goal. It is a device used by developers.
"Feature" is, well, a feature that the business stake holders want to see in their application. To implement a feature you might need one story, or many, since typically if a story is "too big" it is broken down into more manageable smaller stories.
BDD is a variant on TDD (Test Driven Development). As I understand it, the semantics of BDD are less implementation oriented than the semantics of TDD, in that you use phrases such as 'the system should load the user' instead of "the user instance should not be null after being loaded by the DAO" -- they describe system behavior (feature set) as opposed to specific details of the actual implementation. In the end though, they all test the same thing if done correctly.
And, on topic, the concept of story is really orthogonal to BDD; there are development practices that have Stories and do not have BDD.
不幸的是，功能在这个领域是一个重载的词，而 Cucumber 功能与完全成熟的功能是完全不同的东西。
“Cucumber 功能”和用户故事之间最有趣的区别是，用户故事是历史文档，而功能描述了应用程序的当前状态（假设该功能已实现）。
这种差异（IMO）比粒度或大小的差异重要得多。您可以拥有由许多用户故事驱动/启发的 Cucumber 功能，也可以拥有包含许多 Cucumber 功能的单个用户故事。
一旦 Cucumber 功能可以运行，它就是代码。这意味着它更容易被重构和更改。每次运行它时，它都会为您提供有关应用程序当前状态的信息。用户故事告诉您应用程序应该做什么。或者更准确地说，故事的作者认为您的应用程序在撰写故事时应该做什么。
Unfortunately feature is a heavily overloaded word in this space and a Cucumber feature is a very different thing to a fully fledged piece of functionality.
The most interesting difference between a 'Cucumber Feature' and a User Story is that a User Story is a historical document, whilst a Feature describes the current state of the application (assuming the feature has been implemented).
This difference is (IMO) much more important than differences in granularity or size. You can have a Cucumber feature that was driven/inspired by many user stories, and you can have a single user story that has many Cucumber features.
Once a Cucumber feature can be run it is code. This means it is much more prone to being refactored and changed. Each time you run it, it gives you information about the current state of your application. A user story tells you about what your application should do. Or perhaps more accurately, what the authors of the story thought you application should do at the time the story was written.