您如何组织用户故事?
我为Web应用程序做了这个:
为“index”这样的网页制作标题,然后列出用户可以在此页面上执行的所有商店。
我继续阅读所有页面。
这是最有效的方法吗?
答案 0 :(得分:8)
我个人喜欢BDD风格的用户故事和任务。通常,在BDD / Agile下,您将在计划会议中按以下行创建用户故事:
As a [role] I need [capability] so that [desired outcome].
用户故事实际上不应该比这更复杂,因为它们实际上只是未来对话的占位符(大多数公司误解的敏捷的一个关键方面。)一旦你在迭代中达到了准备就绪要实现用户故事,您将通常以关注/上下文/观察的形式为该故事生成一个或多个任务:
关注:有些活动
上下文:在做这样的事情时
观察:这个东西应该添加到数据库中
观察:该东西应该获得一个新的唯一ID
观察:事情应该与那件事有关
现在,每个任务的编写方式都可以直接转换为BDD风格的“规范”测试,该测试可以设置上下文,执行关注操作并验证观察结果。 (有关如何使用xUnit.NET,see this site的一个很好的例子。)
创建用户故事时,重要的是不要太过于技术性思考。你真的不想把你的故事分解成高技术和低级别的东西,比如“创建一个标题为'xyz'的网页。在这个页面上显示商店a,b和c。”这是超级技术,并没有实际描绘任何有用的业务要求。一个故事应该更加流畅和动态,并代表真正的业务需求:“作为一个客户,我需要看到所有包含我正在寻找的产品的商店,以便我可以以优惠的价格购买我需要的东西。”从那个用户故事中,你最终会得到一些任务,这些任务定义了创建这个页面的更多技术方面(我从你在你的问题中读到的内容中进行了很多推断......请原谅我在拓展概念时所采用的任何艺术许可) ):
关注:寻找商店
背景:寻找价格最优的产品
观察:网页应显示包含用户搜索产品的商店缩略图网格
观察:应对商店进行分类,使价格最低的商店出现在页面顶部附近
观察:点击商店的缩略图会带我到该商店网站上的一个页面,其中包含用户搜索的产品
上面的故事非常高级,涵盖了整个页面的预期行为。上述规范可用于验证结果页面的正确行为,用作创建自动UI测试的基线等。但是,也会有驱动此页面的代码,并且应为这些较低级别的事物创建其他任务。好。
关注:检索商店
上下文:搜索包含特定产品的商店实体时
观察:应返回StoreResultDetail的集合
观察:商店的集合可能是空的
观察:每个StoreResultDetail都应包含商店名称
观察:每个StoreResultDetail都应包含产品的价格
观察:每个StoreResultDetail都应包含商店网站的URL
观察:每个StoreResultDetail可能包含该商店网站上产品的网址
上述任务可以通过某些服务上的服务方法以及实现整个页面规范所需的任何其他行为来实现。
完成任务后,您可以创建可视化设计以匹配,实现代码和单元测试(或BDD规范),并使用适当,清晰和简洁的文档对您的应用程序进行QA测试,以验证您的测试。
答案 1 :(得分:2)
通过“网页”分隔用户故事对我来说似乎不是最理想的 - 你应该根据用户故事选择你的网页集,而不是相反。我会根据用户的“角色”进行分类 - 事实上,在用户为中心的设计中,通过游戏中的“persona”进行分类。
答案 2 :(得分:1)
在我们的商店,我们写了Use Cases。用例示例:
Create New Customer Account
Assign User Rights
Receive Order
Accept Payment
我们有一个包含两列的表单。第一列是用户,第二列是计算机系统。在这两列中,我们开始列出操作。用户执行此操作,系统会像这样响应等。我们在条目之间留下间隙,以便步骤自然地从左向右流动,然后再返回。表单上有一个地方,说明用例适用的角色(例如项目经理,管理员)。
从用例中,我们开始草拟网页。
您还可以制作用例图表:
答案 3 :(得分:0)
我首先确定用户将使用该应用程序执行的场景。通常,这些是可以预测的。用户在他/她的头脑中登录具有特定任务的网站并且想要完成该任务。
我将自己局限于一个连续步骤列表的场景。例如,用户登录,用户选择产品,用户选择数量,用户签出,结束。
将场景记录下来还可以帮助您确定应用程序的哪些部分比其他部分更重要,哪些场景可以轻松地“中间”实现。最后,哪种情况可能会成为启动应用程序的一个障碍。
答案 4 :(得分:0)
我们按功能 - 或更好 - 最小市场特征(MMF)对它们进行分组,以便为产品增加价值。事实上,例如,没有办法展示无法创造的东西,或创造一些无法看到的东西。因此,我们将创建/显示分组,以便一起交付。 YMMV可以在以后更新和删除。