问敏捷场景，哪个是正确的？

EN

范围的一端是敏捷纯粹主义者，他们坚持一切都可以通过稍后的重构来完成。在另一端是老派的大设计先锋队，他们认为你应该先建立一个完整的建筑，然后再把功能放在上面。你的问题是完美的，因为它暴露了这两种哲学的缺点，如果你盲目地遵循它们的过程。你想要的是最大的效率。所以你需要分析故事1和故事2在你的情况下。您的软件是否可以在没有S2的情况下进行移植，或者您是否只是分散了这些故事来帮助评估和规划呢？如果S1是“添加到购物车”，而S2是“签出”，那么不构建支持S2的接口是愚蠢的，因为没有它您的软件就一文不值。在每个项目中，都有一组已知的“已拥有”功能，使您的软件更有价值。如果您的两个故事都来自该集合，那么我想说，现在就构建支持这两种功能的接口，以后不要浪费时间重构(#3)。

通常，如果S1和S2都在必须设置的集合中，它们将在待办事项上紧密相连。如果不是这样的话，那么你要么拥有大量的必须拥有的东西，要么你的项目在使用敏捷技术时不会获得那么大的优势，或者S2确实不是一个必须拥有的。所以，如果你期望有大量的时间(几个月？)为了在对S1和S2的承诺之间传递，我将使用1参数接口。时间总是造成不确定性的一个巨大因素。

只需做一次。

重构很容易，预测未来就不容易了。

该项目可能是罐头，新的更重要的故事可能会出现，这意味着故事2是永远不需要的，当你到达故事2时，你可能会更好地理解问题，并需要重构一切。有无数的理由你可能不需要它。

纯粹主义者会说选项1，但我会听取常识，如果你完全相信这是一个要求，那么我会把这一点考虑到你的设计中。

然而，敏捷也是以重构为基础的，所以只要你不公开发布这个界面，如果改变它不会影响我的设计，我就会选择选项1。