I personally like the BDD style user stories and tasks. Generally, under BDD/Agile you will create user stories in a planning meeting along the following lines:
As a [role] I need [capability] so that [desired outcome].
A user story really shouldn't be more complex than that, as they are really just placeholders for future conversations (a key aspect of Agile that most companies misunderstand.) Once you get to the point in an iteration where you are ready to implement a user story, you'll generate one or more tasks for that story usually in the form of Concern/Context/Observations:
Concern: Some Activity Context: When doing such and such Observation: This thing should be added to the database Observation: The thing should get a new unique ID Observation: The thing should be related to that thing
Each task is now written in such a way that it can be directly translated into a BDD-style "specification" test that sets up the context, performs the action of concern, and verifies the observations. (For a great example of how this works with xUnit.NET, see this site.)
It is important when creating user stories not to think too technically. You don't really want to break down your stories to highly technical and low level things like "Create a web page with title 'xyz'. Show stores a, b, and c on this page." Thats super technical and doesn't actually portray any useful business requirements. A story should be more fluid and dynamic and represent the real business requirement: "As a customer I need to see all of the stores that contain the products I am looking for so that I may purchase what I need at a great price." From that user story, you would then end up with tasks that define the more technical aspects of creating this page (I am extrapolating a lot from what I read in your question...forgive me for any artistic license I take in expanding the concept):
Concern: Finding Stores Context: When looking for a product with the best price Observation: The web page should display a grid of store thumbnails that contain the users search product Observation: The stores should be sorted such that those with the lowest price appear near the top of the page Observation: Clicking on a store's thumbnail should take me to a page on that stores web site that contains the product the user searched for
The above story is pretty high level, and covers the expected behavior of the whole page. The above specification can be used to verify proper behavior of the resulting page, used as baseline for creating automated UI tests, etc. However, there will also be code that drives this page, and additional tasks should be created for those lower level things as well.
Concern: Retrieving Stores Context: When searching for Store entities containing a specific Product Observation: A collection of StoreResultDetail should be returned Observation: The collection of stores may be empty Observation: Each StoreResultDetail should contain the store name Observation: Each StoreResultDetail should contain the price of the Product Observation: Each StoreResultDetail should contain the URL of the store's web site Observation: Each StoreResultDetail may contain the URL of the Product on that store's web site
The above task could be implemented by a service method on some service, along with any other behaviors required to implement the specification for the whole page.
Once you have your tasks, you can create visual designs to match, implement code and unit tests (or BDD specifications), and QA test your application with proper, clear, and concise documentation to verify your tests against.
Segregating user stories by "web page" seems suboptimal to me -- you should be choosing the set of your pages based on user stories, not vice versa. I would classify by "role" of the user -- in fact, in user centered design, by the "persona" in play.
In our shop, we write up Use Cases. Examples of Use Cases:
Create New Customer Account
Assign User Rights
Receive Order
Accept Payment
We have a form with two columns. The first column is the user, and the second column is the computer system. In the two columns we begin listing actions. The user does this, the system responds like this, etc. We leave gaps between the entries so that the steps flow naturally from left to right, and back again. There's a place on the form that states which roles the use case is applicable to (e.g. Project Manager, Administrator).
From the use cases, we then begin to sketch up web pages.
I start with identifying what scenario's the users are going to perform with the application. Normally, these are quite predicatable. A user logs in to a website with a certain task in his/her head and wants to fulfill that task.
I'd limit myself to a scenario as one list of sequential steps. For example, user logs in, user select product, user chooses quantity, user checks out, end.
Having the scenario's written down can also help you to determine what parts of the application are more important that others, and which scenario's can be easily be implemented "in-between". And finally, which scenario's could be a show stopper for the launch of the application.
We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.
发布评论
评论（5）
我个人喜欢 BDD 风格的用户故事和任务。 一般来说，在 BDD/敏捷中，您将在计划会议中按照以下方式创建用户故事：
用户故事实际上不应该比这更复杂，因为它们实际上只是未来对话的占位符（敏捷的一个关键方面，大多数公司会误解。）一旦您在迭代中达到准备好实现用户故事的程度，您将为该故事生成一个或多个任务，通常以关注/上下文/观察的形式：
关注< /strong>：一些活动
上下文：当做这样那样的事情时
观察：这个东西应该添加到数据库
观察：该事物应该获得一个新的唯一 ID
观察：该事物应该与该事物相关
现在每个任务的编写方式都可以直接转换为设置上下文的 BDD 风格的“规范”测试，执行关注的操作并验证观察结果。 （有关如何与 xUnit.NET 配合使用的一个很好的示例，请参阅此网站。）
创建用户故事时不要考虑太多技术性，这一点很重要。 您真的不想将您的故事分解为高技术性和低级别的内容，例如“创建一个标题为“xyz”的网页。在此页面上显示商店 a、b 和 c”。 这是超级技术性的，实际上并没有描述任何有用的业务需求。 故事应该更加流畅和动态，并代表真正的业务需求：“作为客户，我需要查看包含我正在寻找的产品的所有商店，以便我可以以优惠的价格购买我需要的东西。” 从该用户故事中，您最终会完成定义创建此页面的更多技术方面的任务（我从我在您的问题中读到的内容推断出很多内容......请原谅我在扩展概念时所采取的任何艺术许可):
关注：寻找商店
背景：寻找价格最优惠的产品时
观察：网页应显示包含用户搜索产品的商店缩略图网格
观察：商店应排序，使价格最低的商店出现在页面顶部附近
观察：点击商店的缩略图应该会将我带到该商店网站上的页面，其中包含用户搜索的产品
上面的故事非常高级，涵盖了整个页面的预期行为。 上述规范可用于验证结果页面的正确行为，用作创建自动化 UI 测试等的基线。但是，还会有驱动此页面的代码，并且应该为那些较低级别的事物创建其他任务，例如出色地。
关注：检索商店
上下文：搜索包含特定产品的商店实体时
观察：应返回 StoreResultDetail 的集合
观察：商店集合可能为空
观察：每个 StoreResultDetail 应包含商店名称
观察：每个 StoreResultDetail 应包含产品的价格
观察：每个 StoreResultDetail 应包含商店网站的 URL
观察：每个 StoreResultDetail 可能包含该商店网站上产品的 URL
上述任务可以通过某些服务上的服务方法以及实现整个规范所需的任何其他行为来实现页。
完成任务后，您可以创建可视化设计来匹配、实施代码和单元测试（或 BDD 规范），并使用正确、清晰和简洁的文档对您的应用程序进行 QA 测试，以验证您的测试。
I personally like the BDD style user stories and tasks. Generally, under BDD/Agile you will create user stories in a planning meeting along the following lines:
A user story really shouldn't be more complex than that, as they are really just placeholders for future conversations (a key aspect of Agile that most companies misunderstand.) Once you get to the point in an iteration where you are ready to implement a user story, you'll generate one or more tasks for that story usually in the form of Concern/Context/Observations:
Concern: Some Activity
Context: When doing such and such
Observation: This thing should be added to the database
Observation: The thing should get a new unique ID
Observation: The thing should be related to that thing
Each task is now written in such a way that it can be directly translated into a BDD-style "specification" test that sets up the context, performs the action of concern, and verifies the observations. (For a great example of how this works with xUnit.NET, see this site.)
It is important when creating user stories not to think too technically. You don't really want to break down your stories to highly technical and low level things like "Create a web page with title 'xyz'. Show stores a, b, and c on this page." Thats super technical and doesn't actually portray any useful business requirements. A story should be more fluid and dynamic and represent the real business requirement: "As a customer I need to see all of the stores that contain the products I am looking for so that I may purchase what I need at a great price." From that user story, you would then end up with tasks that define the more technical aspects of creating this page (I am extrapolating a lot from what I read in your question...forgive me for any artistic license I take in expanding the concept):
Concern: Finding Stores
Context: When looking for a product with the best price
Observation: The web page should display a grid of store thumbnails that contain the users search product
Observation: The stores should be sorted such that those with the lowest price appear near the top of the page
Observation: Clicking on a store's thumbnail should take me to a page on that stores web site that contains the product the user searched for
The above story is pretty high level, and covers the expected behavior of the whole page. The above specification can be used to verify proper behavior of the resulting page, used as baseline for creating automated UI tests, etc. However, there will also be code that drives this page, and additional tasks should be created for those lower level things as well.
Concern: Retrieving Stores
Context: When searching for Store entities containing a specific Product
Observation: A collection of StoreResultDetail should be returned
Observation: The collection of stores may be empty
Observation: Each StoreResultDetail should contain the store name
Observation: Each StoreResultDetail should contain the price of the Product
Observation: Each StoreResultDetail should contain the URL of the store's web site
Observation: Each StoreResultDetail may contain the URL of the Product on that store's web site
The above task could be implemented by a service method on some service, along with any other behaviors required to implement the specification for the whole page.
Once you have your tasks, you can create visual designs to match, implement code and unit tests (or BDD specifications), and QA test your application with proper, clear, and concise documentation to verify your tests against.
对我来说，按“网页”分隔用户故事似乎不是最理想的——您应该根据用户故事选择页面集，而不是反之亦然。 我会按用户的“角色”进行分类——事实上，在以用户为中心的设计中，按“角色”进行分类”正在播放。
Segregating user stories by "web page" seems suboptimal to me -- you should be choosing the set of your pages based on user stories, not vice versa. I would classify by "role" of the user -- in fact, in user centered design, by the "persona" in play.
在我们的商店中，我们编写用例。 用例示例：
我们有一个包含两列的表单。 第一列是用户，第二列是计算机系统。 在这两栏中，我们开始列出操作。 用户这样做，系统像这样响应，等等。我们在条目之间留有间隙，以便步骤自然地从左到右流动，然后再返回。 表单上有一个地方说明了用例适用于哪些角色（例如项目经理、管理员）。
从用例开始，我们开始绘制网页草图。
您还可以制作用例图：
In our shop, we write up Use Cases. Examples of Use Cases:
We have a form with two columns. The first column is the user, and the second column is the computer system. In the two columns we begin listing actions. The user does this, the system responds like this, etc. We leave gaps between the entries so that the steps flow naturally from left to right, and back again. There's a place on the form that states which roles the use case is applicable to (e.g. Project Manager, Administrator).
From the use cases, we then begin to sketch up web pages.
You can also make Use Case diagrams:
我首先确定用户将使用该应用程序执行什么场景。 通常，这些都是可以预测的。 用户登录网站时脑子里想着某个任务，并希望完成该任务。
我将自己限制为一个场景，作为一系列连续步骤。 例如，用户登录、用户选择产品、用户选择数量、用户结帐、结束。
写下场景还可以帮助您确定应用程序的哪些部分比其他部分更重要，以及哪些场景可以轻松地在“中间”实现。 最后，哪种情况可能会成为应用程序启动的阻碍。
I start with identifying what scenario's the users are going to perform with the application. Normally, these are quite predicatable. A user logs in to a website with a certain task in his/her head and wants to fulfill that task.
I'd limit myself to a scenario as one list of sequential steps. For example, user logs in, user select product, user chooses quantity, user checks out, end.
Having the scenario's written down can also help you to determine what parts of the application are more important that others, and which scenario's can be easily be implemented "in-between". And finally, which scenario's could be a show stopper for the launch of the application.
我们按功能（或更佳）对它们进行分组——最低适销功能（MMF），以便为产品增加价值。 事实上，例如，没有办法展示无法创造的东西，或者创造尚无法看到的东西。 因此，我们将创作/展示进行分组，以便一起交付。 更新和删除可以稍后进行，YMMV。
We group them by feature - or better - Minimum Marketable Feature (MMF) so that there add value to the product. Indeed, for instance, there is no way to show something that cannot be created, or to create something that cannot be seen yet. So we group the creation/display so that there are delivered together. Updates and deletions can come later, YMMV.