与现代敏捷方法相结合，产品必须能够根据反馈和需求变化进行增量迭代。 但与许多原型不同的是，MVP 并不是一个一次性的概念。 这就是最小可行架构（MVA）发挥重要作用的地方，帮助产品开发团队更有效地评估技术可行性。
“最小可行产品”（MVP）的概念可以帮助团队专注于快速有效地交付他们认为对客户最有价值的产品，这样他们就可以在投入大量时间和成本之前以最低的成本快速评估产品资源。 市场规模。 简单来说，MVP就是：
“一个产品版本，只为早期客户提供足够的功能供他们使用，并为未来的产品开发提供反馈。 专注于发布 MVP 意味着开发人员可以避免冗长且（最终）不必要的工作。 相反，他们专注于迭代 MVP 版本并响应反馈，以及挑战和验证有关产品需求的假设。”
MVP 的概念不仅仅适用于初创公司。 每个应用程序都有一个可以被视为 MVP 的初始版本。 几乎每个组织都有这样的故事：他们如何花费数月或数年开发新系统，然后部署它，却发现它不能满足用户的需求。 尽早发布 MVP 有助于避免在错误的需求上投入大量时间、金钱和精力。
为了更好地理解MVP的目标，我们首先需要考虑什么是“可行”。 MVP 必须证明它可以为足够多的人提供足够数量的价值，从而在经济上可行。 简而言之，它必须有足够多的人购买才能提供良好的投资回报。 换句话说，你有一个足够大的问题，涉及足够多的人，所以解决它是值得的。 但经济可行性还有另一个方面：成本。 成本必须是可以承受的，其总生命周期成本必须在产品的预期利润范围内。
1 什么是最小可行架构（MVA）？
当人们使用术语“最小可行架构”（MVA）时，他们通常指以下之一：
包含最少组件集的设计。 当团队的主要关注点是尽快实现 MVP 时，MVA 通常主要受功能需求而不是质量属性需求 (QAR) 的影响，因为后者可能没有被很好地理解和定义。 他们的设计决策往往更加实际和实用，因为速度是他们的主要关注点。 他们通常认为，如果MVP继续迭代，MVA需要重新设计并最终演变成成熟的产品。 产品的可持续性不是优先考虑的事项。 组成MVA的组件可以来自商业云供应商提供的现成产品、低代码或无代码产品，或者在现有系统的基础上进行一些微小的改变。
这种方法的缺陷是认为“解决方案的架构对客户来说并不重要”。 但客户确实关心解决方案的可持续性，架构对他们来说很重要。 这种方法可能涉及对初始设计的大量重构，导致时间和精力的浪费，并且可能产生大量的技术债务。 在架构之前优先考虑交付速度可能是正确的做法，特别是在团队无法提供有效的反馈循环的情况下。 然而，团队应该愿意接受这样一种可能性，即他们交付的大部分内容可能需要稍后进行大量返工。
开发团队为解决方案做出的架构决策。 该定义侧重于 MVP 的可持续性和长期生存能力，考虑产品如何满足功能需求，同时最大限度地减少技术债务。 软件架构由 QAR 驱动，而不是功能需求。 该 MVA 由一组最小的技术相关决策组成，这些决策通过经验进行验证并随着时间的推移而演变。 此外，还有一些额外的架构构建实践，可以帮助团队在开发产品时保持产品的架构可行性。
2 MVA 的关键决策要素
“什么才是关键？”这个问题的答案取决于是否必须为产品的可行性做出架构决策。 如果做出（或不做出）决策会影响产品的可行性和可持续性，或者改变决策会花费大量金钱或时间，导致产品不经济、不切实际或不可能，则存在此要素。 必须作为构建 MVA 过程中的关键决策点之一。
这些决策包括产品如何处理与产品/系统特征相关的 QAR，例如：
以上并不是完整的列表，开发团队可能需要根据自己的QAR来添加或删除这个列表的内容。
3. 开发团队如何迭代产品的MVA？
与最终被丢弃的原型不同，开发团队会将初始 MVA 作为 MVP 的一部分，因为它是产品的第一个版本。 通过一系列敏捷方法（例如Scrum中的冲刺）进行迭代 与MVP一样，MVA也需要迭代。 无论何时，产品都应该满足已知的QAR，以免基于猜测和假设给产品带来负担，并通过随后纳入新的QAR或需求，以可持续的方式实现业务功能的持续交付。
我们可以在概念层面上描述这种方法：
简而言之，随着团队更多地了解产品的需求，他们只构建最小可行的产品，只做出满足已知需求绝对必要的架构决策。 产品仍然是MVP，架构仍然是支持MVP的MVA。 原因很简单：团队可能花费大量时间和精力来实现产品功能和 QAR，却发现客户并不欣赏它们的价值。 相信什么是有价值的只是一种假设，直到得到客户的验证，这才是假设和实验发挥作用的地方。
所谓假说，就是对某些尚未被证实（或否定）的观察结果提出一种解释。 在需求方面，人们相信做一件事会导致另一件事发生，例如，提供功能 X 将导致结果 Y。实验用于证明或反驳某些假设。
每个功能和需求（包括 QAR）实际上都代表了关于价值的假设。 经验主义的目标之一是使这些假设变得明确，并有意设计实验来明确测试功能和需求的价值。 团队实际上并不需要构建完整的功能或需求来确定它是否有价值； 他们只是构建一个最小可行的产品和架构，足以验证证明其价值的关键假设。
通过 MVA，团队将在每次迭代 () 中验证他们对解决方案的假设，根据经验进行测试，然后根据他们学到的知识做出决策。 例如，Scrum 团队会通过对产品需求项目进行排名来决定他们需要了解什么。 产品需求项目包括功能需求（例如功能和用户故事）和 QAR。
当团队规划项目时，它会选择许多产品需求作为目标。 这不仅是对产品能够为客户提供价值的假设，也是对增量产品如何随着时间的推移不断迭代的假设。 因此，产品需求项目（包括 QAR）的排序将迫使团队专注于关于价值的假设以及产品如何可持续地交付该价值。
4。结论
MVP 不仅需要考虑产品的市场可行性，还需要考虑其技术可行性，以满足随着时间的推移不断变化的需求。 MVP 不仅限于初创公司，因为每个应用程序都有一个可以被视为 MVP 的初始版本。 MVP 是产品开发策略的一个有用组成部分。 使用MVA作为MVP的一部分，可以帮助团队评估技术可行性，并为产品提供稳定的基础，可以随着产品的演进进行迭代调整。 架构决策的透明度有助于组织更好地理解为什么做出某些选择，这有助于他们就如何使产品适应不断变化的市场条件和客户需求做出更好的决策。
关于作者：
Kurt 在短周期交付软件方面拥有 30 多年的经验。 他帮助许多组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售企业以及大型政府机构。 曾就职于甲骨文、惠普、IBM、微软等大型软件交付企业，并担任该公司技术行业分析师。 他的重点领域是帮助组织建立强大的、自组织的、高绩效的团队，为客户提供流行的解决方案。 他撰写了 4 本与软件开发相关的书籍，其中包括《The Nexus for Scrum》。 他目前住在科罗拉多州博尔德，担任企业解决方案副总裁。
是一位经验丰富的软件架构师，拥有强大的创新和应用程序开发背景、丰富的金融服务行业经验、丰富的咨询经验和全面的技术基础设施知识。 他曾担任一家大型金融服务公司的首席企业架构师，领导大型架构团队、管理大型并发应用程序开发项目、指导创新计划以及制定战略和业务计划。 他是《：in the Age of and》（2024 年）和《：in an Agile and Cloud-World》（2015 年）的合著者，发表了大量文章并在多个软件架构会议上发表演讲。 演讲。
原文链接：创新工具| 如何构建产品的最小可行架构（MVA）