24 架构师在项目中的角色

susemm

已于 2025-02-14 16:08:40 修改

阅读量1k

点赞数 18

分类专栏：软件架构实践（第4版）文章标签： java 数据库开发语言软件架构

于 2024-11-19 08:48:45 首次发布

本文链接：https://blog.youkuaiyun.com/susemm/article/details/143871758

版权

软件架构实践（第4版）专栏收录该内容

33 篇文章

订阅专栏

文章目录

第24章架构师在项目中的角色

第24章架构师在项目中的角色

我不知道为什么人们雇了架构师，然后又告诉他们该做什么。

——弗兰克·盖里（Frank Gehry）

任何在课堂之外进行的架构实践都发生在一个更大的开发项目背景下，而开发项目是由一个或多个组织中的人员进行规划和执行的。尽管架构非常重要，但它只是实现更大目标的手段。在本章中，我们将讨论架构的各个方面以及源于开发项目实际情况的架构师职责。

我们首先讨论一个关键的项目角色，即项目经理，作为架构师的你很可能与这个角色有着密切的工作关系。

24.1 架构师和项目经理

团队中最重要的关系之一是软件架构师和项目经理之间的关系。项目经理负责项目的整体绩效 —— 通常是确保项目在预算内、按时进行，并配备合适的人员从事合适的工作。为了履行这些职责，项目经理经常会向项目架构师寻求支持。

可以将项目经理主要视为对项目的面向外部的方面负责，而软件架构师则对项目的内部技术方面负责。外部视图需要准确反映内部情况，内部活动需要准确反映外部利益相关者的期望。也就是说，项目经理应该了解并向上级管理层反映项目中的进展和风险，而软件架构师应该了解并向开发人员反映外部利益相关者的关注点。项目经理和软件架构师之间的关系对项目的成功有很大影响。他们应该保持良好的工作关系，并注意他们所扮演的角色以及这些角色的界限。

《项目管理知识体系指南》（PMBOK）列出了项目经理的一些知识领域。在这些领域中，项目经理可能会向架构师寻求意见。表 24.1 确定了 PMBOK 所描述的知识领域以及软件架构师在该领域中的角色。

表 24.1 架构师在支持项目管理知识领域中的角色

PMBOK知识领域	描述	软件架构师角色
项目集成管理	确保项目的各个要素得到恰当的协调	进行设计并围绕设计组织团队；管理依赖关系。实现指标的收集。协调变更请求。
项目范围管理	确保项目包含所有必需的工作，并且只包含必需的工作	引出、协商并审查运行时需求，并生成开发需求。估计满足需求相关的成本、进度和风险。
项目时间管理	确保项目及时完成	帮助定义工作分解结构。定义跟踪措施。建议向软件开发团队分配资源。
项目成本管理	确保项目在所需预算内完成	从各个团队收集成本信息；就构建/购买决策以及资源分配提出建议。
项目质量管理	确保项目能够满足其开展的需求	为质量进行设计，并根据设计对系统进行跟踪。定义质量指标。
项目人力资源管理	确保项目充分有效地利用参与项目的人员。	定义所需的技术技能组合。为开发人员提供职业发展路径方面的指导。推荐培训。面试候选人。
项目沟通管理	确保项目信息及时、适当地生成、收集、传播、存储和处置	确保开发人员之间的沟通和协调。征求关于进度、问题和风险的反馈。监督文档工作。
项目风险管理	识别、分析和应对项目风险	识别并量化风险；调整架构和流程以减轻风险。
项目采购管理	从组织外部获取商品和服务	确定技术需求；推荐技术、培训和工具。

给架构师的建议

与项目经理保持良好的工作关系。了解项目经理的任务和关注点，以及作为架构师可能会被要求如何支持这些任务和关注点。

24.2 增量式架构与利益相关者

敏捷方法建立在增量开发的支柱之上，每个增量都为客户或用户提供价值。我们将在单独的章节中讨论敏捷与架构，但即使项目不是敏捷项目，仍然应该期望按照支持项目自身测试和发布计划的节奏增量式地开发和发布架构。

