什么样的架构算得上“够用？”

作者 | Pierre Pureur, Kurt Bittner

译者 | 王强

策划 | Tina

要点

• 避免对 MVA 过度投资：MVA 必须对 MVP 当前面临的挑战作出回应，同时预测（但不是实际解决）MVP 未来将要面对的挑战。
• 如果 MVP 不成功，MVA 就是白费力气，但如果 MVP 成功，MVA 对产品的良性进化就非常重要了。
• MVP 和 MVA 就像两个绑在一根绳子上的登山者一样。MVP 带头前进，但不能领先太多，否则 MVA 会拖它的后腿。
• MVA 领先 MVP 太远也是没有意义的，因为与 MVP 价值相关的反馈可能会让创建 MVA 的决策失去意义。
• 在初始版本的开发过程中，MVA 需要基于一些可能不正确的假设，因此可能会发生一些过度投资，但一旦反馈循环发挥作用，这种情况就会得到纠正。
• 当 MVP 根据反馈而演变时必须重新审视与之对应的 MVA，为一个应用程序创建的架构被另一个应用程序复用时更要这样做。不同的应用程序支持不同的 MVP，因此可以满足不同的要求。

在之前的一系列文章中，我们介绍了一个称为最小可行架构（MVA）的概念。MVA 是对最小可行产品（MVP）的架构补充。MVA 的目的是确保 MVP 在技术上可行、可持续且可随着时间的推移而扩展，是 MVP 的平衡产物；它让 MVP 不至于沦为一次性的概念验证，使得 MVP 成为新产品的种子。

我们在敏捷环境中扩展了 MVP 的概念，将每个新产品版本都视为一个新的 MVP，其通过新增的，为客户服务的成果扩展了之前的 MVP。与 MVP 对应的 MVA 的发展应当足以支持 MVP 的增量改进。通过这种方式，产品及其相关的软件架构都能通过一系列增量改进的方式发展下去。这种共同进化过程如图 1 所示。

图 1：MVP 及其 MVA 在一系列增量交付中共同发展

所有这一切听起来都很不错，但我们也得提出一些基础性的问题，例如什么是“最小值”，以及我们如何知道什么状态是最小？类似地，什么才是“可行”的？

很多时候我们并不会花费大量时间或精力来寻找上述答案。团队被要求快速交付“新”产品（也称为 MVP），旨在刺激更多客户需求，并且他们会做一些技术架构工作（MVA）以将 MVP 发展为可发布的版本。

在这里，MVP 及其对应的 MVA 都是根据时间和资源限制来定义的，而不是基于对尚不能满足客户需求的产品成果的审慎分析来定义。

但是，如果我们花时间了解这些成果并基于此来制作 MVP 和 MVA 会怎样呢？

你怎么知道 MVP

是否是“最小”的？

产品是向客户交付成果的工具。产品的最小增量提供了单一的改进成果。每个版本都必须向产品的某些用户组提供至少一个改进成果。如果它不能改善至少一个成果，那么就不值得发布。如果它提供了不止一种改进成果，那么它可能就不是“最小的”。因此，最小的 MVP 应该恰好为一组用户提供了一种改进成果。

如果一个产品版本为产品的不同用户组改进了多个成果，那么产品开发组织就失去了更频繁地发布较小增量，以收集有关产品版本有效性反馈的机会。

在考虑某个产品增量是否是最小时，我们要牢记作者 Antoine de Saint-Exupéry 的一个观察结果：

“实现可以被称为完美之时，其状态并非无一笔可添画，而是无一笔可删减。”

很多团队都倾向于在版本中“再加一点就好”，但如果尊重“单一成果原则”，相比为了加这一点而延迟发布时间的做法，团队可以更快地交付价值并更快地获得反馈。

这里我们强调的是使用成果而不是产品功能的价值来明确讨论范围。如果你的 MVP 不是用成果来衡量的，那么想要明确范围就会更困难，因为我们很难看出哪些功能需要改善产出，哪些功能只是无用功。

组织很少有自信说某个 MVP 肯定会改善其客户成果，因此他们往往会用精益用户体验中的说法，以实验性的口吻来评价 MVP，例如：

“我们相信，让人们能够 [执行某些任务] 将改善 [某些期望的结果]。当我们观察 [对该结果的一些指标] 时，我们将证明这一点。”

你怎么知道 MVP 是否可行？

