最小可行产品与最小可行架构

“最小可行产品”（MVP）的概念可以帮助团队专注于尽早交付他们认为对客户最有价值的产品，这样他们就可以在投入大量时间和资源之前用最低的成本快速地评估产品的市场规模。简单地说，MVP 就是：

“产品的一个版本，只为早期的客户提供足够他们使用的功能，让他们为未来的产品开发提供反馈。专注于发布 MVP 意味着开发者可以避免冗长和(最终)不必要的工作。相反，他们专注于迭代 MVP 版本并对反馈做出回应，以及挑战和验证有关产品需求的假设。”

MVP 的概念不仅适用于创业公司。每个应用程序都有一个可以被认为是 MVP 的初始版本。几乎每个组织都有这样的故事：他们如何花费数月或数年时间开发一个新系统，然后部署它，却发现它不能满足用户的需求。尽早发布 MVP 有助于避免在错误的需求上投入大量的时间、金钱和精力。

为了更好地理解 MVP 的目标，需要先考虑“可行”的含义。MVP 必须证明它能够以足够的数量为足够多的人提供价值，从而具备经济可行性。简而言之，它必须是有足够多的人去购买的东西，从而提供良好的投资回报。换句话说，你有一个足够大的问题，涉及足够多的人，而且解决这个问题是值得的。但经济可行性还有另一个方面：成本。成本必须是可负担的，而且它总的生命周期成本必须在产品期望的利润范围内。

结合使用现代的敏捷方法，产品必须能够根据反馈和需求的变化逐步演化。与原型不同，MVP 不会被“扔掉”。这里就是最小可行架构发挥重要作用的地方。

什么是最小可行架构？

当人们使用术语“最小可行架构”(MVA)时，他们通常指的是以下其中之一：

• 一种包含最小组件集的设计。当团队主要关注于尽可能快实现 MVP 时，他们的 MVA 往往主要受功能需求而不是质量属性需求（QAR）的影响，因为后者可能还没有得到很好的理解。他们的设计决策往往是战术性的，因为速度是他们的主要关注点。他们通常认为如果 MVP 被证明是成功的，MVA 就需要重新设计，并最终演变成一个成熟的产品。产品的可持续性并不是优先考虑的问题。构成 MVA 的组件可以来自商业云供应商提供的现成产品、低码或无码产品，或在现有的系统基础上做一些细小的变更。

这种方法的缺陷在于人们认为“解决方案的架构对客户不重要”。但客户确实关心解决方案的可持续性，可见架构对他们来说很重要。正如我们在前一篇文章中指出的，这种方法可能涉及对初始设计的重大重构，导致时间和精力的浪费，并可能产生重大的技术债务。将交付速度置于架构关注点之前（这本身就是一个应该文档化的架构决策）可能是正确的做法，特别是当团队无法提供有效的反馈循环时。但是，团队应该愿意接受这样的可能性，即他们交付的大部分东西在以后可能需要进行大量的返工。

• 开发团队对解决方案所做的一小部分基本决策。这个定义关注的是 MVP 的可持续性和长期可行性，考虑产品如何在满足功能需求的同时最大限度地减少技术债务。正如我们在另一篇文章中指出的，软件架构是由 QAR 驱动的，而不是由功能需求驱动的。这种 MVA 由一组最小的技术决策组成，随着时间的推移，这些决策将通过经验来验证，并不断演变。此外，还有一些额外的实践帮助团队在开发产品时保持产品的架构可行性。

什么样的决策塑造了 MVA？

“怎样才算足够”这个问题的答案取决于是否必须为了产品的可行性而做出架构决策。如果做（或不做）出一个决策会影响产品的可行性和可持续性，或者如果改变决定需要付出高昂的金钱或时间成本，导致产品不经济、不切实际或不可能，那么这个决定必须作为 MVA 的一部分。

这些决策包括产品将如何处理与产品/系统特征相关的 QAR，例如：

• 并发性——并发用户、传感器和其他设备的数量，产品必须对这些事件做出响应。

• 吞吐量——产品在给定的时间段内必须处理的事务或数据量。

• 延迟和响应性——产品对事件做出响应的速度。

• 可伸缩性——系统通过增加成本来处理增加的工作负载的能力，一般呈近似线性的关系。

• 持久性——产品必须存储和检索的数据的吞吐量和结构。通常涉及不同类型的数据存储技术的选型（例如 SQL DBMS, NoSQL DBMS 等）。

• 安全性——产品如何通过实现保密性、完整性和可用性来保护自身免受未经授权的数据访问。

• 监控——对产品进行增强，让产品支持人员能够了解产品何时无法满足 QAR 并防止出现关键的系统问题。

• 平台——产品如何满足与系统资源约束（如内存、存储、事件信号等）相关的 QAR。例如，实时和嵌入式产品（如电子表或自动制动系统）与基于云的信息系统有着截然不同的约束。

