敏捷和以体系结构为中心的软件开发有什么区别？

Question

从我所读到的，“敏捷”似乎只是一个用于破解和削减开发的委婉术语。换句话说，在以架构为中心的开发基于设计文档的情况下，敏捷开发本身没有“设计”，并且代码只是被攻击，直到它通过测试。我真的希望事实并非如此。澄清将非常感激。感谢。

Answer 1

我不知道您在哪里获取您的信息，但并非来自任何正确实施敏捷开发团队的人：）

敏捷并不意味着没有设计文件。相反，设计文档会随着时间的推移而迭代地发展。我们的想法是，在任何人有任何经验之前，项目的开始是创建具体和详细设计的绝对最糟糕的时间。变量太多了。相反，会创建一个高级设计，该设计会考虑这些变量并预先解决这些不确定因素会及时发现。

作为一个基本情景，在项目开始时，我们会给出关于该项目规模的高级估计，而没有任何具体数字。 “这部分很小，那部分是中等的，那部分是超大的”等等。企业相应地设定了优先级。说他们最初想要超级超大部分，但现在他们知道这比中等部分要多得多，那么他们宁愿首先将中间部分放在市场上。保存其余部分以供日后使用。

这为他们节省了为超级超大部件创建大量详细设计的时间，而事实证明这对于现在的业务来说并不是最好的。在更紧急的优先事项完成之后，可以重新评估并重新解决这个问题。

而且，非常重要的是，根据软件的性质，在开发过程中对介质部件所做的更改完全有可能对超大部件的设计产生严重影响。如果它都是预先设计的，那么重新设计并适应这些变化会花费更多。

还应该注意的是，开发人员可以在任何开发环境中“一起破解代码以通过测试”。这与敏捷无关，而与草率/懒惰编码实践有关。开发方法的开发方法不会产生好的或坏的软件。

Answer 2

就有组织的正式措施而言，敏捷开发可以非常“架构”。敏捷更多地与简短的迭代生命周期有关，这些生命周期允许项目增长并快速适应客户可能遇到的任何变化或团队遇到的任何变化。敏捷不是“牛仔编码”，但是，大多数敏捷团队使用真实甚至严格的流程来完成他们的工作。

Answer 3

我正在研究这个主题，所以我虽然可以得到一些东西。

敏捷和以架构为中心的方法都涉及到架构的开发，然而，在敏捷中，它并不像看起来那么无组织（如Jesse所提到的那样），软件架构指的是通常所谓的架构峰值即一个孤立的体系结构，其后必须包含在更大的体系结构中以用于体系结构控制。 以架构为中心的方法依赖于架构控制中的所有内容，并因此而失去灵活性，因为通常需要文档在工作量方面产生不希望的开销。

敏捷几乎没有对问题进行分析，但也有很多设计解决方案，但在迭代过程中产生更多孤立的解决方案。以体系结构为中心有两者，但可能需要很长时间才能部署工作软件。最大的目标是实现两者之间的平衡，可能使用更有效的解决方案来收集两者。

因此，敏捷对小型企业最为重要，以建筑为中心更多的是对更大的企业或工业发展。