敏捷开发:如何为迭代/ Sprint设计代码？

Question

在敏捷开发中，您可以处理小用户故事，并生成一个工作迭代。

但是，当下一个用户故事出现并影响已经完成的迭代的设计时，会发生什么呢？

有时，似乎是重新执行最后一个迭代或另一个用户故事，以便在最后一个迭代中合并新的用户故事！

如何处理这个问题？

Answer 1

您描述的问题与雅格尼有关。

在纯粹的敏捷思维中，您可以遵循YAGNI和代码，这正是当前用户故事所要求的，而不需要对代码的进一步需求做出任何预先的决定。它真的可以以你描述的问题结束。

以务实的方式，您可以查看其他已知用户故事的待办事项和优先级，并在当前实现中以某种方式反映进一步的需求。这并不意味着您将用未来故事所需的特性对当前的故事进行编码，但您将将当前实现的设计放在可扩展的设计上，以满足预期的需求。

相比之下，YAGNI仍在游戏中，以防未来需求不明。如果您的待办事项不包含高度优先级的故事，需要对当前实现进行一些重大更改，那么您只需用最简单的方式编写当前实现的代码，就可以完成当前的故事。原因是避免了代码的镀金 =交付没有人真正想要的东西。

结论:如果您能够预测接下来会发生什么(待办事项大多是稳定的)，您可以将这样的决定添加到当前的实现中。如果您无法预测未来需要什么，只需遵循YAGNI即可。

Answer 2

由于似乎有人在讨论这个问题的确切方向，我试着给出几点建议：

• 在非敏捷过程模型中，您通常会对需求进行更改，这大致与您的场景相对应。在这种情况下，当您考虑瀑布模型时，效果尤其容易看到:为了适应新的或更改的需求，您必须遍历整个产品和所有之前的流程步骤。
• 在敏捷开发中，在开始您的sprint之前，您应该举行一次会议来讨论哪些用户故事/史诗/特性/。您计划在即将到来的sprint中实现，并对所需的工作进行评估。这是后一个强调的部分，当你看到一个重大的设计改变和大量的重构时，你作为一个团队成员应该大大提高标准。

每件事都变得更有问题，当然团队的能力越弱。所以，如果你被告知一个用户故事，你说你可以在2周内实现它，但后来你才意识到你需要重新设计，它将需要你至少4周，这是太迟了。你已经在冲刺的中途，冲刺将失败。在这一点上，唯一的选择是取消冲刺的权利。在这一点上重新开始，举行一次新的会议，看看您希望在下一次冲刺中实现的用户故事，包括您对设计问题的新知识，这将导致更准确的时间估计。

最后，我要说一句比这更积极的话:依赖好的时间估计方法确实有很大帮助(f.ex )。( 计划扑克)为了减少风险，估计进行得很远。

为了扩展对您的评论的回答:代码质量保证基本上保持不变。您可以通过测试来确保代码质量，而不管您是否需要重新设计，您都会这样做。当然，椅子不能放在桌子上。但这只是意味着，您有测试用例试图这样做，但失败。这实际上是一种简单的情况(因为在运行测试时，故障很容易弹出)，在这种情况下，您的测试不再与更新的设计匹配。不要忘记，重新设计的过程包括更新现有的测试。如果需求发生变化，您的旧测试将不再受信任！

这里是一些关于在敏捷环境中进行测试的文章的一些提示。

Answer 3

我是这样处理的*：

1. 在小模块中构建代码。如果模块是独立的，则永远不需要修改现有代码。新的task=new模块。
2. 避免旧代码和新代码的交叉。
3. 用新代码替换空代码行。
4. (不要重构)
5. (只编写完美的代码-以后不需要修改)
6. (使添加新模块尽可能简单。如果添加一个新模块花费的时间超过1分钟，它就坏了)