• 用户界面——产品为用户提供的交互方式。例如，虚拟现实界面与二维图形用户界面有完全不同的 QAR，而二维图形用户界面与命令行界面也有完全不同的 QAR。这些决策可能会影响上述的其他 QAR（GUI、VR、命令行或其他类型的界面）。

这并不是一个完整的清单，开发团队可能需要根据自己的 QAR 对这个清单的内容进行增减。

开发团队如何演化产品的 MVA

与最终被丢弃的原型不同，开发团队会将最初的 MVA 作为 MVP 的一部分，因为它是产品的第一个版本。就像他们通过一系列敏捷迭代（或 Scrum 的 Sprint）MVP 一样，他们也迭代 MVA。在任何时候，他们的产品都应该满足已知的 QAR，这样就不会基于猜测和假设的特性给产品增加负担，有助于我们以一种可持续的方式实现业务功能的持续交付。

我们可以从概念层面来描述这种方法：

• 团队最初只提供可以满足已知 QAR 的架构，快速构建出可供真正客户使用的可行产品。

• 然后，随着团队更多地了解客户的真正需求，他们不断地改进产品以满足额外的需求或需求变更（包括 QAR）。保持架构的灵活性是必要的，应用持续架构原则之一——“延迟设计决策，直到绝对有必要”——是实现这个目标的有效方法。

简而言之，随着团队对产品需求的了解越来越多，他们只构建足够的产品，只做出满足已知需求的绝对必要的架构决策。产品仍然是 MVP，架构仍然是支持 MVP 的 MVA。这么做的原因很简单：团队可能会花费大量的时间和精力实现产品的特性和 QAR，结果却发现客户并不认同他们的价值。相信什么是有价值的仅仅是一种假设，直到得到客户的验证，而这才是假设和实验发挥作用的地方。

所谓的假设，就是对某些尚未被证实（或被否定）的观察结果提出解释。从需求方面讲，它是一种信念，认为做了一件事将导致另一件事的发生，例如交付特性 X 将导致结果 Y。实验是用来证明或否定某些假设的。

每一个特性和需求（包括 QAR）实际上都代表了一个关于价值的假设。实证的目标之一是让这些假设变得明确，并有意识地设计实验对特性和需求的价值进行明确的测试。实际上团队不需要构建出整个特性或需求来确定它是否有价值，他们只需要简单地构建足够多的代码，就足以对能够证明其价值与否的关键假设进行验证。

对于 MVA，团队将在每次迭代（Sprint）中验证他们关于解决方案的假设，根据经验对其进行测试，然后根据了解到的东西做出决策。例如，Scrum 团队会通过对产品需求项进行排序来决定他们需要了解什么。产品需求项包括功能需求（比如特性和故事）和 QAR。

当团队在计划一个 Sprint 时，他们选取一些产品需求项作为 Sprint 的目标，这不仅是对产品能够为客户提供的价值的假设，也是对增量产品如何随着时间推移而持续演化的假设。产品需求项（包括 QAR）的顺序将因此迫使团队面对他们关于价值和产品如何可持续交付价值的假设。

结论

MVP 不仅需要考虑产品的市场可行性，还需要考虑其技术可行性，以便随着时间的推移满足不断变化的需求。MVP 并不局限于初创公司，因为每个应用程序都有一个可以被认为是 MVP 的初始版本。MVP 是产品开发策略的一个有用的组成部分。将 MVA 作为 MVP 的一部分可以帮助团队评估技术可行性，并为产品提供一个稳定的基础，可以随着产品的演化进行调整。架构决策透明化有助于组织更好地理解为什么做出某些选择，这有助于他们更好地做出关于如何使产品适应不断变化的市场条件和客户需求的决策。

作者简介：

Kurt Bittner 拥有超过 30 年短周期交付软件的经验。他帮助过许多采用敏捷软件交付实践的组织，包括大型银行、保险、制造和零售企业，以及大型政府机构。他曾为大型软件交付企业工作，包括甲骨文、惠普、IBM 和微软，并曾是 Forrester Research 公司的技术行业分析师。他的重点领域是帮助组织建立强大、自组织、高性能的团队，为客户交付受欢迎的解决方案。他撰写了 4 本与软件开发相关的书，包括“The Nexus Framework for Scaling Scrum”。他现居科罗拉多州博尔德市，并担任 Scrum.org 的企业解决方案副总裁。

Pierre Pureur 是一位经验丰富的软件架构师，拥有丰富的创新和应用程序开发背景、广泛的金融服务行业经验、广泛的咨询经验和全面的技术基础设施知识。他曾担任一家大型金融服务公司的首席企业架构师，领导大型架构团队，管理大型并发应用程序开发项目，指导创新计划，以及制定战略和业务计划。他是“Continuous Architecture in Practice: Scalable Software Architecture in the Age of Agility and DevOps”（2021 出版）和“Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World”（2015 出版）的合著者，并发表了许多文章，以及在多个软件架构会议上发表相关演讲。

原文链接：

A Minimum Viable Product Needs a Minimum Viable Architecture