mrb*_*lah 5 agile user-stories
你如何组织用户故事？
我为Web应用程序做了这个:
为"index"这样的网页制作了标题,然后列出了用户可以在此页面上执行的所有商店.
我继续阅读所有页面.
这是最有效的方法吗？
我个人喜欢BDD风格的用户故事和任务.通常,在BDD/Agile下,您将在计划会议中按以下行创建用户故事:
As a [role] I need [capability] so that [desired outcome].
用户故事确实不应该比这更复杂,因为它们实际上只是未来对话的占位符(大多数公司误解的敏捷的一个关键方面.)一旦你在迭代中达到了准备实现的目的.用户故事,您将通常以关注/上下文/观察的形式为该故事生成一个或多个任务:
关注:一些活动
背景:当做这样的
观察时:这个东西应该被添加到数据库中
观察:这个东西应该得到一个新的唯一ID
观察:这个东西应该与那个东西有关
现在,每个任务的编写方式都可以直接转换为BDD风格的"规范"测试,该测试可以设置上下文,执行关注操作并验证观察结果.(有关如何使用xUnit.NET的一个很好的示例,请参阅此站点.)
在创建用户故事时,重要的是不要在技术上过于思考.你真的不想把你的故事分解成高技术和低级别的东西,比如"创建一个标题为'xyz'的网页.在这个页面上显示商店a,b和c." 这是超级技术,并没有实际描绘任何有用的业务要求.一个故事应该更加流畅和动态,并代表真正的业务需求:"作为一个客户,我需要看到所有包含我正在寻找的产品的商店,以便我可以以合理的价格购买我需要的东西." 从那个用户故事中,你最终会得到一些任务,这些任务定义了创建这个页面的更多技术方面(我从你在你的问题中读到的内容中进行了很多推断......请原谅我在拓展概念时所采用的任何艺术许可) ):
关注:寻找商店
背景:寻找具有最佳价格的产品
观察:网页应显示包含用户搜索产品的商店缩略图网格
观察:商店应进行分类,使得价格最低的商店出现在页面顶部
观察:点击商店的缩略图应该带我到该商店网站上的一个页面,其中包含用户搜索的产品
上面的故事非常高级,涵盖了整个页面的预期行为.上述规范可用于验证结果页面的正确行为,用作创建自动UI测试的基线等.但是,也会有驱动此页面的代码,并且应为这些较低级别的事物创建其他任务.好.
关注:检索商店
上下文:搜索包含特定产品
观察的商店实体时:应返回StoreResultDetail 的集合
观察:商店集合可能为空
观察:每个StoreResultDetail应包含商店名称
Observation:每个StoreResultDetail应包含价格产品
观察:每个StoreResultDetail应包含商店网站的URL
观察:每个StoreResultDetail可能包含该商店网站上的产品的URL
上述任务可以通过某些服务上的服务方法以及实现整个页面规范所需的任何其他行为来实现.
完成任务后,您可以创建可视化设计以匹配,实现代码和单元测试(或BDD规范),并使用适当,清晰和简洁的文档对您的应用程序进行QA测试,以验证您的测试.