「敏捷模型」敏捷架构：规模化敏捷开发的策略

与流行的看法相反，架构是敏捷软件开发工作的一个重要方面，就像传统工作一样，并且是扩展敏捷方法以满足现代组织实际需求的关键部分。然而，敏捷专家的体系结构与传统主义者略有不同。本文讨论以下问题：

1. 迈向敏捷架构
2. 整个生命周期中的架构
3. 谁负责架构？
4. 拥有”架构所有者”的角色
5. 大规模的敏捷架构
6. 根据需求建立您的架构
7. 为您的架构建模
8. 考虑几种选择
9. 记住企业约束
10. 旅行灯
11. 用工作代码证明你的架构
12. 沟通您的架构
13. 想想未来，等待行动（推迟承诺）
14. 采取多视图方法
15. 这是如何运作的？
16. 解决敏捷和架构周围的神话

1.迈向敏捷架构

体系结构提供了构建系统的基础，体系结构模型定义了体系结构所基于的愿景。架构的范围可以是单个应用程序，应用程序系列，组织，或许多组织共享的Internet等基础架构。无论范围如何，我的经验是您可以采用敏捷的架构建模，开发和发展方法。

这里有一些想法供你思考：

• 建筑没有什么特别之处。异端邪说！绝对不行。敏捷建模的谦逊价值表明，每个人对项目的价值都是平等的，所以任何担任架构师并努力工作的人都同样重要，但并不比其他人的努力更重要。是的，优秀的架构师拥有适合手头任务的专业技能，并且应该有有效应用这些技能的经验。然而，完全相同的东西可以说是好的开发人员、好的教练、好的高级管理人员等等。谦虚是建筑工作中一个重要的成功因素，因为你需要避免象牙塔的发展和队友的敌意。架构师的角色对大多数项目都是有效的，不应该由基座上的人来完成。
  
  [En]

  nothing special about the architecture. Heresy! Absolutely not. The humble value of agile modeling shows that everyone has equal value to the project, so anyone who serves as an architect and who works hard is equally important, but no more important than the efforts of others. Yes, good architects have professional skills suitable for the task at hand and should have experience in applying these skills effectively. However, the exact same thing can be said to be good developers, good coaches, good senior managers, and so on. Modesty is an important success factor in your architectural work because you need to avoid the development of ivory towers and the hostility of your teammates. The role of the architect is valid for most projects, and it should not be done by someone on the pedestal.*

• 你应该提防象牙塔式架构。象牙塔式架构通常由架构师或架构团队开发，与项目团队的日常开发活动相对隔离。强大的架构专家会开发并开发一个或多个模型描述了团队中的仆从为架构师建立的最佳体系结构。象牙塔架构通常是美丽的东西，通常有很多花哨的图表和精彩的视觉陈述，宣称它们是你的救赎。理论上，这通常是您的架构师的工作基础，象牙塔式架构完美地运作。然而，经验表明象牙塔架构存在重大问题。首先，”minion开发者”不太可能接受这种架构，因为他们在开发过程中没有发言权。其次，象牙塔式架构通常是未经证实的，象牙塔式架构师很少会弄脏他们编写代码的手，因此在您知道他们实际通过技术原型提供的具体反馈之前，您的项目将面临重大风险。第三，如果架构师除了模型之外什么也不做，因为你无法思考系统所需的一切，象牙塔架构将是不完整的。第四，象牙塔式架构促进了软件的过度建设，因为它们通常反映了任何系统所需的每个功能。架构师曾经参与其中，而不仅仅是您的系统实际需要的功能。
• 每个系统都有一个架构。但是，它可能不一定具有描述该架构的架构模型。例如，一个小团队采用XP方法在同一个房间里一起工作可能没有必要对他们的系统架构进行建模，因为团队中的每个人都非常了解模型并不能为他们提供足够的价值。或者，如果存在架构模型，则通常会有一些简单的旧白板（POW）草图可能由定义的项目隐喻支持。这是因为XP的通信方面，包括结对编程和集体所有权，否定了需要在整个项目中开发和维护的架构模型的需要。其他团队 – 不遵循XP的团队，更大的团队，人员不在同一地点的团队 – 将发现他们的环境中固有的更大的沟通挑战要求他们超越口碑架构。这些团队将选择创建架构模型，以便为开发人员提供有关如何构建软件的指导。从根本上说，您执行体系结构建模的原因是为了解决开发团队成员无法实现共同愿景的风险。
• 架构规模敏捷。传统技术也是如此。为项目制定可行且可接受的架构策略对于您的成功至关重要，尤其是在敏捷团队大规模发现的复杂情况下。扩展问题包括团队规模，法规遵从性，分布式团队，技术复杂性等（有关详细信息，请参阅软件开发上下文框架（SDCF））。一种有效的体系结构方法使您能够解决这些扩展问题。

2.整个生命周期的架构

图1描绘了敏捷模型驱动开发（AMDD）的生命周期。在”迭代0″（Disciplined Agile Delivery（DAD）中的初始阶段），您需要使项目井井有条并朝着正确的方向前进。这项工作的一部分是初步要求设想和架构设想，以便您能够回答有关项目的范围，成本，进度和技术策略的关键问题。从架构的角度来看，在迭代0期间，目标是确定您的团队的潜在技术方向以及您可能面临的任何技术风险（应通过代码证明风险来解决）。此时您不需要详细的架构规范，事实上在软件开发项目开始时创建这样的规范是一个非常大的风险。相反，在迭代期间通过在每次迭代开始时的初始迭代建模或通过在整个迭代中进行模拟计划，在实时（JIT）基础上识别细节。最终的结果是，体系结构随着时间的推移逐渐出现，最初由于更需要设置项目的基础而更快，但是随着时间的推移仍在不断发展，以反映对开发团队的更多理解和了解。这遵循小增量中的实践模型并降低项目的技术风险 – 您始终拥有一个坚实且经过验证的基础，可以从中工作。换句话说，你想要考虑未来，但等待采取行动。

