敏捷开发实践如何受到普遍的系统更改的影响？

Question

当一个由敏捷过程开发的大型系统需要一个突然的、影响到大多数事情的大规模变化时，使用敏捷的最佳方法是什么？迭代部分在这一点上会改变吗？

例如，如果决定将集中式系统变成分布式系统，该怎么办？或者选择另一个大的普适示例。

可以说，应该计划进行大规模的更改，但是敏捷存在的原因之一永远都不是一个完美的世界，所以假设突然出现了一个大的改变，动摇了基础。

编辑总结解决方案：

无论变化有多大或多小，它都是增量式的。--

Answer 1

“迭代部分在这一点上会改变吗？”

绝不可能。

无论这种变化看起来多么“普遍”，您仍然必须在可以管理的迭代中增量地工作。

您仍然需要对更改进行优先排序，并以一种将继续通过单元测试并在需要时可以发布的方式进行更改。

例如，您可能会发现，修复80%的系统就足够了，并且可以发布。或者在释放之前可能需要修复100%的系统。

你还在增量地工作。冲刺。不管你什么时候释放。

Answer 2

敏捷没有神奇的答案。

有很多方法:-

绘制一条合理增量的更改路径，将系统从一种架构更改为另一种结构。如果您有相当好的考虑因素的代码，您应该放弃那些由于更改而变得多余的代码，并保持与更改无关的内容。

另一种方法是，如果情况确实不同，则启动新系统组件的并行开发。

或者，开始新的项目，尽可能多地从旧项目中偷东西。

这取决于变化到底有多大。