那么，增量式架构就是关于增量式地发布架构。具体来说，这意味着增量式地发布架构文档（如第 22 章所述）。这反过来又需要决定发布哪些视图（从计划的集合中）以及发布到何种深度。使用我们在第 1 章中概述的结构，可以考虑将以下内容作为你的第一个增量的候选：

模块分解结构。这将为开发项目提供团队结构信息，使项目组织得以形成。可以定义团队、配备人员、制定预算和进行培训。团队结构将是项目规划和预算的基础，因此这个技术结构定义了项目的管理结构。
模块 “使用” 结构。这将允许规划增量，这在任何希望增量式发布软件的项目中都至关重要。正如我们在第 1 章中所说，使用结构用于设计可以扩展以添加功能的系统，或者可以从中提取有用的功能子集。如果你不计划增量具体是什么，那么尝试创建一个特意支持增量开发的系统是有问题的。
最能传达整体解决方案方法的组件和连接器（C&C）结构。
一个大致的部署结构，至少要解决主要问题，例如系统是否将部署在移动设备上、在云基础设施上等。

在此之后，在制定后续版本的内容时，以架构的利益相关者的需求为指导。

给架构师的建议

首先也是最重要的，确保你知道你的利益相关者是谁以及他们的需求是什么，这样你就可以设计适当的解决方案和文档。此外：

与项目的利益相关者合作，确定发布节奏和每个项目增量的内容。
你的第一个架构增量应该包括模块分解和使用视图，以及一个初步的 C&C 视图。
利用你的影响力确保早期发布处理系统最具挑战性的质量属性要求，从而确保在开发周期后期不会出现令人不快的架构意外。
分阶段发布你的架构以支持那些项目增量，并在开发利益相关者处理每个增量时满足他们的需求。

24.3 架构与敏捷开发

敏捷开发最初是对一些开发方法的反抗，其中包括在流程方面僵化且重量级、在所需文档方面过于苛刻、专注于前期规划和设计，并最终以一次性交付为高潮，而每个人都希望这个交付结果一开始就与客户真正想要的东西相似。敏捷主义者主张将原本可能花费在流程和文档上的资源分配到弄清楚客户真正想要什么，并以小的、可测试的交付增量尽早提供。

关键问题是：在需求分析、风险缓解和架构设计方面，一个项目应该进行多少前期工作？这个问题没有单一的正确答案，但可以为任何给定的项目找到一个 “最佳点”。“正确” 的项目工作量取决于几个因素，其中最主要的是项目规模，但其他重要因素包括复杂的功能需求、高度苛刻的质量属性要求、易变的需求（与领域的 “先例性” 或新颖性相关）以及开发的分布程度。

那么架构师如何实现适当的敏捷性呢？图 24.1 展示了你的选择。可以选择瀑布式的 “前期大设计”（BDUF），如图 24.1 (a) 所示。或者可以完全不顾架构的谨慎性，相信敏捷主义者所说的 “涌现” 方法，即最终架构随着程序员交付他们的增量而出现，如图 24.1 (b) 所示。这种方法可能适用于小而简单的项目，这些项目可以迅速转向并根据需要进行简单的重构，但我们从未见过它在大型、复杂的项目中起作用。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 24.1 架构设计的三种方法

毫不奇怪，我们推荐的方法介于这两个极端之间：这是 “迭代 0” 方法，如图 24.1 © 所示。在你对需求有一定了解的项目中，你应该考虑通过执行几次属性驱动设计（ADD；在第 20 章中描述）的迭代来开始。这些设计迭代可以专注于选择主要的架构模式（包括一个参考架构，如果合适的话）、框架和组件。以如 24.2 节中所建议的方式，以有助于架构的利益相关者的方式支持项目的增量。早期，这将帮助你构建项目结构、定义工作分配和团队组建，并解决最关键的质量属性。如果需求发生变化 —— 特别是如果这些变化驱动质量属性需求 —— 采用敏捷实验的实践，其中使用 “尖峰” 来解决新需求。“尖峰” 是一个有时间限制的任务，创建它是为了回答技术问题或收集信息；它不旨在产生一个成品。尖峰在一个单独的代码分支中开发，如果成功，则合并到代码的主分支中。通过这种方式，可以从容应对新出现的需求并进行管理，而不会对整体开发过程造成太大干扰。

