敏捷开发和架构

Question

正式的体系结构规范如何适应敏捷开发--如果有的话？

我特别想到的是Scrum，它没有提到官方工件中的架构。

在组装你的第一个产品待办事项之前，你是否只是让架构“意外”地发展(可以这么说)，你是否非正式地指定了它，或者是否有空间在组装你的第一个产品待办事项之前做一些像4+1规范这样的事情？

Answer 1

敏捷经常被描述为“只做你现在需要做的事情，如果需要更多的东西，你可以在以后重构”。

这是相当误导的。它可以被理解为“现在快速插入一些东西，然后研究如何升级它，以便在未来做更多的事情”。这将导致一个充满痛苦和技术债务的世界。

对于任何系统，你都需要一个设计。对于小型/简单的系统，这种设计可以在您的头脑中，但您仍然需要在开始之前考虑系统将做什么，以及如何最好地完成它。

因此，我认为将设计纳入敏捷方法的正确方法是，在你知道系统最终要做什么的情况下进行足够的设计，并用粗略的笔画来描述它将如何做到这一点。想出一个足够灵活的设计，这样你就不会烧掉任何桥梁。但是不要浪费时间为每个螺母和螺栓写一个正式的详细规范。向下设计到您知道子系统将在哪里以及如何适合的级别，但它可以被视为一个“黑匣子”，只有在需要实现它的时候才能设计它本身。

敏捷开发不应该排除正式的架构-它只是意味着您应该只设计足够的正式架构，以便当您完成时所有部分将很好地结合在一起，并且您只在需要时才充实该设计的较小细节。有时，这意味着你仍然需要一个相当详细的设计。

Answer 2

取决于你的作用域。可能是给定的，也可能是绿地。只是足够的架构，恰到好处。你需要一些东西来写你的第一个测试，做持续集成。

它是一个文档，那么谁将需要它，该做什么呢？

• 你的团队需要一些东西来描述在哪里放置功能和在哪里测试；
• 当你必须扩大你的团队时，新来的人可能需要漂亮的introduction;
• marketing可能需要购买和安装硬软件；...

Answer 3

Scrum主要是一种项目管理技术，这就是为什么它没有提到架构的原因。

尽可能多地以增量方式定义架构。端到端的实现而不是逐层的实现在这方面很有帮助:它导致在每一层中实现一个部分。

架构决策可能很难恢复，所以它们必须很好，并在最后负责的时刻采取，当您对系统和客户需求有了更多的了解时。

不需要正式的规范。