图1.软件项目的敏捷模型驱动开发（AMDD）生命周期。

图2描述了Disciplined Agile Delivery（DAD）工具包描述的敏捷/基本生命周期。DAD工具包具有本文中描述的所有体系结构策略.DAD是一种混合体，它采用来自各种来源的策略，包括敏捷建模，Scrum，XP，敏捷数据等等。实际上，DAD在处理方面做了”繁重的工作”，因为它捕获了来自这些不同方法的想法如何组合在一起。因为DAD不是规定性的，所以它支持几个生命周期。图2的生命周期是DAD基于Scrum或”基本”的敏捷交付生命周期，但它也支持精益/看板类型的生命周期和持续交付生命周期。我们的想法是，您的团队应该采用对您所面临的情况最有意义的生命周期。

图2. DAD Agile生命周期（单击以展开）。

这种轻量级初始体系结构建模方法的替代方法是尝试在实现开始之前完全定义您的体系结构。这种极端通常被称为预先设计（BDUF）。这种方法背后的动机通常是项目管理不希望任何人前进，直到就方法或”一个数据真相”达成共识。不幸的是，这种方法通常导致没有人向前推进很长一段时间，象牙塔式架构往往在实践中证明是脆弱的，这种架构对于你实际需要的东西来说是过度的，和/或开发子团队在他们的拥有，因为他们不能等待架构师完成他们的工作。这种方法通常是所涉人员的一种思维方式的结果，是瀑布式软件开发时代（20世纪70年代和80年代，当今许多管理人员都是软件开发人员）的遗留思维过程。现实情况是，架构的发展非常艰难，这是您成功的关键，也是您从一开始就无法做到的。进化（迭代和增量）方法通过一次开发一次，并且只在您需要它时，解决了架构不充分或不适当的风险。

3.谁对架构负责？

这个问题比你想象的要复杂得多。答案很简单，适用于小型敏捷团队(绝大多数)，每个人都对体系结构负责。实践模式和其他人告诉你，你真的不想单独工作。坦率地说，架构是非常重要的，无论它们有多聪明，都不能停留在一个人的手中，所以架构应该是团队的努力。在一个小的项目团队中，比如15人或更少，我更喜欢包括所有的开发人员，因为这允许所有的参与者在体系结构中表达他们的观点。这增加了每个人对体系结构的理解和接受程度，因为他们作为一个团队一起工作。当架构被证明不合适时，它还会增加开发人员愿意更改架构的机会，而且它可能不会像您最初想象的那样进行扩展，因为这是团队的架构，而不仅仅是他们的架构。当一个人发展了一些东西，它就变成了“他们的孩子”，没有人喜欢听到他们的孩子很丑–当你发现他们的架构有问题时，他们可能会抵制任何批评。当整个团队开发一个架构时，人们通常更愿意重新考虑他们的方法，因为这是一个团队问题，而不是个人问题。

但是，”每个人都拥有架构”战略存在两个基本问题：

• 有时人们会有不同意见。当团队不同意时，该策略可能会急剧崩溃，因此您需要具有架构所有者角色的人来促进协议的达成。
  
  [En]

  sometimes people disagree. This strategy can collapse dramatically when the team does not agree, so you need someone with the role of architecture owner to facilitate the agreement.*

• 它不会扩展。当您的团队规模较大或地理位置分散时，在软件开发上下文框架（SDCF）中调出的八个缩放因子中的两个，您将组织您的团队成为一个子团队。在这种情况下，大规模的架构需要协调机构。

4.拥有”架构所有者”

对于任何相当复杂的系统，您需要花一些时间来构建它。您将做一些前期架构设想，让您开始朝着正确的方向前进，然后架构将需要从那里发展。许多敏捷团队发现他们需要扮演”架构所有者”角色的人，有时称为敏捷解决方案架构师。这个人通常是团队中技术最有经验的人，负责促进架构建模和演变工作。就像Scrum的产品所有者角色负责团队的要求一样，架构所有者负责团队的架构。架构所有者是Disciplined Agile（DA）工具包中的主要角色之一。

建筑所有者的传统角色不同于建筑师的角色。在过去，建筑师往往成为建筑的主要创造者，也是少数参与其中的人之一。他们经常开发体系结构，然后“开发”它，或者更准确地说，强迫它的开发团队。架构所有者与团队一起开发和开发架构。尽管他们是架构方面的最终决策者，但这些决策应该以与团队协作的方式做出。有效的架构所有者是在组织所使用的技术方面经验丰富并能够使用架构高峰来探索新策略的开发人员。他们还应该对业务领域有很好的了解，并拥有必要的技能来与开发人员和其他项目干系人沟通体系结构。

5.规模敏捷架构

在大型敏捷团队、地理上分散的敏捷团队或企业范围的架构工作中，您将需要架构所有者团队或企业架构团队(在敏捷建模中，我最初将其称为核心架构团队。这是一个我从未真正喜欢过的术语)。大型敏捷团队通常被组织成较小的子团队，如图3所示。每个子团队的架构所有者是架构所有者团队的成员，这有助于增加每个子团队理解和遵循整体架构的机会。并增加总体架构战略满足总体解决方案所有需求的可能性。将有一个总的首席架构所有者，这可能是一个轮换的角色，负责推动团队。

图3.大规模的敏捷团队被组织成子团队的集合。

组织大规模敏捷团队有四种基本策略：

