当您拥有多种UI模式中常见的功能时，捕获用户故事的好方法是什么？
例如，想象一下商业航班信息系统，有人可能会用它来回答“UA211航班何时降落？”这个问题。
通常情况下，提供日程安排信息的功能是常见的基础功能，即使您可能通过桌面Web浏览器，移动浏览器（您希望应用不同的样式以使其更有用）来请求它。甚至可能通过SMS短代码。
现在，这肯定可以是单个用户故事（“As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time”）。但这似乎是错误的（无论如何，这可能是一个史诗般的故事）。
你可以将它分开的用户故事（“As a desktop user...”，“As a smartphone user...”等），这是我过去所做的，团队只知道估计第一个包括所有功能，以及后续仅用于估算UI实现的功能。
第三个选项是使基础功能成为与表示层隔离的故事，然后创建UI故事：“As a flight info system front end, I want to get flight status information so that I can present it to the user”，“As a desktop user, I want to see flight arrival... etc”。但这似乎是人为的。
思想？
DWH
答案 0 :(得分：1)
我认为问题在于你试图将UI功能绑定到后端太紧。
例如，如果你把它分解为一个简单的故事：
用户可能想知道给定航班号的航班状态。
好了，现在，鉴于你实现了这一点，现在你可以看看哪些平台会调用它，因为敏捷的一部分不是过度开发，但在这种情况下，如果你有业务需要支持移动和桌面设备，那么你应该把它作为一个REST服务来实现，因为这是两个最简单的解决方案。
所以REST服务解决了上面的第一个故事。
现在，您会发现每个平台还有其他细节。例如，手机上是否有可能已有信息的东西，例如，旅行者是否去了旅行网站并且已经输入了他的信息，那么你可能想去那里，假设旅行者在用户的联系方式中
或者，如果用户只是想输入航班号，那么为什么不将其作为网页，因为这是支持这两个概念的最简单方法。然后，如果您有一个支持GET的URL，并以HTML格式输出，那么您可以轻松地显示。
所以，我的第一个故事太简单了，您可能想要考虑是否可以返回不同类型的数据，因此用户可能想要使用HTML，PDF，json或xml，但是对于每一个都应该是一种商业需求。
不幸的是，很难回答你的问题，因为有太多未知数，这就是你遇到困难的原因。如果你提出错误的问题，那么你确实有一个史诗，但如果你能把它分解为几个简单的故事，那么它就会变得更容易解决。
答案 1 :(得分：1)
我会推荐第二个选项。
如你所知，第一个听起来对于一个故事来说太多了，一个故事应该总是适合一次迭代。
使用第三种选择，最大的问题是你在故事结束时没有提供商业价值，这通常是一种不好的做法。
你可以通过其他方式分割这项工作。您最初可以开发一个非常简化的准系统版本，它可以在所有客户端上运行，然后在后续故事中对每个客户端进行优化。