【发布时间】：2009-12-12 06:02:34
【问题描述】：
正式的架构规范如何适应敏捷开发——如果有的话？
我特别想到了 Scrum，它没有提到官方工件中的架构。
您是否只是让架构“意外地”演变（可以这么说），您是非正式地规范它，还是在组装您的第一个产品 backlog 之前，是否有空间预先制定 4+1 规范之类的事情？
【问题讨论】：
标签： architecture agile scrum
【发布时间】：2009-12-12 06:02:34
【问题描述】：
敏捷通常被描述为“只做你现在需要做的事情，如果以后需要做更多的事情你可以重构”。
这是相当具有误导性的。它可以被理解为“现在快速完成一些事情，然后研究如何升级它以在未来做更多的事情”。这将导致痛苦和技术债务的世界。
对于任何需要设计的系统。对于小型/简单的系统，这种设计可能在您的脑海中，但您仍然需要在开始之前考虑系统将做什么，以及如何最好地做到这一点。
因此，恕我直言，将设计纳入敏捷方法的正确方法是，在您知道系统最终预期要做什么以及描述它将如何做到这一点的大致范围内进行足够的设计。想出一个足够灵活的设计，你不会烧毁任何桥梁。但是不要浪费时间为每个螺母和螺栓编写正式的详细规范。设计到您知道子系统的位置和方式的水平，但它可以被视为一个“黑匣子”，它本身只能在您需要实现它时进行设计。
敏捷开发不应该排除正式架构 - 它只是意味着您应该只设计足够多的正式架构，以便在您完成后所有部分都能很好地组合在一起，并且只充实该设计的较小细节需要时。有时这意味着您仍然需要预先进行相当详细的设计。
【讨论】：
-
除了上面的质量答案之外：让您的设计成为用户看到的需求定义。这有助于您在关注用户并最终关注用户界面（这在任何软件项目中都应该是最重要的）的同时设想域模型。
取决于您的范围。可能是给定的，可能是绿地。恰到好处的架构，恰到好处。你需要一些东西来编写你的第一个测试，进行持续集成。
这是一份文件，那么谁需要它，做什么？
- 您的团队需要一些东西来描述在哪里放置功能以及在哪里进行测试；
- 当您必须扩大团队时，新人可能会喜欢介绍；
- 营销可能需要漂亮的图片；
- 可能有人必须购买和安装硬件和软件； ...
【讨论】：
Scrum 主要是一种项目管理技术，所以它没有提到架构。
尽可能以增量方式定义架构。端到端完成而不是逐层实现在这方面有帮助：它导致在每一层中实现一个部分。
架构决策可能很难恢复，因此必须在最后负责任的时刻做出正确的决策，当您对系统和客户需求有更多了解时。
没有强烈需要正式的规范。
【讨论】：