No matter how "pervasive" the change appears to be, you still have to work incrementally, in iterations you can manage.
You still have to prioritize the changes and make them in a way that will continue to pass unit tests and can be released when needed.
You may, for example, find that fixing 80% of the system is sufficient, and you may release. Or may be required to fix 100% of the system before releasing.
You still work incrementally. In sprints. Irrespective of when you release.
Plot a path of reasonably incremental changes to change the system from one archtecture to another. If you have reasonably well factored code, you should be ditching the code that is made redundant by the change and keeping stuff thats independent of the change.
Another approach if things are really different, start a parallel development of components for the new system.
Or, start new and steal as much as you can from the old project.
发布评论
评论（2）
“此时迭代部分有变化吗？”
绝不。
无论变化看起来多么“普遍”，您仍然必须在您可以管理的迭代中逐步开展工作。
您仍然必须确定更改的优先级，并以能够继续通过单元测试并可以在需要时发布的方式进行更改。
例如，您可能会发现修复系统的 80% 就足够了，您可以释放。或者可能需要在发布之前修复 100% 的系统。
你仍然循序渐进地工作。在冲刺中。不管你什么时候释放。
"Does the iterative part change at this point?"
Never.
No matter how "pervasive" the change appears to be, you still have to work incrementally, in iterations you can manage.
You still have to prioritize the changes and make them in a way that will continue to pass unit tests and can be released when needed.
You may, for example, find that fixing 80% of the system is sufficient, and you may release. Or may be required to fix 100% of the system before releasing.
You still work incrementally. In sprints. Irrespective of when you release.
敏捷没有神奇的答案。
有多种方法： -
绘制一条合理增量更改的路径，将系统从一种架构更改为另一种架构。如果您的代码分解得相当好，那么您应该放弃因更改而变得多余的代码，并保留与更改无关的内容。
如果情况确实不同，另一种方法是开始为新系统并行开发组件。
或者，开始新的项目并从旧项目中尽可能多地借鉴。
取决于变化到底有多大。
Agile has no magic answers.
There's a number of approaches :-
Plot a path of reasonably incremental changes to change the system from one archtecture to another. If you have reasonably well factored code, you should be ditching the code that is made redundant by the change and keeping stuff thats independent of the change.
Another approach if things are really different, start a parallel development of components for the new system.
Or, start new and steal as much as you can from the old project.
Depends how BIG the change really is.