使用敏捷方法时如何获得良好的设计？
我已经使用敏捷方法（SCRUM）大约三年了，我看到了它的某些优势，特别是在许多级别的短期反馈中（来自能够早期访问已实现功能的客户，来自可以测试功能的测试人员）。实施后，其他开发人员可以通过审查等方式就新代码提供非常早期的反馈）。 另一方面，我有两个悬而未决的问题，第一个我将尝试在这个问题中进行解释。 问题：难以获得良好的设计 我试图在代码混乱时立即进行重构，我会尽力编写单元测试（这确实有助于防止错误，尤其是重构时）。另一方面，以小增量开发一些复杂的功能，每天提交并在非结构化代码时不断重新思考代码，这使我无法产生出真正好的设计。 我最近采用的另一种方法可以生产出唯一经过精心设计的模块，方法是采用不同的方法：我分析了几天的问题（实际上，在我开始认真研究该问题之前，我已经将这个问题花了几个月的时间） ），为所有涉及的类及其之间的关系草拟了相当详细的设计，持续了两天，然后将自己锁在办公室，并通过不间断地工作了大约三周时间写下了整个代码。结果是我一段时间以来取得的最好的结果，很少有易于定位和修复的错误，并且设计非常清晰，自此以后就不需要进行任何相关更改。 因此，到目前为止，我发现预先了解要执行的操作的总体效果比开始以小增量编写代码要有效得多，以期在此过程中神奇地出现大效果。尽我最大的努力，小增量开发方法一直使我的设计变糟。 问题：有没有类似的经历？我是否以错误的方式应用SCRUM，或者如果我想以较小的增量进行开发并且最终仍然使用精心设计的软件，应该注意什么？还是应该在开始实际编码之前安排设计用户故事？至少对于比平均水平更复杂的功能，这是否被视为一种好的做法？ 编辑-注意 我知道这样一个事实，即好的设计不是绝对的东西，本身没有价值，而是取决于上下文，因此，人们应该针对一种足以解决当前问题的设计。 例如，如果我必须实现一个简单的组件，即（1）必须尽快准备就绪，（2）仅使用一次，（3）不用，那么我不会在乎（过分）好的设计。由系统的其他部分（YAGNI）使用。 当组件（1）会被多次使用并且会在产品的几种不同版本中使用时，我确实会在乎良好的设计；（2）需要维护并随着时间的流逝而扩展；（3）取决于它，还有很多其他组件。