前言
- 最小可行产品（MVP）的概念可以帮助团队专注于尽快交付他们认为对客户最有价值的东西，以便在投入大量时间和资源之前迅速、廉价地评估产品的市场规模。
- MVP不仅需要考虑产品的市场可行性，还需要考虑其技术可行性，以便随着时间的推移进行维护和适应不断变化的需求。
- MVP不仅适用于初创公司，因为每个应用程序都有一个初始发布版本，可以被视为MVP。MVP是产品开发策略的一个有用组成部分。与简单的原型不同，MVP并不打算“扔掉”。
- 在MVP的一部分创建最小可行架构（MVA）有助于团队评估技术可行性，并为产品提供一个稳定的基础，可以随着产品的演进而进行调整。
- 如果做出（或不做出）决定会影响产品的可行性和可持续性，或者改变决定会在金钱或时间方面付出如此巨大的代价，以至于这样做会使产品经济不可行、不切实际或不可能，那么这个决定必须作为MVA的一部分做出。
- 使架构决策透明化有助于组织更好地理解为什么做出了某些选择，从而帮助他们更好地决定如何将产品适应变化的市场条件和不断发展的客户需求。
最小可行产品的概念可以帮助团队专注于尽早交付对客户最有价值的内容，以便他们可以在投入大量时间和资源之前快速、廉价地评估产品在市场上的规模，避免投入大量资源到可能不成功的项目中。简而言之，MVP是：
“产品的一个版本，具有足够的功能，可以被早期客户使用，并提供反馈以供未来产品开发。专注于发布MVP意味着开发人员可能避免进行冗长且（最终）不必要的工作。相反，他们会对可用版本进行迭代，并对产品需求的假设进行挑战和验证。”
然而，MVP的概念不仅限于创业公司的背景。每个应用程序都有一个可以视为MVP的初始发布版本。几乎每个组织都有这样的故事：他们花了数月甚至数年的时间开发新系统，然后部署它，却发现它并不符合用户的需求。提早发布MVP有助于防止将大量时间、金钱和精力投入到错误的需求中。
为了更好地理解MVP的目标，考虑一下“可行”的含义。MVP必须证明它以足够数量的价值为足够数量的人提供服务，以使其在经济上可行。简而言之，它必须是足够多的人愿意购买，以便提供良好的投资回报。
换句话说，您有一个足够大的问题，以及足够多的人需要解决这个问题。但是经济可行性还有另一个方面：成本。该产品既必须价格合理，又必须在所需利润率范围内定义的总生命周期成本之内。
并且使用现代敏捷方法，产品必须能够根据反馈和随时间变化的需求进行增量演进；与简单的原型不同，MVP不打算被“扔掉”。这就是最小可行架构发挥重要作用的地方。
什么是最小可行架构
当人们使用“最小可行架构”（MVA）这个术语时，他们通常指的是以下之一：
- 一个涉及最少组件的设计。当团队主要专注于尽快实现MVP时，他们的MVA往往受其功能性要求的影响，而不是其可能尚未完全了解的质量属性要求（QARs）。他们的设计决策往往是战术性的，因为速度是他们的主要关注点，他们通常期望MVA在MVP被证明成功并最终演变成一个完整的产品时需要进行重新设计。产品的可持续性不是优先考虑的问题。用于组装MVA的组件可能来自商业云供应商提供的现成产品、低代码或无代码产品，或者是从现有系统中进行最小修改后重新使用的。
这种对MVA的方法的缺陷在于认为“解决方案的架构对客户并不重要”。但客户确实关心解决方案的可持续性，这使得架构对他们而言变得重要。正如我们在之前的一篇文章中你为什么需要关心软件架构指出的，这种方法可能涉及对初始设计的重大重构，导致时间和精力的浪费，并可能产生重大的技术债务。
将交付速度置于架构问题之前（这本身就是一个应该记录的架构决策）可能是正确的做法，尤其是如果团队当前的周期时间过长，无法提供有效的反馈循环。但团队应该愿意接受这样的可能性，即他们所交付的大部分内容可能在以后需要进行重大的重做。
- 这个定义将注意力集中在可持续性上，即MVP的长期可行性，考虑了产品如何在满足其功能性要求的同时满足其QARs，并尽量减少技术债务以实现可持续性。正如我们在另一篇文章中指出的那样，软件架构是由QARs驱动的，而不是由功能性要求驱动的。在这种方法中，MVA由一组经过时间检验和发展的最小化技术决策组成。这些决策通过一组最少的架构实践来补充，帮助团队在演化过程中保持产品的架构可行性。
什么样的决策塑造了MVA
回答“什么是刚刚好”的问题取决于是否需要做出架构决策才能使产品可行。如果做出（或不做出）决策会影响产品的可行性和可持续性，或者如果更改决策在时间或金钱上的成本如此之高，以至于这样做会使产品不经济、不切实际或不可能，那么这个决策必须成为MVA的一部分。
这些决策涉及产品/系统特性相关的QARs的处理方式，包括：
- 并发性——与同时在线用户、传感器以及其他设备同时产生事件的数量相关。
- 吞吐量——与产品必须在定义的时间段内处理的交易量或数据量相关。
- 延迟和响应速度——与产品对事件作出响应的速度相关。
- 可伸缩性——与系统通过增加成本来处理增加的工作负载的能力相关，通常呈近线性关系。
- 持久性——与产品必须存储和检索的数据的吞吐量和结构（或缺乏结构）相关。通常包括关于不同种类数据存储技术的决策（例如SQL数据库管理系统、NoSQL数据库管理系统等）。
- 安全性——与产品如何保护自身免受未经授权的使用或对产品数据的访问相关，以实现机密性、完整性和可用性。
- 监控——与产品将如何被实时监测相关，以便支持产品的人员了解当产品开始无法满足QARs并防止严重系统问题时的情况。
- 平台——与产品将如何满足与内存、存储、事件信号等系统资源约束相关的QARs相关。例如，实时和嵌入式产品（如数字手表或自动制动系统）与基于云的信息系统具有完全不同的约束。
- 用户界面——与产品如何与用户进行交互的决策相关；例如，虚拟现实界面与二维图形用户界面具有完全不同的QARs，而命令行界面则与二者都有不同的QARs。这些决策可能会影响上述其他QARs。（GUI、VR、命令行或其他类型的界面。）
这个列表并不详尽，开发团队可能需要根据他们自己的QARs添加或删除其中的项目。
开发团队如何发展他们产品的MVA
与一次性原型不同，开发团队在构建MVP的过程中同时构建他们的初始MVA，这是产品的第一个发布版本。采用敏捷方法，就像他们通过一系列迭代（或Scrum中的Sprint）演进MVP一样，他们也演进MVA。在任何时间点，他们的产品都应该满足已知的、客观的QARs。通过这样做，他们不会基于猜测和假设给产品增加不必要的功能，这有助于我们以可持续的方式持续交付业务能力。
在概念上，这种方法可以描述如下：
- 团队最初开发了足够的架构，恰好满足了软件系统的已知QARs，以便快速创建一个足够可行的产品，供真实客户使用。
- 然后，团队持续演进产品，以满足更多的需求或需求变化（包括QARs），随着他们对客户真正需要的了解越来越多。保持架构的灵活性至关重要，应用连续架构原则，特别是第3原则，“延迟设计决策直到绝对必要”，是实现这一目标的有效方法。
简而言之，随着团队对产品需求的了解越来越多，他们只会构建足够多的产品，并作出尽可能少的架构决策，以满足他们现在所知道的需求；产品继续是一个MVP，而架构继续支持MVP。这两种行为的原因很简单：团队可能会花费大量时间和精力在产品中实施功能和QARs，结果发现客户不认同它们的价值观；关于价值的信念只是假设，直到被客户验证。这就是假设和实验有用的地方。
简化来说，假设是对尚未被证明（或证明无效）的某种观察结果提出的解释。在需求的背景下，它是一种信念，即做某事会导致其他事情发生，例如交付X功能将导致Y结果。实验是旨在证明或拒绝某种假设的测试。
每个功能和每个需求（包括QARs）实际上都代表了关于价值的假设。经验主义方法的一个目标是使这些假设变得明确，并有意识地设计实验，明确测试功能和需求的价值。实际上并不需要构建整个功能或需求来确定其是否有价值；对于团队来说，构建它的足够部分以验证可能证明或否定其价值的关键假设可能是足够的。
在MVA的背景下，团队将在每个迭代（Sprint）中通过经验主义地测试来验证他们对解决方案的假设，并根据所学到的知识做出决策。例如，在Scrum的背景下，Scrum团队将考虑他们需要通过对产品积压清单中的项目进行排序来了解的内容；产品积压清单本身将包含功能性需求（如功能和用户故事）以及QARs。
当团队计划一个Sprint时，他们从产品积压清单中拉取项目以满足Sprint的目标，这将反映出不仅关于产品提供给客户的价值的假设，还包括关于产品增量如何在随着时间的推移而持续演变的假设。产品积压清单中项目的顺序，包括QARs，因此将迫使团队面对他们关于价值以及产品如何可持续地提供价值的假设。
总结
MVP（最小可行产品）不仅需要考虑产品的市场可行性，还需要考虑其技术可行性，以便随着时间的推移进行维护和适应不断变化的需求。MVP并不局限于初创企业的背景，因为每个应用程序都有一个可以视为MVP的初始发布版本，它们可以成为产品开发战略的有用组成部分。将MVA（最小可行架构）作为MVP的一部分创建有助于团队评估技术可行性，并为产品提供一个稳固的基础，可以随着产品的发展而进行调整。公开透明的架构决策有助于组织更好地理解为何会做出某些选择，从而帮助他们更好地决定如何使产品适应不断变化的市场条件和不断发展的客户需求。