• 架构驱动的方法。使用此策略，您可以围绕架构中调出的子系统/组件组织子团队。当您的架构具有高质量（松散耦合且高度内聚）并且在子团队真正开始之前已经识别出子系统的接口时，这种策略很有效（接口会随着时间的推移而发展，但您希望获得良好的开端）在他们最初）。该策略面临的挑战是，它需要以反映架构的方式捕获您的需求。例如，如果您的体系结构基于大型业务域组件，那么一个需求应尽可能专注于单个业务域。如果您的体系结构基于技术层 – 例如具有用户界面（UI），业务和数据层的3层体系结构 – 那么如果可能，需求应该集中在单个层上。
• 特征驱动的方法。通过此策略，每个子团队一次实现一个功能，这对涉众来说是一个有意义的功能块。我将把这个策略应用到体系结构中，以显示大量的耦合，并且您可以使用复杂的开发实践。这种方法的挑战在于，子团队经常需要访问各种源代码来实现此功能，从而冒着与其他子团队发生冲突的风险。因此，这些团队参与了复杂的变更管理、持续集成，甚至可能是并行的独立测试策略(仅举几例)。
  
  [En]

  feature-driven method. Through this strategy, each subteam implements one function at a time, which is a meaningful functional block for stakeholders. I will apply this strategy to the architecture to show a lot of coupling, and you can use complex development practices. The challenge with this approach is that subteams often need to access a variety of source code to implement this functionality, risking conflicts with other subteams. As a result, these teams have engaged in complex change management, continuous integration, and perhaps even parallel independent testing strategies (to name a few).*

• 开源方法。使用该策略，一个或多个子系统/组件被开发为开源的，即使它是针对单个组织的(这称为内部开源)。该策略通常用于被许多团队广泛重用的子系统/组件，例如安全框架，并且必须快速发展以满足访问/使用它们的其他系统不断变化的需求。该策略要求您采用支持开放源码方法的工具和流程。
  
  [En]

  Open source method. Using this strategy, one or more subsystems / components are developed as open source, even if it is targeted at a single organization (this is called internal open source). This strategy is often used for subsystems / components that are widely reused by many teams, such as security frameworks, and must evolve rapidly to meet the changing needs of other systems that access / use them. This strategy requires you to adopt tools and processes that support open source methods.*

• 其组合。大多数敏捷团队会适当地结合前三种策略。
  
  [En]

  its combination. Most agile teams will combine the first three strategies appropriately.*

图4描绘了大规模敏捷项目的体系结构活动过程。您通常会看到在大型项目（通常称为程序），地理位置分散的项目，复杂（域或技术）项目或企业级（通常支持敏捷企业架构）上采用这种方法。这种方法有四个重要方面：

• 想象一下最初的架构。最小的架构所有者团队负责最初的架构愿景，然后将其提交给子团队进行反馈和后续发展。对于大型项目/项目，通常有其他敏捷团队成员参与这个初始建模工作，包括产品所有者，甚至关键的项目干系人。这项工作的架构预计将持续几天，对于非常大型或复杂的项目，将持续数周。对于企业体系结构工作，企业体系结构团队通常在初始项目建模工作中包括项目级应用程序/解决方案架构师，并且通常包括高管兴趣
  
  [En]

  imagine the initial architecture. The smallest team of architectural owners is responsible for the initial architectural vision and then brings it to the sub-team for feedback and subsequent evolution. For large projects / projects, there are usually other Agile team members involved in this initial modeling effort, including product owners and even key project stakeholders. The architecture of the work is expected to last for several days and for very large or complex projects for weeks. For enterprise architecture work, enterprise architecture teams usually include project-level application / solution architects in the initial project modeling work, and usually include executive interests*

• 与开发团队合作。在大型项目/程序中，如图3所示，体系结构所有者团队的成员将在项目的每个子团队中扮演积极的角色，将体系结构传递给子团队，并与他们一起以特定的方式演示一些体系结构实验。对于企业架构工作，企业架构师至少会担任顾问，他们的专长是企业架构，但更好的是，他们将成为关键项目团队的活跃成员，并在这些团队中承担架构所有者的角色。由于敏捷开发的协作性，架构所有者简单地制定最初的架构愿景，或者通过偶尔回顾他们的工作来“支持”项目团队，但他们必须“卷起袖子”，成为项目团队的积极成员。这将帮助他们避免创建“象牙塔结构”，这在理论上听起来不错，但在现实世界中却不切实际。它还有助于增加项目团队实际利用体系结构的机会。
  
  [En]

  work with the development team. In large projects / programs, as shown in figure 3, members of the architecture owner team will play an active role in each sub-team of the project, passing the architecture to the sub-teams and working with them to demonstrate some of the architecture experiments in a specific way. For enterprise architecture work, enterprise architects will at least act as consultants, and their expertise is enterprise architecture, but even better, they will become active members of key project teams and assume the role of architecture owners in these teams. Because of the collaborative nature of agile development, architecture owners simply make the initial architectural vision, or “support” the project team by occasionally reviewing their work, but they must “roll up their sleeves” and become active members of the project team. This will help them avoid creating “ivory tower structures”, which sounds good on paper but turns out to be impractical in the real world. It also helps to increase the opportunities for project teams to actually take advantage of the architecture.*

• 将架构传达给架构利益相关者。对于项目团队，架构利益相关者包括与敏捷交付团队一起工作的产品所有者、关键项目利益相关者，以及开发团队的其他成员。这些人需要了解体系结构的愿景、已经做出的权衡以及实现体系结构的当前状态。
  
  [En]

  communicate the architecture to architecture stakeholders. For project teams, architectural stakeholders include product owners who work with agile delivery teams, key project stakeholders, and other members of the development team. These people need to understand the vision of the architecture, the tradeoffs that have been made, and the current state of the implementation architecture.*

