问如何在敏捷环境中完成架构设计？

EN

免责声明:我是一个敏捷环境中的架构师，但是，正如长老Helmuth所说，“没有任何作战计划能在与敌人的接触中幸存下来”。换言之，实际情况意味着准则的确切文字不能总是得到遵守。

以上提出的大部分要点都尽可能地遵循团队的要求。然而，原则1(编码系统设计系统的团队)在团队由数十(或数百)个开发人员组成的不同大陆和时区组成时，确实很难遵循。这与开发人员的技能或态度无关，更多的是他们的后勤问题，他们都是为了从客户那里收集需求，了解现有的复杂系统。

那么，系统的设计是如何完成的呢？使用UML？还是定义接口和主要块的文档？也许还有别的事？

架构师通常标识主要组件，然后定义它们之间的接口(包括安全性、速度和可靠性等非功能性需求)，并将组件的内部设计委托给各个团队。这是一个很好的折衷方案，可以让团队设计自己的组件，而不要求每个人都了解系统的一切。

每个组织都有自己的体系结构设计标准，这有时在组织内部的项目中各不相同。这个设计是在团队开始编码之前完成的，或者尽早完成，通常包含(而且不是完整的列表)：

1. 扩大需求和范围定义。这包括用例或用户案例，它们充实了更高层次的业务需求。我个人喜欢将RFC 2119用于非功能性需求。设计是基于和追溯到这些。虽然它可能不符合设计的共同定义，但它们通常也同样重要。
2. 由高级网络或组件关系图和一页文本组成的概述。这是一个非常广泛的受众，从高层管理到开发和质量保证。由于受众广泛，这很少使用UML或定义的符号。
3. 各个组件的详细信息，通常集中在上面提到的它们之间的接口或API上。接口可以指定为目标语言中的方法签名，包含先决条件和后条件细节。组件可能具有网络图，例如显示云或数据中心中VM的布局及其网络安排。关系数据库通常会有实体关系图。
4. 体系结构风险及其缓解的列表(如果已知的话)。和需求一样，这些也展示了设计决策和权衡。

简而言之，敏捷过程中的系统设计与传统瀑布过程中的系统设计完全相同。然而，在敏捷环境中，更少的设计是预先完成的，更多的是委托给组件团队的。关键在于确定最初需要做多深，哪些决定需要推迟，以及确定何时需要做出决定。应该尽早做出影响多个开发团队的决定，特别是可伸缩性和安全性。向已经国际化的产品添加其他语言这样的决策可以推迟到很晚。

在创建初始设计之后，架构师与每个团队一起工作，并检查他们的设计。如果需要对工作单元(如scrum sprint)进行额外的设计或设计更改，架构师的目标是在工作单元开始时使其可用。架构师还负责向受影响的团队或涉众传递任何更改。

免责声明:我不是敏捷教练/架构师--这是我在敏捷项目中看到的，而且我认为它运行得很好。

我认为敏捷并没有很好地定义你如何做架构--敏捷集中在开发方法和实践上。另一方面，UML只是一种用于交流您的体系结构的语言，它超出了敏捷(如果它适合您的项目和您的团队)。

架构真正适用的原则之一是在最后一个可能的负责任的时刻做出决定--这意味着如果您在项目开始时还没有做出所有决定的话，这是很好的，特别是因为您在这个阶段拥有最少的信息。随着时间的推移，您可能会做出“进化”架构的决定。是的，这可能看起来像一些返工，但这也是因为，你已经了解了环境，需求，什么是可能的不可能的新东西，等等。

您想要避免的主要事情是架构腐烂--在这种情况下，代码实际上不符合任何特定的体系结构，只是混乱不堪。与发展一个体系结构相比，主要的区别在于，在后者中，您定期做出明智的决定，并以明确的理由记录它们，然后继续执行，以确保您的代码遵循它。

在进行测试驱动的开发时，可以创建独立测试模块的测试代码(尽可能独立于其他模块)。

为了简化测试代码的创建，您可以向其他模块引入接口，这些模块可以很容易地被模仿。

通过这种方式，您可以自动获得模块之间的耦合尽可能小的体系结构。

在我看来，tdd也是一项建筑工程。