作为敏捷性的倡导者，我们可以将软件架构的这种通用定义视为潜在的问题。

在本文中，我们将研究敏捷软件开发团队如何处理和集成软件架构的重要方面。首先让我们定义这个术语，从更传统的（即非敏捷）定义开始，即软件架构是“关于如何在给定边界内构建软件解决方案的一组原则和约束”。

作为敏捷性的倡导者，我们可以将软件架构的这种通用定义视为潜在的问题。约束和边界；这两个词已经包含了一个刚性结构，刚性地描述了软件系统的功能和非功能需求。在传统管理的软件开发项目中，这些要求实际上是在任何开发开始之前就已经刻在石头上的，并且在开发结束之前不会改变。作为一种刚性结构，由于其刚性的性质，这样的软件架构对变化极为敏感。但作为敏捷软件开发人员，我们希望能够快速行动并拥抱变化。

传统的线性软件开发过程

不可否认，某些约束和界限有助于定义我们想要构建的内容。但是为了我们的敏捷目的，我们需要能够消除它们的僵化，以便我们可以在项目过程中对其进行调整。我们如何将传统的软件架构转变为敏捷的软件架构？请记住，在敏捷中，人比流程更重要.

传统软件架构师分析计划系统的软件需求，并根据这些需求做出技术决策。他需要能够看到更大的图景，尤其是关于系统未来的运行。他可能需要了解并注意合规性法规，还需要能够制作设计文档。通常，传统的软件架构师本身并不太参与开发，即编程。他可能会在实际开发开始之前交付架构，然后继续前进。如果项目中的某些内容发生了变化，则不直接参与开发项目的软件架构师无法修改相应的软件架构。这可能是传统软件架构如此僵化的原因之一吗？

在敏捷中，团队及其凝聚力很重要。如果一个传统的软件架构师不参与软件的实际开发，那他怎么能融入敏捷开发团队呢？好吧，大多数软件架构师都是经验丰富的开发人员，他们已经被提升到新的角色。这意味着他们拥有开发软件所需的技能，即使软件架构师这一新的、传统的角色并不真正需要这项活动。

看敏捷团队，我们可以在团队中嵌入一位经验丰富的开发人员，给他起名叫“敏捷软件架构师”，让他和团队一起设计软件架构，同时也让他留在团队里和我们一起开发软件. 当他留在团队中并亲身体验开发时，他将对项目和软件有所了解，将获得直接反馈，并且能够调整和修改软件架构。因此，他能够为敏捷、可持续的软件架构创建动态文档。

然后可以应用这种敏捷软件架构并将其移植到 Scrum 用户故事等敏捷工件中，并根据需要创建和更新它们。与敏捷项目的其余部分一样，这是一个迭代过程。敏捷软件架构师持续监控可能变化的需求，并帮助团队将它们与可能变化的技术情况保持一致，所有这些都与产品所有者等其他敏捷角色进行讨论。因此，架构师为团队提供建议和指导，使其能够共同确定其软件架构。他仍然需要看到大局，但他还需要将其与正在进行的迭代开发过程中发生的事情保持一致。

我们这样说是因为重要的是要考虑敏捷开发团队是一个自我管理的团队。敏捷软件架构师不是团队领导或团队经理，即使他可能比团队中的其他开发人员更有经验。传统上的技术决策应该作为建议进行交流，并与团队讨论。我们需要记住，这是一项协作努力，任何团队成员都无法独善其身或独自完成。创建工作增量（即功能原型）的敏捷原则实际上使软件架构师和团队能够通过让他们了解它们如何影响系统来做出更明智的决策。

敏捷开发过程，在本例中为 Scrum

那么敏捷软件架构什么时候开始呢？越早越好！一旦第一个用户故事可用，团队应该共同了解这些需求如何转化为技术软件需求。这个过程可以改进一些用户故事，同时质疑其他用户故事的可行性。只是不要因为你觉得你的软件架构还没有准备好而推迟你的实际开发。相反，将其设计视为一个持续的过程。一些团队也有一个基本的参考架构，他们会在项目运行时对其进行调整。保持您的敏捷软件架构尽可能简单和精简，使其易于应用、通信和修改。在您的软件开发过程中使用敏捷原则时，这三点非常重要。

总而言之，我们可以同意，良好的软件架构对于软件开发至关重要，无论是敏捷的还是传统的。然而，在敏捷软件开发过程中，这种架构永远不会真正完成，而在传统管理的开发项目中，它在项目开始时就被严格地固定下来。此外，我们建议将软件架构师的角色融入敏捷开发团队，以适应敏捷过程，让第一手经验和团队反馈影响正在进行的软件架构设计过程。最后，我们需要提到的是，精益软件架构对于实现顺畅的敏捷开发过程至关重要。