• 更新建筑工作。架构所有者团队会发现他们需要偶尔聚在一起，随着项目的进展改进架构，协商架构更改，并根据需要更新架构模型(如果有的话)。这些会议将在项目开始时频繁举行，随着架构的整合，需求将会越来越少。可能不是核心体系结构团队成员的开发子团队成员出席会议提供信息，或参与一些技术原型并分享结果，这将是很常见的。最好的会议很短，通常不超过一个小时，经常站在白板周围–每个人都应该为会议做好准备，愿意参加并讨论自己的问题，并像团队一样工作。很快就做出了决定。
  
  [En]

  update the architectural work. The architecture owner team will find that they need to get together occasionally, improve the architecture as the project progresses, negotiate schema changes, and update the schema model as needed, if any. These meetings will be held frequently at the beginning of the project, and as the architecture is consolidated, there will be less and less need. It will be common for development sub-team members who may not be members of the core architecture team to attend meetings to provide information, or to participate in some technical prototyping and share the findings. The best meetings are short, usually no more than an hour, and often stand around the whiteboard-everyone should be ready for the meeting, willing to attend and discuss their problems, and work as a team. A decision was made quickly.*

图4.大规模的敏捷架构流程

6.需求驱动的架构

您的体系结构必须基于需求，否则您将成为黑客攻击，就这么简单。在确定体系结构需求时，涉及积极利益相关者的实践对您的成功至关重要–请记住，需求来自项目利益相关者，而不是开发人员。良好的技术体系结构需求来源将包括您的用户及其直接管理人员，因为他们通常对技术需求和约束有一定的了解。运营商肯定会对您的部署架构有要求。面向业务的需求的最佳来源是您的期望–您的用户、他们的经理。您组织中的高级经理将获得可能导致系统潜在变化的见解。

正如您所期望的那样，应用正确的构件并并行创建多个模型的实践适合您的架构需求。当您处理体系结构的技术方面时，您将希望基于技术需求、约束和可能的更改案例。同样，当您处理体系结构的业务方面并可能确定软件子系统或业务组件时，您可能需要将重点放在描述关键使用需求的基本用例或用户故事上，以及可能应用于您的系统的关键业务规则。

体系结构团队(或体系结构所有者的小项目)会犯的一个常见错误是忽略现有的和相关的构件，例如描述组织现有技术基础设施的网络或部署图、企业业务模型(用例模型、流程)图、工作流图、公司业务规则等)，或者系统应该满足的公司部署标准(对于工作站、分支机构等)。是的，现有的构件可能过时了，或者根本不适用于您的工作，但您至少应该尝试检查它们，并尽可能地利用现有的工作。与合适的人一起阅读或讨论可能会为你节省大量精力。换句话说，不要忘记尽可能多地重用现有的构件。

理解体系结构建模的一个重要概念是，尽管它通常发生在项目的早期，但它从来都不是第一位的。基本上，您总是花时间来确定一些需求。其他一切都是黑客攻击，黑客不能敏捷。

7.建模你的架构

架构建模的主要目标应该是就您打算如何构建系统达成共识或理解。换句话说，你将建模以理解。我的经验是，99.999％的软件项目团队需要花一些时间来建模他们系统的架构，即使是依赖于隐喻来指导他们的开发工作的Scrum / XP团队也是如此。虽然你的XP团队正在识别你的系统的比喻，你和你的队友在开发你的初始版本时会想到好几周，但你经常会画出你认为你的系统如何工作的草图。在AM的练习放弃临时模型之后，您可能不会保留这些草图，这通常是因为它们是无法解决的想法，或者仅仅是因为您正在建模以了解问题，所以一旦您这样做，图表就不再对您有价值了。话虽如此，XP团队开发架构模型并没有错。这些模型可能就像你在公众可见的白板上留下的草图一样简单，因为虽然隐喻可以是非常有效的东西，但架构模型通常会提供团队所需的更多细节。正如您所期望的，Disciplined Agile Delivery（DAD）团队也将进行一些架构建模。

您如何以敏捷的方式为您的架构建模？我通常会努力创建一个或多个导航图，图表显示系统”景观”的概述。就像路线图概述了城镇的组织一样，您的导航图概述了系统的组织结构。导航图是系统架构视图的实例。当您阅读有关架构建模的书籍和论文时，作者提出的一个共同主题是需要各种架构观点，每位作者都会展示他或她自己的关键视图集合，您需要考虑这些观点。我的经验是，没有一套架构视图适合每个项目，而项目的性质将有助于定义您应该考虑创建的视图类型。这意味着您创建的导航图类型取决于您正在构建的系统的性质。这在概念上与AM的实践一致应用正确的工件，它告诉您应该使用正确的建模技术来完成手头的任务。例如，使用基于J2EE的技术构建复杂业务应用程序的团队可能会发现UML组件图和工作流图适合用作体系结构导航图。但是，构建企业数据仓库的团队可能倾向于使用基于其体系结构的数据模型和UML部署图。不同的项目，不同的架构视图，因此不同类型的导航图。有趣的是，两个项目都需要两个导航图，符合多模型原则。您需要灵活处理您的方法，因为一种尺寸并不适合所有情况。

组织将犯的一个常见错误是将其架构工作建立在其组织结构上。例如，具有强大数据组的组织可能希望将数据模型作为其体系结构的主要工件，而不管系统的实际性质如何。当你有锤子专家时，每个问题看起来都像钉子一样。当您使用新技术或尝试开发组织几乎没有经验的新系统时，这个问题非常普遍 – 过去运行良好的组织结构在您的新环境中可能不再适合您。有关架构和组织结构的含义的更多信息，请参阅Conway定律的组织模式。

要创建导航图，建模工作的主要驱动力应该是假设简单。创建简单内容的做法表明您应该努力识别可能的最简单的体系结构方法 – 您的体系结构越复杂，个体开发人员不会理解它的可能性就越大，错误和崩溃的机会就越大。此外，您的架构模型应包含正确级别的信息，显示系统的各个方面如何协同工作，而不是细节（这就是设计的全部内容）遵循实践描述模型简单。您还应该使用最简单的工具来完成这项工作，很多时候，您需要使用白板草图来模拟架构的关键方面。绘图工具可以使用CASE工具。普通旧白板（POW）可以使用绘图工具。当纸张和便利贴可以使用时，请勿使用POW。