如果一个 MVP 所提供的价值前提被证明是正确的，并且开发和维护与其对应的 MVA 的成本不超过其财务收益，则这个 MVP 就是可行的。只有一种方法可以证明其可行性：让实际用户 / 客户使用该产品并提供反馈。“真正的用户 / 客户”很重要；内部利益相关者的能力不够，并且可能会存在认知偏见，因为正是他们的意见塑造了关于这个 MVP 的原始想法。手工选择的焦点小组可能无法代表广大客户群的需求，因为小组成员是由塑造 MVP 概念的人们选择的，而且他们也会存在认知偏见。

对于某些产品，可能需要很长一段时间才能确定其 MVP 的可行性，可能需要数周，有时甚至数月。早期反馈就算不能准确衡量 MVP 的价值大小，也许也能快速确定 MVP 是否有价值。在考虑你的 MVP 应该做成什么样的时候，你首先应该问问自己你将要如何判断它是有价值的，以及你需要多长时间才能知道这一点。

对可行性的评估还包括了对财务可行性的估计。我们不用深入研究财务决策过程，只需记住开发产品的成本净现值不能超过产品将产生的未来收益的净现值即可。开发 MVP 和 MVA 能够帮助组织确定这个等式中成本净现值的水平，但他们还需要找到评估收益净现值的方法。

为了让一个 MVP 可行，它还必须在产品的整个生命周期内得到支持。如果由于某种原因，产品在客户需要时却停止运行，那么该产品对客户就没有价值。这就是产品的 MVA 的用武之地：当一家公司向客户提供 MVP 时，他们就提出了支持该 MVP 的隐含承诺，直到他们告诉客户他们将不再提供支持为止。MVA 的目的是确保 MVP 交付的成果是受到支持的。

如何知道 MVA 是最小的？

MVP 和 MVA 加在一起，就能一点一点回答清楚“我们的产品（及其相关软件架构）是否可行，在产品的整个生命周期内是否一直获得支持且可靠？”这样的问题。每个 MVA 都尝试满足与 MVP 相关的质量属性要求（QAR）。如果它还满足与自己对应的 MVP 无关的其他 QAR，则 这个 MVA 就不是最小的。换句话说，MVA 仅支持与之对应的 MVP 中包含的成果，并且必须在产品的预期生命周期内提供支持，并预测那些应该在 QAR 中表达的未来需求。

MVA 必须对 MVP 当前面临的挑战作出回应，同时预测（但不是实际解决）MVP 未来将要面对的挑战。换句话说，我们不能让 MVA 进行代价巨大的返工来解决这些未来才会遇到的问题。一些返工是可以接受的，也是意料之中的，但“完全重写”这个词意味着架构已经失败，所有关于可行性的赌注都将落空。

因此，MVA 在“解决可能永远不存在的未来问题”和“让技术债务累积到导致架构破产的程度”之间保持着动态平衡。能够平衡这两种力量的正是我们的经验。

典型的问题是，开发团队认为他们非常了解 MVP 中隐含的，在未来会遇到的架构挑战。这种观念可能会导致团队对 MVA 投资过度，然后他们不得不频繁返工。例如，他们可能会说：

“我们知道我们以后需要一个消息传递机制，所以让我们现在就开发它吧，然后等企业用户来决定他们到底需要什么。”

他们是否需要消息传递机制取决于 QAR。如果无法在产品的预期生命周期内满足 MVP 的要求，他们可能是对的，但他们应该问的问题是“我们现在就需要它吗？”

如果 MVP 没能成功，他们花费大量时间和精力来开发的就会是一些没用的东西。但如果他们不开发这个组件，将来这个 MVP 可能会有一天没法继续用下去了，这意味着他们也会承担大量的技术债务。所以做好这个决策是非常重要的，并且它需要团队有丰富的权衡利弊的经验。一些能证明这个 MVP 将实现其目标的早期证据也很有用，能让团队了解他们在 MVA 上的工作是不是有用的。

在规划 MVA 的内容时，开发团队会问“我们需要满足哪些 QAR 才能长期可靠地交付 MVP，以及我们需要开展哪些技术工作？”。这里的架构不需要为了满足这些未来的需求而做到尽善尽美，但设计架构时确实需要预测为满足未来需求而可能做哪些更改。

第一个 MVA 需要多少架构工作？

开发团队创建第一个 MVA 时，所依据的是对这个 MVA 需要解决的问题的理解，而且这种理解往往是不成熟、不够充分的。他们一般也不会有什么 QAR，也许只有宽泛的组织“标准”可遵循，这些标准更偏理想化，不够精确。初始描述往往非常模糊，毫无帮助，例如“系统必须支持大量并发用户”“系统必须易于支持和维护”“系统必须能够抵御外部威胁”等。

