我在工作中遇到了一个问题,我们刚开始使用scrum作为开发团队.我对我们提供的用户故事有些麻烦,因为它们似乎不符合我对用户故事的解释.
以下是我们为此sprint提供的用户故事的实际示例:
作为网站用户,我希望有一个注册页面,以便我可以注册并提供我的详细信息.
作为商家用户,我希望在注册表上进行验证,以便我提供正确的信息.(这与表单验证有关)
作为商家用户,我在注册时需要支持,以便回答有关所需详细信息的任何问题.(这与表格上的工具提示有关)
我脑海中的第一个是用户故事.第二个似乎是第一个用户故事的传统要求,我认为它们应该是第一个用户故事的接受标准.
我遇到的另一个困惑是我们最后一次冲刺:
作为用户,我希望能够登录该网站.
作为用户,我希望能够使用用户名登录网站.
产品负责人说这是两个不同的用户故事,需要单独测试.
我的问题是,在为后两个创建测试用例和验收标准时,它很难,因为它们非常具体,与第一个用户故事有关.看起来我们只是在卡上提出传统要求并将其称为其他东西.我主要想知道我是否错了这个/为什么？
它只是在我看来,我们目前只是让用户创建他们想要作为一个用户故事什么,而不是帮助他们从需求到正确的用户故事进行筛选.我被告知我们需要将它们全部分开报告,以便我们可以记录用户请求的所有内容.
S.L*_*ott 11
用户故事关注客户价值....随着系统开发的进展,通过围绕用户故事的协作,实现的实际工作得以充实....为了限制范围,用户故事具有协作开发的验收标准,用于定义用户故事何时满足利益相关者的期望.测试用例通常被开发为代码(具有测试驱动开发)或在开发代码时进行记录.
[强调我的.]
作为用户,我希望能够登录该网站.
作为用户,我希望能够使用用户名登录网站.
由于既没有提供任何客户价值,也没有用户故事.
您使用应用程序软件来管理信息,做出决策并(最终)采取行动.如果用户故事没有提供关于采取什么信息,决策或行动的一些提示,那么就没有客户价值,这只是技术文件夹 - 客户必须忍受的实施细节才能到达应用程序的有趣部分.
具体而言,登录的客户价值为零.这是IT在客户之间建立的障碍,以及他们做出决策和采取行动所需的有价值信息.这是一种安全机制,大多数人实际上并不喜欢安全性.IT部门对客户施加安全保护.最受欢迎的密码(IIRC)是"aaaaaaaa".为什么？客户不喜欢安全.
详细的微观登录用户故事可能是未能看到客户真正价值的症状.
在我看来,我们目前只是让用户创建他们想要的任何用户故事
好.
我被告知我们需要将它们全部分开报告,以便我们可以记录用户请求的所有内容.
真是个不错的计划.
问题是将"用户碰巧说的废话"与"我们可以构建的有意义的东西"分开.允许用户说出他们想说的任何废话是非常非常重要的.让他们漫步是件好事.
定期(在每个sprint之前),您将优先考虑用户所说的废话(1)您可能能够在sprint期间构建,以及(2)创建您可能创建的最重要和最具戏剧性的用户值.有些故事会被忽略.有些将是低优先级.有些将合并,有些将被拆分.用户说的一些事情将是矛盾的.有些人将是彻头彻尾的谎言.有些将是不完整的.都很好.这只是用户碰巧说的垃圾.不是从神的口中直接指向你的神圣指示.
这套经过修改的用户故事推动了冲刺.现在,您开始与用户协作以获取详细信息,编写测试用例,定义接受等等.
当你正在向交付冲刺时,用户可以继续说废话将附加到未实现的用户故事的积压.允许用户说出他们想说的任何废话是非常非常重要的.让他们漫步是件好事.