重要的一点是，当您的所有通信都是面对面的时，导航地图通常足以描述您的体系结构。如果不是这样，当您的模式所有者无法与开发人员(其中一些人可能位于远程位置)密切合作时，您需要使用文档来补充图表。

当您进行架构建模时，您应该考虑利用可用的丰富架构模式，但您应该以有效的方式进行。”模式系统：面向模式的软件体系结构”这本书是开始学习常见体系结构模式的好地方，例如图层，管道和过滤器，代理，模型 – 视图 – 控制器和Blackboard。与分析和设计模式一样，应该按照惯例轻轻地应用模式 – 只有在明确需要时才将它们引入您的架构中。在此之前，如果您怀疑架构模式可能是合适的，那么您可能认为您将拥有需要代理的多个关键服务来源，然后对您的架构进行建模，以便在实际情况出现时应用此模式。请记住，您正在逐步开发系统，遵循小增量中的练习模型，并且您不需要在第一天就建立正确的体系结构（即使您愿意，也无法实现此目标）。

您应该认识到，您的架构模型将揭示您的系统对其他系统的依赖性或它们对您的依赖性。例如，您的系统可以通过Internet与信用卡处理服务交互，从遗留关系数据库访问数据，或为另一个内部应用程序生成XML数据结构。网络图和UML部署图对于识别这些依赖性非常有用，面向过程的模型（如工作流程图，UML活动图和数据流图）也非常有用。这意味着这些依赖关系表明可能需要遵循这样的做法：在您的团队与您共享依赖关系的系统的所有者之间正式化合同模型。理想情况下，许多这些模型已经到位，信用卡处理器可能具有您必须遵循的严格定义的协议，并且遗留数据库可能具有为其定义的物理数据模型，尽管诸如XML数据结构之类的新功能将需要足够的定义。有时，如果没有准确的文档，您需要对旧系统的现有接口进行分析，有时需要设计新的接口。在这两种情况下，都需要由您的团队，其他团队或合适的联合开发相应的合同模型。

您应该如何组织架构建模？在项目开始时，我通常会将体系结构团队聚集在一个单独的房间中，以听取初步想法。理想情况下，这次会议不会超过几个小时，但对于一些更大的项目，它可能会持续几天甚至几周(我会严肃地质疑任何超过两周的努力)。与往常一样，建模过程越长，由于缺乏反馈而偏离课程的可能性就越大。这次建模会议的目标是就我们正在建设的系统的格局达成初步协议，也许不是共识，但足够的共识，这样我们就可以开始作为一个团队向前推进。

8.考虑几种替代方案

正如精益软件开发告诉我们的那样，我们不应该尽早采取架构策略，而应该考虑几种替代方案，并且只要它们仍然可行，就让这些替代方案对我们”开放”。这意味着，当您在项目早期构想架构时，您应该真正设想出几种可能的架构。公平地说，这种策略并不是新的，事实上，这种策略已经在IT架构社区中推广了几十年，尽管并不总是如此。

9.记住企业约束

除最新的组织外，所有组织都有现有的技术基础设施。更成熟的组织可能包括：

• 他们试图实现的技术基础设施的“未来”愿景
  
  [En]

  the “future” vision of the technology infrastructure they are trying to achieve*

• 企业级标准和指南 – 用于开发，数据，用户界面，安全性等 – 项目团队应遵循的标准和指南
• 战略重用战略，以降低整体开发和运营成本
  
  [En]

  Strategic reuse strategy to reduce overall development and operational costs*

• 企业架构，战略重用和/或类似的团队，负责发展和推广这些事物
• 运营和支持组织，有时称为系统管理组织，负责在生产中运行组织的系统
  
  [En]

  Operations and support organizations, sometimes referred to as systems management organizations, are responsible for running the organization’s systems in production*

关键是这些企业级的考虑为开发团队提供了挑战和机遇。虽然每次构建新系统时都从一个干净的体系结构委员会开始是很好的，但现实是在大多数情况下，该策略是不合适的。多年来，我见过几个敏捷项目团队，因为他们选择从头开始，声称他们的体系结构随着时间的推移而出现，他们有勇气担心明天的问题，他们已经做出了潜在的可交付软件。他们经常，基本上是嘲笑任何其他敏捷的言论，认为他们证明了他们的嘲弄。训练有素的团队构建其体系结构出现在他们工作的组织环境中的系统。他们谦虚地认识到，他们不能做出他们想要的所有技术决定，但受到现有基础设施和愿景的限制。此外，它们还生产可在组织生态系统中使用的消耗性解决方案。

幸运的是，企业关注的焦点也很多。通过利用现有的基础架构团队，可以更快地提供，因为他们的构建更少。通过使用现有技术，或者至少通过使用企业愿景中提到的新技术（对您的组织来说是新的），他们通过帮助最小化运营成本来降低系统的总体拥有成本（TCO）。通过遵循公司发展准则，它们有助于提高工作的一致性和质量，增加其可维护性，以便将来负责发展和维护工作。顺便说一句，软件开发上下文框架（SDCF）的企业规程扩展因子是八个中唯一的扩展因子，这使得开发团队可能更容易实现，因为这个因素远离项目级别的重点（ “容易”的情况）到企业层面的焦点（”硬”情况）。

那你做了什么？至少，企业架构师和运营团队等企业团队是重要的利益相关者，应该由您的产品所有者代表。对于您的企业体系结构组，他们中的一个或多个可能成为您的开发团队的活跃成员，并具有体系结构所有者的角色。对于其他组，产品所有者可以根据需要选择以领域专家或技术专家的身份加入您的团队，并在适当的即兴基础上加入。