敏捷编程和架构并不总是处于最佳状态。2001 年的《敏捷宣言》，即敏捷运动的 “首要指令”，暗示架构是涌现的，不需要预先进行规划或设计。

过去（现在仍然）很容易找到已发表的关于敏捷的论述，宣称如果你没有交付可工作的软件，那么你就没有做任何有价值的事情。由此可以推断，如果你正在从事架构工作，那么你就是在从编程中拿走资源，因此，你在做 “毫无价值的事情”—— 架构，哼！写代码，架构就会自然涌现。

对于中型到大型系统，在严酷的经验压力下，这种观点不可避免地崩溃了。质量属性需求的解决方案不能简单地在开发的任意后期阶段 “附加” 到现有系统上。安全、高性能、安全性以及更多关注点的解决方案必须从一开始就设计到系统架构中，即使计划的前 20 个增量交付不涉及这些能力。是的，你可以开始编码，是的，架构会涌现 —— 但它会是错误的架构。

简而言之，对于敏捷和架构之间的任何结合，《敏捷宣言》都是一个相当糟糕的婚前协议。然而，伴随《宣言》的是 12 条敏捷原则，如果善意地解读，这些原则暗示了两个阵营之间的中间立场。表 24.2 列出了这些原则，并对每个原则提供了以架构为中心的评论。

表 24.2 敏捷原则与以架构为中心的视角

敏捷原则	以架构为中心的视角
我们的首要任务是通过尽早且持续地交付有价值的软件来满足客户需求。	绝对地
欢迎需求变更，即使在开发后期也如此。敏捷流程利用变更为客户带来竞争优势。	绝对地。这一原则可通过提供高度可修改性（第 8 章）和可部署性（第 5 章）的架构来实现。
频繁地交付可工作的软件，时间间隔从几周到几个月不等，倾向于更短的时间尺度。	绝对地，只要这一原则不被视为排除经过深思熟虑的架构。DevOps 在这方面可以发挥很大的作用，并且正如我们在第 5 章中所看到的，架构可以如何支持 DevOps。
业务人员和开发人员必须在整个项目期间每天一起工作。	正如我们在第 19 章中所讨论的，业务目标会导致质量属性需求，而架构的首要职责就是满足这些需求。
围绕积极主动的个人来构建项目。为他们提供所需的环境和支持，并相信他们能够完成工作。	虽然我们原则上同意，但许多开发人员缺乏经验。因此，一定要包括一位技术娴熟、经验丰富且积极主动的架构师来帮助指导这些人。
在开发团队中以及向开发团队传达信息的最有效方法是面对面交谈。	对于重要的系统来说，这是无稽之谈。人类发明书写是因为我们的大脑无法记住我们需要记住的所有事情。接口、协议、架构结构等等都需要被记录下来，反复指导的低效率和无效性以及由此产生的误解错误都证明了这一原则是错误的。按照这种说法，没有人应该制作用户手册，而应该只公布开发人员的电话号码，并公开邀请随时拨打。对于任何有维护阶段的系统（几乎是每个系统）来说，这也是无稽之谈，因为在维护阶段，最初的团队无处可寻。你要和谁进行面对面的交谈来了解重要的细节呢？关于这个问题，请参阅第 22 章以获取我们的指导。
可工作的软件是进度的主要衡量标准。	是的，只要“主要”不被理解为“唯一”，并且只要这一原则不被用作除了编码之外取消所有工作的借口。
敏捷流程促进可持续发展。发起者、开发人员和用户应该能够无限期地保持稳定的节奏。	绝对地
持续关注技术卓越性和良好的设计能增强敏捷性。	绝对地
简洁（即最大化未完成工作的艺术）至关重要。	是的，当然，只要理解我们未做的工作实际上可以安全地舍弃而不会对正在交付的系统造成损害。
最好的架构、需求和设计来自于自组织团队。	不，并非如此。最好的架构是由熟练、有才华、经过训练且经验丰富的架构师有意识地设计出来的，正如我们在第 20 章中所描述的那样。
团队会定期反思如何变得更有效率，然后相应地调整和改变其行为。	绝对地

