问敏捷方法:快速、肮脏还是先计划？

EN

敏捷方法首先是计划。只是不是先计划好一切。实际上，您可以收集需求、设计、代码、测试、部署和呈现。您只需在不到两周的时间内(给予或接受)就可以部署并获得反馈的最小特性来完成所有这些工作。然后再做一次，添加另一个特性或调整旧特性。

关键是编写接受更改的代码，这样当您最终看到“整个流程应该如何运行”时，您就可以更改代码。这样，当“流动的方式”(或其他什么)再次改变时，就不会有什么创伤了。

你不能写得又快又脏。快速和肮脏给你里奇德代码。小动作要快。通过不传播知识保持灵活性。理想情况下，任何单一的特性更改都应该只影响代码中的一个位置。

你也不能花费大量的时间除了计划之外什么也不做。你可以计划，但你需要能够改变计划。你需要迅速发现改变计划的理由。当计划顺利进行的时候，没有什么可学习的，也就是计划进行得太久了。规划和编码必须紧密相连。如果你在学习，那么计划越老，它就越愚蠢。

从长远来看，你应该计划变得更聪明。编写灵活的代码。那么变聪明并不会导致后悔。

我不喜欢对大多数人来说，它要么是“快速而肮脏的”，要么是“前面的大设计”。他们甚至不认为还有其他选择。

敏捷就是构建一个系统，在那里，即使是在开发的后期，变化也是微不足道的。这是通过在小的增量块中构建软件，并使用健壮的自动化测试锁定这些块的行为来实现的。并使用频繁的、自动部署到生产中来验证这些更改的价值。

通过进行健壮的自动化测试，通过在更长的时间内进行增量重构，甚至更改架构中最坚硬的部分也变得非常简单。因此，即使您意识到您的体系结构可以在项目进行到一半时做得更好，实际上也可以相对快速地进行更改。

有些人说“预先设计”对敏捷很有好处。但是，如果您打算在此设计之后迭代，您仍然需要确保您的开发文化生成一个易于更改的系统。因此，"SDUF“并不会使健壮测试、密集重构和持续部署的需求失效。

通过将“易于更改”构建到系统中，您不需要仔细考虑项目的初始设计，因为这可以在稍后进行更改。“快速而肮脏”的方法，大多数人称之为“尖峰”，只有当你稳定你发现有价值的特性时才能使用。但是，您不应该在代码库中留下被黑客攻击的代码太长时间，因为它们会减慢更改的速度。

也是，

它是“开始简单，提高，而你前进”。

快速和肮脏是脆弱的，但快速(如果项目足够小和短暂的话)。

计划首先是刚性的，但很稳定(如果项目在遇到财务或时间限制之前就完成了)。

敏捷是上面2的替代方案。它依赖于一种迭代方法，在这种方法中，特性一次完成一次，特性一个接一个地完成，并且在完成程序的这些完全功能的部分时所获得的知识被用来在开发过程中充实和调整计划。要做到这一点，需要预先进行一些规划--至少需要足够的计划，才能估计出各个特性需要多少工作--但是由于敏捷期望更改，过多的计划会导致浪费。