许多人讨厌架构评审。
我能理解他们。当它作为一个无聊且无用的委员会完成时，充满了不明白你在说什么的人，但仍会做出决定。
但是架构审查是一种有效的机制，可以确保具有不同观点、约束和时间范围的利益相关者之间的决策保持一致。
作为此类流程的负责人，我个人承诺进行类似于同行评审的架构评审：一个提高质量和速度的有用流程。
什么是架构评审作为同行评审？
架构审查是一个在软件生命周期中充当质量门的过程，在受即将发生的变化影响的利益相关者之间执行。
架构审查的目标是：
- 澄清并评估变革的必要性
- 生成解决问题的替代方案
- 确定方案之间的利弊权衡
- 评估非功能性需求和约束
- 识别潜在的重用机会和风险
- 减少由于设计不佳而导致后期返工和问题的可能性
- 捕捉重要设计决策的基本原理
- 发现或强化平台基础的需求
- 确保做出有利于共享标准的决定
- 使利益相关者在景观变化的请求中保持一致。
这种做法在建筑等其他领域很常见，建筑师与建筑商、您自己和办公室的同事一起审查其计划，以调整将要完成的工作。
软件的不同之处在于变化是连续的。
在未来 10 年内，您可能会在家中进行扩建，从而规划您的花园相对容易。这是另一个具有高度不确定性的问题。
软件必须不断发展，才能在短期内交付价值，并满足多层架构支持的长期目标。
这就是为什么可以在不同级别进行架构审查：企业、功能、应用程序、技术、软件、基础设施、安全性。
复杂主题的参与者数量往往会产生一个低效的过程，当人们玩弄权力和政治时，这种情况会变得更糟。
实施架构审查的适应性过程作为同行审查能够以最小的努力使利益相关者保持一致，同时实现最高的质量和速度。
为什么在质量工程中使用架构审查？
质量工程是约束整个软件生命周期以持续交付 Quality at Speed 软件的范例。
数字化的压力正在推动组织通过软件重塑他们的产品以产生新的价值流。
公司只有通过质量满足成功用户体验的期望，并率先以速度获取价值，才能取得成功。
架构审查如何为质量做出贡献？
软件质量取决于相关涉众、他们的需求、目标和看法；质量上的一致性需要使他们的利益一致。
软件生命周期本质上分布在不同的活动和涉众之间，从而减少了它们之间的正式交互和共享。
架构审查是一种有效的方式，可以为决策相关的利益相关者共享和验证即将发生的变化，并与方向保持一致。
架构审查有助于质量：
架构审查如何为 Speed速度 做出贡献？
架构审查，或更准确地说是委员会，因使用无用的模板和讨论而减慢计划的速度而声名狼藉。
虽然在具有高度自主权的筒仓中做出决策令人满意，但它很可能会遗漏关键信息，从而导致事后代价高昂的返工。
我的祖父总是说，纸上谈兵比完成后更容易改变；我完全同意，并提倡提高速度的架构审查。
架构审查有助于提高speed速度：
- 关注主要利益相关者，问题和要解决的问题
- 通过定义要解决的主题、里程碑和实施时间来确定节奏
- 利用门户、通知和协作工具的异步性
- 对即将发生的变化和决策理由的当前管道的可见性。
如何开始在 QE 中使用架构评审？
实施架构审查就像任何结构化计划一样，它必须在有限的范围内慢慢开始，然后在基础到位后扩展。
目标是以最小的努力做出有效的决定。因此，确保简单的更改在轻量级过程中快速进行，同时正确分离更大的计划。
坚持以下原则很重要：
- 不要使用“董事会”或“委员会”之类的状态名称
- 寻求最小的努力来验证更改
- 尽早让不同的利益相关者参与进来
- 提供指导方针而不是严格的规则
- 共享管道和决策的可见性
- 有节奏地驾驶以保持前进。
我们可以区分三个主要步骤来开始架构审查：
- 先决条件
- 过程
- 测量
准备架构审查先决条件
第一步包括安装支持架构审查过程和度量所需的基础。
您需要实施以下关键要素：
- 架构评论空间
- 架构审查流程
- 架构审查模板
- 架构决策记录
- 架构决策管道。
文档空间可以是您公司的知识门户，如 Confluence、Notion 和类似的替代品。使用下一个元素构建它很重要。
首先，编写一个规范审查过程的页面：
- 明确说明为什么、什么、谁、何时、如何
- 明确谁是流程的负责人
- 定义利益相关者的参与方式和决策制定方式
- 添加过去的例子，它可能会有所作为
- 说明何时执行架构以使流程清晰
- 提供其他领域的相关指示。
架构审查模板可以非常简单，坚持提供指导而非规则。一种有效的方法是每个体系结构审查一页，其中给出了上下文、主题和利益相关者，以及主题审查的计划。
架构审查的每个主题或子主题都可以依赖单张幻灯片问题摘要，然后是支持您的分析和论证的相关幻灯片。
最后要正式化的部分是架构决策记录 (ADR)和架构审查管道。
ADR是一份决策记录，记录了背景的关键要素、评估的选项和决策的理由。
ADR在许多赌注中都很有用：
- 确保会议中的每个人都保持一致
- 异步共享给许多利益相关者
- 系统化参考的变化，如制图
- 确定模式、标准和基础改进
- 避免以后出现诸如“为什么那样决定？”之类的问题。
为此，我推荐此页面包含有用的ADR 模板。
剩下的元素是架构审查管道，它将包含所有即将到来的、正在进行的和存档的架构审查，以及相关的文档链接。可以用一张表来实现，一个积压管理工具，选择一个简单的解决方案开始。
启动架构审查流程
开始您的架构审查过程将遵循组织之间的逐步部署，重点关注可以作为早期胜利的主题。
一种诱惑是尝试解决所有变化，但这不是现实的抱负。
遵循架构师 Gregor Hohpe 的建议：“Play or Pass”。
然后对添加到您的架构审查管道的选定主题应用架构审查流程：
- 形式化问题
- 确定要解决的子主题
- 计划所需的最少研讨会
- 编写架构决策记录
- 在利益相关者之间共享决策。
编写一个母版页，其中包含有关审查的所有参考信息，例如问题陈述、子主题列表、利益相关者和审查计划。
在执行准备工作坊后，计划每次审查会议：
- 准备好的单张幻灯片问题总结
- 支持讨论的附加内容
- 共享输入和决策所需的最少利益相关者。
审核完成后，将页面存档在特定区域，按照模板编写架构决策记录，并在组织中更广泛地共享之前与参与人员共享以进行验证。
使用测量来推动改进
通过实践、时间，最重要的是，持续改进，你会在“架构评审作为同行评审”过程中变得更好。
审查的目标是在短期和长期内加速交付有价值的软件，因此需要进行各种测量。
以下指标有助于衡量审核流程的绩效：
- 架构审查 NPS（为什么不呢？）
- 架构审查周期（从季度计划到决策）
- 架构审查返工（审查决策的时间）。
您可以使用有关 ADR 空间的视图数量、架构审查页面的可视化和参与度的事实指标来完善您的视图。
但最重要的结果很重要，从业务开始：
- 您是否正在交付更多 Quality at Speed 软件？（您可以使用 NPS、业务度量和 Accelerate 指标来完成此视图）
- 您是否正在为自己的轨迹做出更好的决定？（即重用资产，识别新机会，生成价值更高、风险更低的场景）
- 您是否从架构审查中获得了中期收益？（即能够通过以前做出的更好的决定来加速）
利益相关者的主观反馈也很有用，可以提出以下问题：
- 团队是否认为该过程有用并能带来价值？
- 利益相关者是否感到参与并影响了流程？
这种满意度衡量并不容易，但对您的主动性至关重要。由于看到收益的时间延迟，过程价值的很大一部分是不可见的，这可能令人沮丧。
这就是为什么使用事实指标完成测量并与利益相关者合作以调整流程以最大化价值创造的重要性。
架构评审作为 MAMOS 中的同行评审
对于希望通过质量工程加速的组织而言，架构审查的有效实施是游戏规则的改变者。
他们必须调整MAMOS的不同领域，包括方法、架构、管理和文化、组织和技能，以改造整个系统。
即使作为同行评审的架构评审是领域方法的一部分，它也能够系统地评估跨不同层的变化的适合性。
方法论与组织它们的人和接受参与的人一样乏味。如果它不起作用，请做些事情让它变得更好。
毕竟，您推动了变革。