所以有六个 “绝对地” 的赞同，四个一般性的赞同，以及两个强烈的反对。

敏捷，在其最初被编纂时，似乎在构建小型产品的小型组织中效果最佳。中等规模到大型规模的组织希望将敏捷应用于大型项目时，很快发现协调大量小型敏捷团队是一个巨大的挑战。在敏捷中，小团队在短时间内完成小部分工作。一个挑战是确保这些众多（几十个到几百个）小团队适当地划分了工作，以便没有工作被遗漏，也没有工作被重复做。另一个挑战是对团队的众多任务进行排序，以便他们的结果可以频繁且快速地合并，以产生一个合理运行的系统的下一个小增量。

在企业规模上应用敏捷的一个方法示例是规模化敏捷框架（SAFe），它大约在 2007 年出现，并且从那时起一直在不断完善。SAFe 提供了一个工作流、角色和流程的参考模型，在这个模型下，大型组织可以协调许多团队的活动，每个团队都以经典的敏捷方式运作，以系统地、成功地生产出一个大规模的系统。

SAFe 承认架构的作用。它接纳 “有意架构”，其定义会引起本书读者的共鸣。有意架构 “定义了一组有目的、有计划的架构策略和举措，这些策略和举措增强了解决方案的设计、性能和可用性，并为团队间的设计和实现同步提供指导。” 但 SAFe 也强烈建议一种称为 “涌现式设计” 的平衡力量，它 “为完全进化和增量式实现方法提供技术基础”(scaledagileframework.com)。我们认为，这些品质也会从有意架构中涌现出来，因为如果没有仔细的预先思考，快速进化的能力和支持增量式实现的能力是不会出现的。实际上，本书中涵盖了实现这些的方法。

24.4 架构和分布式开发

如今，大多数重要项目都是由分布式团队开发的，这里的 “分布式” 可能意味着分布在一栋建筑的不同楼层、一个工业园区的不同建筑、处于一两个不同时区的不同园区，或者分布在全球各地的不同部门或分包商之间。

分布式开发既有好处也有挑战：

成本：劳动力成本因地点而异，有一种观点认为将部分开发工作转移到低成本地区必然会降低项目的总体成本。实际上，经验表明，对于软件开发来说，从长远来看可能会节省成本。然而，在低成本地区的开发人员具备足够的领域专业知识之前，以及在管理实践适应分布式开发的困难之前，必须进行大量的返工，从而削减甚至可能抵消工资成本节省下来的资金。
技能组合和劳动力可用性：组织可能无法在一个地点雇佣到所有开发人员：搬迁成本可能很高，开发人员库的规模可能很小，或者所需的技能组合可能很专业且在一个地点不可用。以分布式方式开发系统允许工作转移到有工人的地方，而不是强迫工人转移到工作地点，尽管这会以增加沟通和协调成本为代价。
对当地市场的了解：开发针对其所在市场销售的系统变体的开发人员对合适的功能类型以及可能出现的文化问题类型有更多的了解。

分布式开发在项目中是如何进行的呢？假设模块 A 使用模块 B 的接口。随着时间的推移，情况发生变化，这个接口可能需要修改。因此，负责模块 B 的团队必须与负责模块 A 的团队进行协调，如图 24.2 所示。如果这种协调只涉及在共用自动售货机旁的简短交谈，那很容易，但如果涉及在其中一个团队处于半夜的时候预先计划的网络会议，那就不那么容易了。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

图 24.2 团队与模块之间的协调

更广泛地说，协调方法包括以下选项：

