敢不敢尝试：MVA 困境

• 技术雷达是一种常用的描述技术采用风险的方法。

• 技术雷达可以帮助团队针对他们正在构建的解决方案及其架构进行实验。

• 每个产品发布都是或应该是关于团队提供的价值及解决方案的可持续性的实验。

• 这些实验必须以业务的利益相关者能够理解和支持的方式来平衡业务和技术风险。

• 发布的版本应着眼于学习最多的经验，而不是特性的数量或交付的技术深度，但如果新版本的实验规模过大或次数过多，就会变得“大到不能倒”，不再是实验了。

开发一个产品的新增量（也称为最小可行产品，MVP）的团队往往面临着艰难的处境：他们必须在很短的时间内开发和交付他们希望其能有价值的产品增量。他们还需要为这个 MVP 开发一个最小可行架构（MVA），以满足其质量目标——也称为质量属性要求（QAR）。

这两种力量之间的这种紧张关系造成了一个两难境地：团队是依赖久经考验但可能无法完全满足其需求的技术，还是探索可能更适合，但实施起来风险更大的新的和陌生的技术？团队及其组织如果一直坚持使用久经考验的技术，往往会在短期内将风险降至最低，但从长远来看，继续使用不再适合应对组织所面临挑战的那些旧技术会增加风险。

技术雷达（TR）是组织汇总和交流其在使用各种技术时所获得的经验的一种方式，如图 1 所示。

图 1：Thoughtworks 的一个技术雷达示例

在这个流行的表示中，技术雷达在一个圆圈的象限中显示了四个不同的技术领域，当然这里的技术领域可以多放一些，也能少放一些。在这个圆圈内，根据编制者的经验，需要建议团队是否应该：

• 采用 该技术，因为它已被无可争议地证明具有普遍用途；

• 试用 该技术，因为尽管一些团队已经成功使用了该技术，但每个团队都需要根据自己的情况做出自己的决定；

• 评估 该技术，因为虽然该技术看起来很有趣，但它还没有得到广泛的应用，不足以值得推荐；

• 暂停 使用该技术，因为该技术领域有更好的解决方案。这个环中的产品可能曾经被推荐采用过，但它们被推荐使用的机会可能已经减少了。

组织对风险的亲和力也会影响技术决策，如图 2 所示。

图 2：技术采用因团队技能和风险承受能力而异

这张表使用 Everett Rogers 的创新扩散模型将技术成熟度映射到了组织风险承受能力上。从这个角度来看，如果你的团队认为在构建某个 MVA 时使用某种特定技术会很有用，你需要问自己“我们的组织是否符合该技术采用者的形象？”例如，如果你想使用自动机器学习（AutoML）技术，那么你的组织是否真的符合“创新者”形象？你的组织能否吸引精通该技术的人才？当这些实验可能没有回报时，你的组织是否依旧愿意进行实验？

在上一篇文章中，我们谈到了每次产品发布都是一个增量式最小可行产品（MVP），它有着对应的最小可行架构（MVA），可确保 MVP 的价值能够长期维持。在这个模型中，每个 MVP 都是一个探索那些客户认为有价值的东西的实验，每个 MVA 都是一个关于如何可持续地支持该价值的实验。

这些实验为团队提供了尝试新技术的机会；为了实现发布的目标，团队可能必须使用一些新技术。他们面临的挑战是平衡技术实验和业务实验。业务利益相关者不会接受仅由技术实验组成的产品版本，如果技术实验失败，他们也可能会担心新版本将业务实验置于风险之中。团队必须协商解决这一问题。

但是……技术实验可能是实现业务实验所必需的。有时业务实验可能会失败并拖累技术实验，但如果技术实验不能满足迫切的业务需求，它也永远不会成功。

无论如何，如果团队想要在发布版本中加入技术实验，就需要与业务和运营利益相关者进行富有挑战性的讨论。业务利益相关者必须以他们熟悉的方式了解技术实验的好处，了解该技术如何更好地满足客户需求。

运营利益相关者需要确信该技术是稳定且可支持的，或者至少稳定性和可支持性是用于评估该技术的一部分标准。

完全避免技术实验通常是一件坏事，因为它可能会错过以更好的方式解决业务问题的机会，从而导致解决方案的效果不如其他方法。随着时间的推移，这可能会增加技术债务。

正如我们在最近的一篇文章中所写，承担技术债务（TD）是一种学习事物的方式，可以让你避免对那些你可能尚未完全理解的问题的解决方案做过度投资。在引入新的、不熟悉的技术作为 MVA 的一部分时，有意承担 TD 可能不是一件坏事。假设新技术成功满足了团队的需求，使 MVA 达到或超过其 QAR；这也可能适用于试图解决类似问题的其他团队，因此增加的 TD 可能不需要“偿还”。

