问我们应该使用一个用户故事还是拆分成几个更小的

EN

您不希望等待2+迭代来传递和获得对事物的反馈。如果你等得太久才能得到客户和用户的反馈，你可能会投入太多的精力去构建错误的东西，当你需要做大量的返工，甚至放弃工作时，这些东西就会被浪费掉。

如果您不能在一次迭代中向产品交付某些内容并获得有关特性的反馈，那么下一步的最佳操作是获得一些您可以向最终用户演示的内容，比如在测试环境中，并在一次迭代中获得关于该增量的反馈。您可以使用模拟数据来模拟任何您没有的东西，但是通过实现工作流的一个真正的部分并获得反馈，您可以验证设计和实现的一部分，以确保在您花上几周或几个月的时间之前，它是真正想要的。

我也建议看看你的组织结构。需要协调4个团队来实现一项面向用户的功能是非常低效的。在沟通和协调方面可能存在不必要的开销。我还认为，团队中的竞争优先级可能导致依赖工作，而不是像预期的那样开始或完成。以一种允许单个团队承担全部工作的方式组织您的团队也可能会减少实现的总体时间。

作为一个用户我想..。

它是一个用户故事(US)的主题，从用户的角度来看，用户请求并获取文档。

在一个或多个美国(S)中构建需求和在sprint中启动该功能应该是不相关的。由于需求是用户故事，努力是在故事点和考虑团队的速度给出的发射时间，无论是有一个或多个美国(S)。有可能表达故事点的人，并有一个成本-时间范围的概述，虽然不可取。

为了在多团队环境中利用并行性，在多个团队环境中，不同团队开发的特性相互依赖，团队必须事先就相互连接达成一致，然后每个团队开发他们必须在其上传递的外部特性的硬编码版本(所谓的模拟实现)，开发团队必须使用模拟启动的特性，并在它们可用后用真正的特性替换模拟。

工作流程可以通过计划-构建运行或者“先做好，然后做好，然后做得更好”来概括。

理想情况下，用户故事所需的时间应该少于sprint。问题是客户不关心你的流程。他们希望他们的大故事结束并降级。而不是“未完成”的部分。

所以，如果你需要的话，就把它内部拆开。称它为史诗，制作故事，或分裂它，只演示最后一个故事。

但不要与他们争论，他们要求错误的东西或演示‘不完整’的东西。他们不会在意的。