开发团队还会收到利益相关者的一些早期声明，阐述他们对系统目标的一些想法。项目 / 产品赞助商经常会对 MVP 的成功做出不切实际的预测，这可能会导致开发团队在获得用户反馈之前对 MVA 的构建工作过度投入。

但是……有时项目发起人的预测是正确的，即使是过度建设的 MVA 也会在用户的高需求下陷入困境。即使对于简单的 MVA 来说，也有一些一定要遵循的原则。例如，大多数组织都无法承担一个安全性较差产品的后果，即便这个产品非常简单。

现实情况是，早期 MVA 与 MVP 一样，都是基于经验指导下的有根据的猜测做出来的。你可能不得不构建一些自己都怀疑可能没什么用的东西。初始版本的 MVA 多半会在某些领域过度构建，而在其他领域构建不足，你只能通过构建、发布和收集反馈这样的流程来了解到底哪里该补足，哪里可以砍掉。MVA 应该设计成足够获得用户反馈的架构，而不应该：

• 让组织的业务或声誉面临不可接受的风险，或
• 花费大量时间开发和完善 MVA，结果让重要的反馈姗姗来迟

撤销那些被证明是错误的最初假设 / 决定的成本是应当关注的要素。技术债务是初始 MVA 不可避免的后果，就像大多数 MVP 至少会在某些方面出现部分错误一样。所以我们需要快速获得反馈。

开发团队有时会试图从成功的系统中复制它们的架构来起步，使用供应商解决方案也是一个办法。如果你发现这种解决方案的某些方面不起作用时也不至于陷入供应商锁定的困境，那么这可能就是个好方法。但不要复制那些超出你们需求的架构，否则可能会产生你们无法承受的技术债务。另外，当 MVP 逐渐演变时，请不要在早期版本的 MVA 上流连忘返。

如何知道 MVA 是否可行？

在你发布产品增量改进之前，你是没法知道答案的。因为你并没有收集到关于这个 MVP 是否有用的反馈，如果没有反馈，你就不知道对应的 MVA 是否只是浪费时间，或者它是否可能需要在产品的生命周期内支持某一组产品功能。所以 MVA 必须通过的第一道关卡就是对 MVP 价值的评估。

我们相信每一个产品增量改进本质上都是一个新的 MVP。让 MVP 尽可能小巧的原因很简单：MVP 越大，它包含无价值内容的可能性就越大。如果 MVA 的目标是确保 MVP 的长期生存能力，那么让 MVP 保持较小的规模也能帮助避免 MVA 膨胀。

MVP 及其对应的 MVA 很像是两个用绳子绑在一起的登山者（参见图 2）。MVP 走在前面，MVA 不能落后太多，否则会伤害 MVP。因为 MVP 就像领头的攀登者，所以 MVA 领先于 MVP 也是没有意义的。有一个例外：系统初始版本的 MVA 必须有一个起点，而开发团队用于初始 MVA 的假设可能会导致对初始版本的一些过度投资。一旦反馈循环发挥作用，这种情况就会自行纠正。

就像登山者探索无人攀登的山峰一样，MVP 可能会根据反馈改变他们的路线。两名登山者可以串联移动，但这不是最好的解决方案；你将在构建 MVP 过程中学到一些东西，这些知识能帮你做出构建 MVA 的决策（也包括是不是要放弃 MVA 这样的决策，就像是登山者放弃攀登计划）。

下面是我们之前文章中提到的一些宽泛建议：

• “如果做出（或不做出）一项决定会影响产品的可行性和可持续性，或者如果改变这一决定在金钱或时间方面有着高昂的代价，以至于这样做会让产品不够经济、不切实际或不可能实现，那么该决定必须成为 MVA 的一部分。”
• “透明的架构决策有助于组织更好地理解他们为什么做出某些选择，这样他们就能做出更好的决策，来让产品适应不断变化的市场条件和客户需求。

图 2：MVP 和 MVA 必须保持紧密联系，从而避免两者膨胀和不可行

当你知道了你的 MVP 是有价值且有用的之后，MVA 的评估结果就会告诉你这个 MVP 是否是可行的，或者它是否只是对其用户的空洞承诺。除非 MVA 是可行的，否则长远来看 MVP 将无法提供有价值的成果。回到“攀登者”的比喻，就算 MVP 成功了，它也可能为它的失败播下种子，因为它经常会产生大量技术债务，如果产品要在市场上一直保持竞争力，就需要尽快偿还这些债务。

