在项目开始时，软件架构建模是否被视为敏捷方法？

Question

我习惯于在项目开始时制定架构计划。 在敏捷过程中，似乎正在完成或改进体系结构 在迭代期间。

Answer 1

Agilists不同意规划和架构。 XP倾向于提倡没有（或很少）架构预先（即计划设计），但人们喜欢Martin Fowler say they do planned design maybe 20% of the time。 XP Explained (Kent Beck)的第14章对XP设计理念有很好的阐述。

Michael Keeling has a good explanation about why agilists (and others) disagree。他说要注意两个方面：你对解决方案的了解以及你对问题的了解。如果您对该领域的解决方案（例如，Web系统）了解很多，那么您更有可能推迟计划。但是，当之前没有人建造过火星车时，你会做更多的计划。对我而言，这解释了为什么不同情况下的工程师会做不同的事情，但每个人所做的事情都是理性的。

Chapter 3 of my book on software architecture致力于回答“你应该做多少架构？”这个问题。简而言之，答案是“架构，直到风险从你的雷达中消失”。如果您不担心可扩展性或安全性，请不要打扰那些。但是，如果您担心可审计性（例如，法规遵从性），那么在您认为自己已经处理它之前就可以对其进行处理，或者可以使用进化设计来处理它。该章可免费下载。

如果你很敏捷，你应该避免将大量的前期设计推到迭代零点。换句话说，如果你的Iteration Zero是三个月的设计，你就不是很敏捷。

您的问题是关于架构模型的 - 这只是您在计划设计中要做的事情之一。模型是达到目的的手段（最终是一个运行系统）。很好用，它们可以帮助你降低风险，但如果你有一个很好的模型而没有系统，没有人会在项目结束时感到高兴。

Answer 2

敏捷并不代表任何计划。

您创建sprint 0，其中包括设置开发环境和架构目标。

一开始就保持简单，它会长期支付。

Answer 3

这取决于你需要对你到达目的地的位置有一个模糊的概念，所以你可以从Walking Skeleton开始，然后在你去的各个部分充实，但同样你不想做出决定too soon。因此，您可以从包含某些实体的体系结构图开始，但在依次评估每个实体之前，不要指定它们的具体实现。

Answer 4

从技术上讲，架构应该跨越迭代，因为架构说这是我们将如何扩展或者这是我们将如何进行通信等。在开发期间，您只需构建您需要的迭代。如果您不需要扩展，则不要将该部分体系结构包含在项目中。因为敏捷的一部分是使用测试，如果您需要稍后重新访问该代码以使其扩展，那么虽然它将包括返工，但您应该有信心进行这些更改以及当前用于扩展的架构建议。

Answer 5

规划和其他项目活动也是如此。 你需要在任何这些活动中做一些总体工作才能让项目顺利进行，但是你不应该深入研究最佳解决/属于每次迭代的细节。

在一开始就非常清楚地了解项目的内容 非常高级。如果情况并非如此，那么首先需要做的就是这样做。 对于架构也需要做同样的事情，我们在这里谈论非常短的时间，与合适的人参与，可以在开始构建一个完全错误的东西。

当您在极高水平上进行上述操作时，随着每次迭代的进行，您自然会获得大量新的高级别信息。另请注意，您可以在一开始就确定确保可以完成某些任务对于了解项目是否可以工作至关重要。 这会影响对团队的关注以及为确保团队成为一个健康项目而需要采取的行动。