我正在从事一个项目，我们真的很想尝试使用敏捷软件方法，并且正在编写我们的用户故事。这对我们来说是新的，尽管我们在编写成功的软件方面有很多经验。我的问题涉及到当产品需要在多个平台上运行时如何编写故事......
为了争论，我们假设我们的用户故事是......
现在这需要在多个浏览器上工作，很可能是 PC 和 Mac 上的多个版本的浏览器。
过去对不同团队效果良好的方法是，您是否在您希望支持的所有平台上测试故事，或者您是否成功编写了额外的用户故事，例如“必须也适用于 Safari 版本 x.xx”。我不喜欢后者的想法，它没有很好的范围。
另一种选择可能是像这样为每个平台重复编写故事......
无论如何，真的只是在寻找一些洞察力，并有兴趣了解社区中其他一些团队的成功和失败。
感谢分享...
【问题讨论】：
标签： agile user-stories agile-processes
正如 Dave Hillier 所说，DoD 也是一个很好的方法。此外，如果每个浏览器兼容性具有不同的优先级，则将每个故事分开以便可以优先考虑也是一个好方法。
如果需要以相同的优先级完成，并且使浏览器兼容并不难，我会这样做：
As a customer, I want to be able to login to the system, so that I can use the system
Exit criteria:
- xxxx
- yyyy
- be able to login on Safari, IE, Chrome, Firefox
【讨论】：
您可以创建一个Definition of Done (DoD)。
DoD 通常是一份清晰简洁的需求列表， 团队必须遵守软件增量才能将其称为完成。
在您的 DoD 中，您应该包含每个故事的强制性内容。
例如，当您实现一个故事时，您可能希望它在最广泛采用的浏览器上运行。包括对您希望在 DoD 中支持的每个浏览器的功能的实现和测试。
您可能决定要添加对旧浏览器的支持，但这是一个低得多的优先级，可以在以后完成。您可以将该工作单独包含为单独的产品待办事项项目（例如故事或错误）。然后可以酌情确定它们的优先级。
这些项目可以使用故事模板编写，例如"As a user, I want"。例如：
作为客户，我希望能够使用 IE8 登录
作为客户，我想从 IE8 重置密码
最终，您的团队会决定最适合您的情况。这取决于您的客户想要什么！
【讨论】：
我会选择 4 个故事，例如：
Users can Login with Safari
Users can login with IE
Users can login with Chrome
users can login with Firefox
然后您可以创建验收标准来测试每个主要平台的不同相关版本。
如果可以的话，我希望故事尽可能保持高水平。 “用户需要能够登录”是灵活的（只要不是太大）。按浏览器拆分用户故事很像混合非功能性标准和用户故事。
【讨论】：
”写了一个额外的用户故事，例如“必须也适用于 Safari 版本 x.xx”。我不喜欢后者的想法，它没有很好的范围。”
你嫌弃的其实是更好更正确的方法！ “它也应该在其他浏览器上工作......”应该是故事卡背面的 UAC 和功能。
这样您就可以为客户和您的主要故事添加 BV。
支持 UAC 方式作为正确方式的另一个原因是“在不推荐的做法的帮助下消除” - 用户故事不应该是一个洗衣清单。
【讨论】：
我不会为每个平台创建故事，因为美国是“潜在可交付”的单位，应该为最终用户带来价值。
请注意，没有关于用户应该如何访问功能的内容，所以问自己一个简单的问题 - 如果它在平台 A 上有效但在平台 B 上无效，您会将此功能提供给最终用户吗？
IMO 为开发和测试而不是美国创建特定于平台的任务是有意义的，如果任务没有完成，你不能说美国是“完成”。
【讨论】：