开发团队遵循严格的“完成定义”可以防止部分技术债务的积累。一旦开发团队确信 MVP 是有价值的，就需要立即解决大部分由这个 MVP 引入的技术债务。就像“登山者”的比喻，两个登山者之间的绳子长度代表了开发团队在保持产品可行性的同时愿意承担的技术债务量。

响应 MVP 的变化

有时，交付 MVP 后获得的反馈并不是组织所希望的。发生这种情况时，开发团队必须大幅修改 MVP 以响应反馈。有时，这意味着或多或少地重新开始，并创建一个新的 MVP，或者如果业务概念被证明没有足够的价值，团队甚至要完全停止工作。

当 MVP 发生显著变化时，开发团队应该重新评估对应的 MVA，即使它在过去被证明是有用的也是如此。也许并不是所有这些功能都是用户需要的，也许用户哪个都不需要，也许他们需要一些新的、不同的东西。保留旧的 MVA 或从其他应用程序借用的 MVA 有点像在一条已经建成的道路上旅行：只有当它带你去往你想去的地方时，它才有价值。

当一个组织发现一个 MVP 有缺陷并且需要重新考虑问题时，它也需要重新评估其对应的 MVA，即使他们已经投入了大量资金也是如此。就算 MVP 的一部分被证明是可行的也一样。因为这里的 MVA 可能主要是为了支持这个 MVP 中一些没用的部分而构建的。重大的目标或愿景变化也需要组织重新考虑 MVA，我们要自问“它还是最小的吗”，或者“它仍然可行吗？”和“我们怎么知道答案？”

总 结

开发团队及其组织很难将产品版本瘦身到最小程度，因为他们认为，如果能将更多功能融入其中，这个版本将更有价值。它可能会更有价值，但开发进度也会被延迟。由于了解版本是否有价值的唯一方法是发布它并衡量结果，因此如果团队添加进来的功能没有价值，那么为了添加更多功能而延迟发布就可能会降低版本的价值。因此，我们希望将增量 MVP 限制为单个用户 / 客户组的单个成果范围上。

将 MVA 与其对应的 MVP 放在一起考虑也很重要。如果这个 MVP 没有价值，那么对应的 MVA 也没有价值。MVA 需要支持 MVP 的长期生存能力，但前提是该 MVP 有价值。MVA 必须预测 MVP 的未来演变，但它还不需要立刻解决这些未来的问题。而且甚至不必在 MVP 发布时就解决这些问题。

MVP 和 MVA 是相互关联的，两者之间往往存在滞后，以避免 MVP 达不到目标时，之前对 MVA 的投资过了头。但 MVA 也不能落后太远，不然长远来看 MVP 可能就支撑不住了。此外，系统初始版本的 MVA 必须有一个起点，开发团队用于初始 MVA 的假设可能会导致一些过度投资。一旦反馈循环发挥作用，这种情况就会自行纠正。

作者介绍

Pierre Pureur 是一位经验丰富的软件架构师，拥有丰富的创新和应用程序开发背景、对金融服务行业的广泛了解、广泛的咨询经验和全面的技术基础设施知识。他过去的角色包括担任一家大型金融服务公司的首席企业架构师、领导大型架构团队、管理大规模并发应用程序开发项目、指导创新计划以及制定战略和业务计划。他是《持续架构实践：敏捷和 DevOps 时代的可扩展软件架构》（2021 年）和《持续架构：敏捷和以云为中心的世界中的可持续架构》（2015 年）等书的合著者，并发表了多篇文章并在多个有关该主题的软件架构会议上发表了演讲。

Kurt Bittner 在以反馈驱动的短周期交付工作软件方面拥有 30 多年的经验。他帮助各种组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售组织以及大型政府机构。他曾就职于大型软件交付组织，包括 Oracle、HP、IBM 和 Microsoft，并且是 Forrester Research 的前技术行业分析师。他的重点是帮助组织建立强大的、自组织的、高性能的团队，提供客户喜爱的解决方案。他是四本有关软件开发相关主题的书籍的作者，其中包括 The Nexus Framework for Scaling Scrum。他居住在科罗拉多州博尔德，担任 Scrum.org 企业解决方案副总裁。

原文链接：

How Much Architecture Is “Enough?”: Balancing the MVP and MVA Helps You Make Better Decisions(https://www.infoq.com/articles/mva-enough-architecture/)

声明：本文为 InfoQ 翻译，未经许可禁止转载。