但如果新技术未能兑现承诺，无法满足团队的需求，则应迅速终止实验，从而消除 TD 问题。这里的危险在于，你也许会假设在新技术上花费更多时间和精力可能会扭转局面。一旦确定 MVA 无法满足其 QAR，就应立即终止实验，无需在实验上花费更多时间和精力。小心落入“确认偏见”陷阱！

此外，如果实验规模太大而不能失败，或者实验失败会被视为坏事，那么它就不是实验。只有在实验没有提供任何有用信息的情况下，它才会是失败的；你要记住，一项技术，甚至一项特性就算没有提供预期的结果也并不是失败，你只是获得了相关信息而已。

团队在这方面犯的一个错误是，在不知道技术是否会产生预期结果的情况下，投入过多精力实施新技术。当他们不确定时，他们应该将发布分解为一些较小的版本，以便更快交付，从而获得反馈。

同样，开发团队及其业务利益相关者都应避免对价值做出假设，而是将复杂而昂贵的解决方案分解为一些较小的部分，这样他们就能更快、更轻松地进行评估。换句话说，如果“实验”太大而不能失败，那么他们需要将其分解为一些较小的实验。

团队及其利益相关者首先必须就 MVP/ 新版本发布的业务范围达成至少是初步的协议。达成协议后，开发团队必须做出预测，判断他们需要做多少工作才能实现发布目标。这里他们就必须开始做出技术选择了，因为不同的技术会改变团队需要做的工作量和性质。

使用图 1 所示的技术雷达，团队将首先调查“采用”类别中列出的技术，并评估这些技术是否有某些选项可以帮助他们实现发布目标。如果他们只需要使用“采用”类别中的技术，他们的工作通常会更简单，风险更小。不过，这些更“成熟”的技术并不总是能完成团队需要做的所有事情，因此他们可能需要考虑“试用”类别中的技术，等等。

在做出这些决策时，团队会权衡各种技术风险，如图 3 所示。

图 3：团队权衡多种技术风险

这些权衡受到两个简单事实的制约：开发团队没有太多时间获取和掌握新技术，且他们不能因为采用未经证实或不可持续的技术而将新版本的业务目标置于风险之中。这通常会导致团队坚持使用久经考验的技术，但这种策略也存在风险，最明显的是锤钉式风险，即团队无论如何都会使用不适合新问题的旧技术，例如使用关系数据库来存储类似图形的数据结构。

任何新版发布的第一步规划工作是就发布的目标达成一致。关于这一点，最重要的决定是就团队或组织需要多快获得实验反馈达成一致。为此，他们需要了解应运行哪些实验。他们总要平衡至少两种实验：

• 他们需要决定应进行哪些有关业务价值的实验。这些实验将成为 MVP 的重点。换句话说，业务利益相关者对“他们的客户或用户需要什么或会发现什么”有一些想法，但这些想法通常未经证实。很多时候，测试这些想法的唯一方法是构建和发布某些东西。

• 他们需要决定应做出哪些技术决策来持续支持业务价值实验，如果实验成功的话。这些决策的一部分可能涉及采用新技术。类似于图 1 和图 2 的技术雷达可以帮助他们做出决定。对于每一种候选技术，他们需要问自己

• 组织是否能接受与新技术相关的风险？

• 业务实验和相关技术实验的业务案例是否合理？组织如何知道这一点？

• 考虑到组织的专业知识和资源，技术是否可支持 / 可持续？组织如何知道这一点？

• 技术是否满足团队的需求？如何知道这一点？

对于每一种实验，团队及其利益相关者都需要就如何判断实验是否成功达成一致。此外，如上所述，如果实验规模过大或数量过多，团队及其利益相关者将需要缩小发布范围，以保持在新版本的反馈周期目标之内。

开发 MVP 的团队只有很短的时间来开发和交付他们希望有价值的产品增量，以及创建 MVA 来支持该 MVP。他们可以依赖久经考验的技术，但这些技术可能无法完全满足他们的需求，也可以探索可能更适合但会增加技术风险的新的和不熟悉的技术。技术雷达是一种描述这种风险的流行方式，可以帮助团队对他们正在构建的解决方案及其相关的 MVA 进行实验。

产品发布是对团队提供的价值以及解决方案的可持续性而做的实验。这些版本发布应着眼于尽可能学习经验，而不是特性数量或交付的技术深度。发布中体现的实验必须以业务利益相关者和开发团队可以理解和支持的方式来平衡业务和技术风险。

实验规模过大或次数过多的版本会变得“大到不能倒”，不再是实验。快速和早期的反馈非常关键，可以防止过度投资于客户或用户不想要或不需要的东西，还可以防止产品架构变得臃肿和无效，并防止依赖不可持续的技术。

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

原文链接：

To Dare or Not to Dare: the MVA Dilemma(https://www.infoq.com/articles/mva-dilemma-experiments/)

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