关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
3年前关闭。
Improve this question
正式的架构规范如何适应敏捷开发——如果有的话？
我正在特别考虑 Scrum，它没有提到官方工件中的架构。
你只是让架构“偶然”进化(可以这么说)，你是非正式地规范它，还是在组装你的第一个产品待办事项之前有空间做一些像 4+1 规范的事情？
最佳答案
敏捷通常被描述为“只做你现在需要做的事情，如果需要更多的事情你可以稍后重构”。
这是相当具有误导性的。它可以被理解为“现在快速加入一些东西，然后研究如何升级它以在 future 做更多的事情”。这将导致一个充满痛苦和技术债务的世界。
对于任何需要设计的系统。对于小型/简单系统，这种设计可能在您的脑海中，但您仍然需要在开始之前考虑系统将做什么，以及如何最好地做到这一点。
所以恕我直言，将设计包含在敏捷方法中的正确方法是设计足够多，现在您知道系统最终要做什么，并粗略地描述它将如何做。想出一个足够灵活的设计，你不会烧掉任何桥梁。但是不要浪费时间为每个螺母和 bolt 编写正式的详细规范。设计到一个级别，您知道子系统将在哪里以及如何安装，但它可以被视为一个“黑匣子”，它本身只能在您需要实现它时进行设计。
敏捷开发不应该排除正式的架构——它只是意味着你应该只设计足够的正式架构，当你完成时所有的部分都能很好地结合在一起，并且你只在适当的时候充实该设计的较小细节他们是需要的。有时这意味着您仍然需要预先进行相当详细的设计。
关于architecture - 敏捷开发和架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1892510/