10.轻装上阵

您的架构工作的一个目标应该是轻装上阵，尽可能灵活。当一个五页的文档可以做时，不要创建一个五十页的文档。当图表执行时，不要创建一个五页的文档。当隐喻可以做时，不要创建图表。记住”他们不会读它（TAGRI）”的原则。

不确定如何创建文档？这是错误的，因为您可以随时返回到白板，但您浪费在创建不需要的构件或向构件添加不必要的细节上的时间已经一去不复返了。您的目标应该是考虑项目团队(或组织，甚至行业，取决于您的范围)面临的关键问题，而不应该创建大量文档。股东投资回报最大化的原则告诉你要专注于高价值的活动，比如作为一个团队解决难题，实现共同的愿景。同样，它告诉您避免低价值的活动，例如编写详细的文档或开发得分较高的图表。这些活动往往令人安心，因为它们提供了进步的幻觉，如果你试图避免处理棘手的问题，它们会给你提供一个跑题的来源，但实际上它们很少像你想象的那样有效。因为其他人很少看到比作者更多的东西。原则性软件是您的主要目标，这意味着您应该对您的体系结构进行建模，直到您认为您有了可行的策略，在这一点上，您应该继续开发软件而不是文档。

您希望在什么时候记录体系结构？在我看来，有两个例子可以让它变得“敏捷”。首先，当您有一个分布式开发团队，但找不到更有效的沟通方式(如面对面的对话)时，文档是一种选择。其次，在项目结束时，您希望留下足够的文档，以便其他人可以在以后了解您的方法。现实情况是，对于一个相当复杂的系统，要在代码中记录所有内容即使不是不可能，也是非常困难的。有时，描述您的体系结构的最佳位置是简短的概述文档。本文档应重点解释您的体系结构的关键方面，这些方面可能会被您的导航图捕获，其中可能包括关键体系结构要求的摘要，以及对您所做的“可疑”方面背后的关键决策的解释。与往常一样，如果您正在创建模式文档，则应该以正值递增，并且最好以最有效的方式执行。

很多人在发现架构没有”记录良好”时会感到担心，无论这意味着什么。我并不是很担心这个问题，但我担心的是架构是否真实，以及开发人员是否理解并接受它。如果您要优先考虑您的体系结构文档，拥有可行的体系结构，让开发人员理解该体系结构，并让所有开发人员都能使用它，那么我怀疑文档将在该列表中排在最后。想一想。

11.证明你的架构

实践证明它与代码指出模型只是一个抽象，一个看似非常好的模型在实践中可能实际上并非如此，你可以肯定知道的唯一方法是通过实现验证你的模型。这意味着你应该证明你的架构是有效的，XP称之为尖峰，RUP称为架构原型。当您的架构呼唤一些对您来说不熟悉的东西时，也许您是第一次使用两个或更多产品，您应该花时间来探索这种方法是否能够如何工作以及它是如何工作的原则快速反馈。记住要获得项目利益相关者的许可才能完成这项工作，因为这是他们花的钱。有时您会通过努力发现原始方法不起作用，我希望尽早发现，有时您会发现您的方法实际上是如何工作的（而不是您认为它的工作方式）。架构尖峰/原型的开发有助于降低项目风险，因为您可以快速发现您的方法是否可行，您还没有简单地制作象牙塔架构。

图5概述了优先需求”最佳实践”的敏捷方法。通过对交付生命周期的风险价值方法，Scrum价值驱动生命周期的扩展，您将确定解决项目主要技术风险的少数需求。例如，如果您的要求表明您的系统必须能够在10小时内每秒处理4,000个事务，那么这将是一个明确包含某些技术风险的要求。这是您希望在项目早期实现的一种要求，以确保您的体系结构真正起作用。我的一般规则是，当你进入为期6个月的项目仅18天而不是在”6个月项目”的8个月点结束时，最好发现你的架构策略需要重新考虑。这意味着，如果技术风险要求不在积压的首位，那么您需要与产品所有者密切合作，以说服他们重新确定优先级不高的要求。但是，如果您无法说服您的产品所有者这样做（我在实践中从未遇到过这个问题，但认识到可能会发生这种情况），那么您需要尊重他们的决定并接受以后证明您的架构的风险生命周期。

图5.工作积压。

12.传达您的架构

有两个主要的受众，架构的沟通很重要：您的开发团队和项目涉众。为了促进开发团队之间的交流，我坚信您应该遵循公开展示的模型的所有体系结构图，因为高度保密的体系结构不是体系结构，它只是一种徒劳的自我练习。我参与了几个项目，我们成功地维护了一个白板，专门用于向项目中的每个开发人员和其他碰巧经过的人公开显示的架构图。我们还允许任何人根据公开和诚实沟通的原则和集体所有制的做法对图表提出意见或建议，因为我们希望他们对我们的工作给予反馈。我们没有什么可隐瞒和信任的，别人愿意帮助我们(他们愿意)。

在项目开始时，您经常会发现您需要使图表“看起来很漂亮”，以便您可以将它们呈现给您的项目涉众。您的利益相关者想知道什么是正确的，以及您打算采取什么方法来确定您是否明智地投资资源，这意味着您需要构建模型来交流和定位您的一些模型，以便其他人能够理解它们。这可能意味着您需要花时间清理模型，以便可以渲染它们并记录它们的概述。为了尽可能保持灵活性，有目的的模型原则告诉您，您应该确切地知道您正在为谁开发模型，以及他们将为谁使用它们，以便您可以专注于所需的最小工作量。向关键项目干系人演示通常会让开发人员感到恼火和分心，这对项目的成功至关重要，因为他们为您提供了获得项目支持和所需资源的机会。此外，您还可以增加利益相关者的重要性，使您能够积极参与项目(如果您没有可用的利益相关者，则不能遵循积极参与的做法)。

