敏捷场景,这是正确的吗？

Question

想象一下,你有一个用户故事1需要实现一个方法:

public static void MyMethod(string paramA);

有几个类将使用此方法,MyMethod会完成完成用户故事1所需的所有操作,但仅此而已.

您很确定在将来的迭代中会出现另一个故事(用户故事2),这将需要该方法成为:

public static void MyMethod(string paramA, int paramB);

之前对MyMethod的调用需要重构,并且需要添加一些对MyMethod的新调用以满足用户故事2的要求(在故事2之后注意,仅使用paramA调用MyMethod是没有意义的).

在处理用户故事1时,敏捷思考:

1)只实现:public void MyMethod(string paramA);

2)实现:public void MyMethod(string paramA,int paramB); - 但现在对第二个参数不做任何事情.此时调用将0传递给第二个参数.

3)实现:public void MyMethod(string paramA,int paramB); - 但现在对第二个参数不做任何事情.呼叫传递正确的值(根据用户故事2的期望)

4)实现:public void MyMethod(string paramA,int paramB); - 所有电话完全覆盖用户故事1和2

Answer 1

做1.

重构很容易,预测未来不是.

该项目可能是罐装的,新的更重要的故事可能会出现,这意味着故事2永远不需要,当你到故事2时,你可能更好地理解问题,需要重构一切.你可能不需要它的原因是无穷无尽的.

Answer 2

一方面，敏捷纯粹主义者坚持认为一切都可以通过稍后的重构来完成。另一端是老派的大设计预先人群，他们认为应该首先构建一个完整的架构，然后将功能添加到它上面。你的问题是完美的，因为如果你盲目地遵循这两种哲学的过程，它就会暴露出这两种哲学的失败。您想要的是最大效率。因此，您需要分析您的情况中的故事 1 和故事 2。您的软件是否可以在没有 S2 的情况下交付，或者您只是将故事分开以帮助估算和规划？如果 S1 是“添加到购物车”而 S2 是“结帐”，那么不构建支持 S2 的接口是愚蠢的，因为如果没有它，您的软件就毫无价值。在每个项目中，都有一组已知的“必备”功能，使您的软件值得交付。如果您的两个故事都来自该集合，那么我会说立即构建支持这两个故事的界面，并且稍后不要浪费时间重构（#3）。

通常，如果 S1 和 S2 都在必备集合中，那么它们在 Backlog 上的位置就会很接近。如果情况并非如此，那么您要么有大量必须具备的东西，而您的项目将不会使用敏捷技术获得那么大的优势，要么 S2 确实不是必须具备的。因此，如果您预计 S1 和 S2 的承诺之间需要花费大量时间（几个月？），那么我会使用 1 参数接口。时间总是造成不确定性的一个巨大因素。