非正式接触：只有当团队在同一地点时，才可能在咖啡室或走廊中碰面等非正式接触。
文档：如果文档编写良好、组织有序且得到恰当传播，那么无论团队是否在同一地点，都可以将其用作协调团队的一种手段。
会议：团队可以举行预定的或临时的、面对面的或远程的会议，以帮助团队团结起来并提高对问题的认识。
异步电子通信：各种形式的异步电子通信可以用作协调机制，例如电子邮件、新闻组、博客和维基。

协调方法的选择取决于许多因素，包括组织的基础设施、企业文化、语言技能、涉及的时区以及依赖特定模块的团队数量。在组织建立起分布式团队之间的协调工作方法之前，团队之间的误解很可能会导致项目延迟，在某些情况下还会导致严重缺陷。

这对架构和架构师意味着什么呢？这意味着在分布式开发中，向团队分配职责比在集中式开发中更为重要，在集中式开发中，所有开发人员都在一个办公室，或者至少距离很近。这也意味着对模块依赖关系的关注比其在可修改性和性能等质量属性中的通常作用更加重要：由全球分布式团队所拥有的模块之间的依赖关系更有可能出现问题，应尽可能将其最小化。

此外，在分布式开发中，文档尤其重要。在同一地点的团队有各种非正式的协调可能性，例如去隔壁办公室，或在咖啡室或走廊中碰面。远程团队没有这些非正式机制可用，因此他们必须依赖更正式的机制，如文档，并且当出现疑问时，团队成员必须主动相互交谈。

在本书准备出版之际，由于新冠疫情危机，世界各地的公司都在学习应对远程参与和居家办公的做法。现在就确定这场大流行对商业世界的长期影响还为时过早，但似乎很可能会使分布式开发成为常态。一起工作的人们现在都通过电话会议进行；不再有走廊交谈或在自动售货机旁的会议。为了让工作能够继续进行，每个人都在学习适应分布式开发模式。看看这是否会带来任何新的架构趋势将是很有趣的事情。

24.5 小结

软件架构师在某种类型的开发项目背景下开展工作。因此，他们需要从这个角度理解自己的角色和职责。

项目经理和软件架构师可以被视为扮演互补的角色：经理从管理角度运行项目，架构师从技术解决方案角度运行项目。这两个角色在各种方面相互交叉，架构师可以支持经理以提高项目成功的机会。

在一个项目中，架构并非完全成形于宙斯的额头，而是以对利益相关者有用的增量方式发布。因此，架构师需要很好地理解架构的利益相关者及其信息需求。

敏捷方法专注于增量式开发。随着时间的推移，架构和敏捷（尽管它们一开始相处得并不融洽）已成为不可或缺的伙伴。

全球开发创造了对明确协调策略的需求，这种策略基于比集中式开发所需的更正式的策略。

24.6 扩展阅读

丹・保利什（Dan Paulish）写了一本关于在以架构为中心的环境中进行管理的优秀书籍 ——《以架构为中心的软件项目管理：实用指南》，本章中关于分布式开发的内容改编自他的书 [Paulish 02]。

你可以在scaledagileframework.com上了解 SAFe。在 SAFe 之前，敏捷社区的一些成员已经独立得出了一种中等量级的管理流程，该流程提倡前期架构。有关架构在敏捷项目中的作用，请参阅 [Coplein 10]。

项目管理的基本概念在 IEEE 指南《采用项目管理协会（PMI）标准：项目管理知识体系指南（第六版）》[IEEE 17] 中有所涵盖。

软件架构度量指标通常在项目中属于架构师的职责范围。库林（Coulin）等人的一篇论文提供了关于这个主题的文献的有用概述，并在此过程中对度量指标本身进行了分类 [Coulin 19]。

架构师在组织中占据独特的位置。他们被期望在系统的整个生命周期（从摇篮到坟墓）的所有阶段都能熟练应对。在项目的所有成员中，他们是对项目和系统的所有利益相关者的需求最敏感的人。他们通常被选为架构师的部分原因是他们具有高于平均水平的沟通技巧。《软件架构师电梯：重新定义数字企业中架构师的角色》[Hohpe 20] 描述了架构师在组织内外与各级人员互动的这种独特能力。