准备好在演示文稿中传达您的体系结构，没有理由不能保持演示文稿的灵活性。

13.考虑未来，但不要过度建设（推迟承诺）

我怀疑关于敏捷架构建模的最具争议性的概念是你应该考虑未来的变化，但在你真正需要之前不要采取行动。换句话说，不要过度构建你的系统，但同时要聪明一点。XP社区对于过度构建软件的概念相当直率，他们相信”你无论如何都不需要它”（YAGNI）。基本思想是你无法准确预测未来[1]，因此不应该为未来的可能性而努力。相反，您今天应该专注于构建您现在需要的东西并干净地构建它，以便您的软件在需要时易于更改。明天，当您发现需要更改软件以满足新要求时，请更改它。当您过度构建软件以更加通用时，为了满足未来的潜在需求，您实际上正在做出非常严肃的权衡：

• 很难估计你正在生产的东西的实际价值。你没有专注于满足今天的需求，所以你不会给你的用户带来直接的价值。我参与了几个项目，在过去的几个月里，在前几个季度的几个案例中，我们专注于开发一个通用的基础设施(持久性框架、消息传递框架等)。构建技术上有趣的东西当然很有趣，但它们对我们的用户毫无价值。
  
  [En]

  it is difficult to estimate the actual value of what you are producing. You are not focused on meeting today’s needs, so that you will not bring direct value to your users. I’ve been involved in several projects, and in the last few months, in a few cases, in the first few quarters, we focused on developing a common infrastructure (persistence framework, messaging framework, etc.). We certainly have a lot of fun building things that are technically interesting, but they are of no value to our users.*

• 你是在猜测。你真的不知道你是否需要你正在建造的东西–当一辆大众就足够的时候，你可能正在建造一辆保时捷。
  
  [En]

  you’re guessing. You really don’t know if you even need anything you’re building-you may be building a Porsche when a Volkswagen is enough.*

• 你增加了维护负担。您今天过度建造的任何东西都需要在项目的整个生命周期中进行测试和维护，这违反了Travel Light的原则。
• 尚不清楚在多大程度上需要测试当你过度建造一些东西时，唯一准确验证它的方法是通过虚构的反馈–没有人要求你过度建造任何东西，所以没有人可以验证你的工作。此外，大多数开发团队测试风险，但如果您猜测需求，您也会猜测风险级别。
  
  [En]

  it is not clear to what extent it needs to be tested. When you overbuild something, the only way to accurately verify it is through fictional feedback-no one asks you to overbuild anything, so no one can verify your work. In addition, most development teams test the risk, but if you guess the requirements, you also guess the risk level.*

那么，你怎么才能对这一切变得聪明呢？尽管你不想基于未来/神话般的需求过度构建系统，但思考未来是没有问题的。这是一个分两个阶段的战略：

• 初始建模。做一些初步的架构，设想思考问题，探索关键概念，从而让你朝着正确的方向前进。这并不意味着您需要创建大量的架构文档，尽管您可能会进行一些建模，是的，egads！，甚至可以创建足够的架构文档来满足您的需求。
• 推迟设计决定。精益软件开发的原则之一是将承诺推迟到决策的最后时刻，从而增加您的灵活性和成功的机会。
  
  [En]

  postpone design decisions. One of the principles of lean software development is to postpone the commitment to the last possible moment of your decision, thereby increasing your flexibility and your chances of success.*

一个有趣的策略是变更案例建模。变更案例用于描述系统的新潜在要求或对现有要求的修改。变更案例是您未来可能需要或可能不需要支持的要求，但您今天绝对不需要支持。变更案例通常是与项目利益相关者进行头脑风暴的结果，其中诸如”业务如何变化？”等问题。”什么立法可以改变？” “你的竞争对手在做什么？”和”还有谁可能会使用该系统以及如何使用？”在技术方面，开发人员经常会提出诸如”什么技术可以改变？”等基本问题。和”我们需要与哪些系统进行交互？”这将导致识别变更案例。变更案例应该是现实的，例如”我们为银行进入保险业务”或”我们需要支持我们系统中的[INSERT FLASHY NEW TECHNOLOGY]”是合理的变更案例，但”我们的销售人员被不明飞行物绑架” “T。此外，变更案例通常描述的要求与您当前正在处理的要求相当不同，这些要求可能会导致重大的返工。通过识别变更案例，您现在可以智能地选择看起来与架构或设计决策相同的内容。当您的当前要求不足以帮助您在备选方案之间进行选择时，您应该只将相关的变更案例纳入决策过程。另一个优点是你现在可以向你的项目利益相关者解释为什么你选择一种方法而不是另一种方法，因为我想说你有一个故事要讲。但是，我不能强调改变案例不应该被用作为你的系统镀金的借口。保持敏捷，不要过度构建系统。那么当你认为你有一个你真正相信现在需要实施的变革案例时，你会怎么做？简单 – 与项目利益相关者讨论。询问他们是否立即要求变更案例，如果是，则相应地采取行动。如果这不是一个直接的要求，那么接受这个事实并继续前进。永远不要忘记项目利益相关者有责任确定需求的优先级，而不是您的需求。

未来的建模会不会受到影响？这是一场压倒性的胜利，因为我怀疑，如果你对它进行建模，那么你更有可能建造它。我认为，这需要严格的纪律，不要过度建设，因为一旦你把它捕捉为一系列的泡沫和线条，很容易说服自己，过度建设一次没有坏处。正如已经说过的，在讨论变更案例时，制作丢弃的草图并没有什么错，只是不要过度模仿您打算保留的任何模型。

14.采用多视图方法

敏捷建模的多模型原则建议您认识到，因为现代系统很复杂，您需要考虑架构中的一系列视图。虽然它们采用不同的方法，但多视图策略是现代架构框架中的基本概念，例如Zachman框架，TOGAF，4 + 1等。这些框架中的每一个都有很好的理由来选择视图，它们在实践中似乎都运行良好，它们都可以灵活地进行处理，所以我的建议是检查您的选项并选择最能反映出来的架构框架。您组织的文化。我的目标不是提出另一个架构框架，而是让您了解它们及其基本概念。图6概述了软件/系统架构师需要关注的视图和关注点（通常称为服务质量要求）。

图6.架构视图和关注点。

视图/视点被捕获为图表和文本描述（例如用例，技术规范或散文）的组合。潜在的问题，可能是您自己的观点，您的架构应该解决的观点包括：

• 用法/业务流程
• 用户界面
• 系统界面
• 网络
• 部署
• 硬件
• 数据存储
• 数据传输
• 活动
• 代码/组件分发
• 功能/逻辑/服务

借用面向方面编程（AOP）的语言，您的架构也可能需要考虑”横切关注点”。这些问题/观点也应该通过您的架构视图来解决，在某些情况下可能是您自己的特定视图。这些担忧包括：

• 分层/分区
• 重用
• 质量和验证
• 准确性和及时性
• 可靠性、可用性、可维护性和性能
  
  [En]

  Reliability, availability, maintainability and performance*

• 环境（绿色计算问题）
• 定制点
• 可消耗性（包括（de）安装的简易性，支持级别，可用性，……）
• 并发
• 安全
• 国际化
• 条例
• 维护，操作和支持问题

这意味着任何扮演架构师角色的人都需要具备广泛的技能来工作，他们需要摆脱过度专业化的传统哲学，更多地成为一名泛化的专家。至少，他们应该从简单的数据架构师、安全架构师或网络架构师转变为架构师。仅仅成为一名架构师可能太专业了，但这取决于具体情况。真正的专业人士努力拥有广泛的技能和一个或多个专业。

15.这是如何工作的？

我所描述的架构方法与许多组织目前正在做的事情明显不同。表1比较并对比了许多组织中常见的架构实践与敏捷对应的架构实践。显然，这有很大的不同。敏捷方法之所以有效，是因为它专注于团队合作的人员。敏捷建模认识到人们是错误的，他们不太可能从一开始就获得正确的架构，因此需要有机会根据实施工作的反馈行事。当敏捷架构师是开发团队的高效成员，并且当开发团队参与开始的架构工作时，他们不需要全面的文档，导航图就足够了（授予，当这不是案件文件，希望最小，可能是必需的）。不需要架构评论，因为架构是通过架构原型设计/峰值的具体反馈来证明的，因为人们可以看到架构发展，因为您的模型公开展示供所有人查看。敏捷架构师有勇气专注于解决当今的问题并相信他们明天可以解决明天的问题（Beck，2000），以及认识到他们无法准确预测未来并因此选择不过度构建他们的架构的谦虚。

表1.比较常见和敏捷架构实践。

建筑师很受人尊敬，经常被奉为偶像，甚至更糟的是，被奉为偶像

常见的做法

敏捷实践

敏捷的架构师会谦虚地承认，他们不是在水上行走。

建筑师太忙了，没有时间自己开发它。

敏捷架构师是开发团队中的活跃成员，在正确的地方开发软件，并充当团队的架构顾问

该体系结构模型是健壮的，可以满足未来的需求。

敏捷架构师应该谦虚地承认，他们无法预测未来，但应该有勇气相信他们可以解决明天的问题。

我们的目标是在项目早期开发一个全面的体系结构。

您以增量和迭代的方式发展您的体系结构，允许它随着时间的推移而出现

需要一个文档齐全的体系结构模型

轻装上阵，专注于勾勒出架构的导航地图，并记录足够的信息以与目标受众交流

架构模型只有在”适合公共使用”时才进行交流

建筑模型是公开展示的，即使它们是促进来自其他人的反馈的持续工作

在将模型投入使用之前，进行体系结构审查以验证模型

通过混凝土试验对结构进行了验证。

16.解决敏捷和架构周围的神话

我想通过解决我在世界各地的组织工作中仍然遇到的一些常见的误解来结束这篇文章。

• 敏捷的人不做架构。我的希望是，这篇文章将坚定地把这个神话放在一边。
  
  [En]

  Agile people do not do architecture. My hope is that this article will put this myth firmly aside.*

• 您需要进行详细的前期架构建模。您应该进行一些前期架构建模，以确定您的一般技术策略，识别您可能遇到的潜在技术挑战，并帮助您在团队中围绕技术方向达成共识。关键是你不需要很多细节来实现这些目标。采用”大型模型预测（BMUF）”方法是一种选择，这种方法在理论上听起来很棒，特别是如果你是一名专业建模师，但在实践中通常被证明是一个相当差的人。BMUF战略导致糟糕的决策和解决方案不太可能满足利益相关者的实际需求，降低您支持不断变化的需求的能力，并导致士气低落。
• 建筑师对建筑负责。尽管许多组织选择支持主要负责建筑活动的专业建筑师，但这在实践中被证明是一个相当糟糕的选择，因为开发人员可能会将建筑师视为“象牙塔”，并经常选择忽视他们。正如您在本文中看到的，有效的架构策略本质上是协作的，而不是专制的。
  
  [En]

  the architect is responsible for the architecture. Although many organizations choose to support professional architects who are primarily responsible for architectural activities, this turns out to be a pretty bad choice in practice, because developers may regard architects as “ivory towers” and often choose to ignore them. As you can see in this article, effective architectural strategies are collaborative rather than autocratic in nature.*

感谢您的关注、转发和点赞。

Original: https://blog.51cto.com/jiagoushipro/5560366
Author: 超级架构师
Title: 「敏捷模型」敏捷架构：规模化敏捷开发的策略