作者 | Kurt Bittn、Pierre Pureur
译者 | Sambodhi
策划 | 丁晓昀
多年来，我们会听到人们将他们的软件架构称为“精益和敏捷”的架构。这让我们不禁思考精益和敏捷实践究竟如何助力团队在软件产品的架构设计上取得突破？有些人将这两者混为一谈，认为精益和敏捷在很大程度上是相似的方法。但我们认为，在软件架构的语境下，精益和敏捷方法有着本质的不同，它们都有各自的优势和局限性。
精益方法的核心在于消除低效开发过程和实践所带来的浪费，缩短产品开发周期，该方法主要是在制造问题领域中发展起来的。它们主要关注产品开发的手段和方法，但也包括逐步改进产品的机制。
精益方法的前提假设是，组织已经对要构建的产品或解决的问题有了较为清晰的认识，因此其主要关注在构建已知解决方案时减少浪费。
许多管理者青睐精益方法，因为它能够显著提升开发效率、增强生产力、降低成本并增强项目的可预测性。
他们将软件开发视为一条生产线，而精益方法起源于制造业，与这种生产线式的软件开发理念高度契合。
然而，这并不是敏捷方法的重点。敏捷方法的核心目标并非单纯地追求效率、生产力、成本削减或可预测性的提升，尽管这些都有可能是实现敏捷方法主要目标的副产品：迅速验证组织是否在构建正确的产品。
为了实现这一目标，团队需要减少浪费以实现快速反馈周期，从而降低成本并提高效率，但这些只是实现不同目标的手段。
正如爱丽丝在迷茫中询问切西猫应该选择哪条路时，切西猫的回应 “如果你不知道你想去哪里，那么走哪条路都无所谓”。在软件架构的语境下，敏捷方法要回答的问题是 “产品应该去哪里？”（即产品要实现什么） ，精益方法要问的问题是 “构建产品最快最有效的方式是什么？” ，它假设团队已经明确他们需要构建的产品是什么。
对于软件架构而言，这意味着什么呢？
MVP、MVA 与经验主义
最小可行产品（MVP）作为一种经验性的方法，已广泛应用于验证团队是否走在构建正确产品的正确道路上。在一些系列文章中，我们在此基础上引入了最小可行架构（MVA）这一相关概念，作为对 MVP 概念的扩展。MVA 是开发团队对解决方案所作的一系列基础设计决策，它强调 MVP 的可持续性和长期可行性，在满足产品功能需求的同时也满足 QAR，注重产品的可持续性，并力求减少技术债务。
在 MVP 和 MVA 的实践中，客户需求以及满足这些需求所需的技术决策常常存在一定的未知性，至少部分是未知的。这要求团队运用经验反馈循环，深入了解客户需求，并收集关于其解决方案是否满足这些需求的反馈。这一点对于 MVP 和 MVA 来说都是一样的。
值得注意的是，MVP 和 MVA 并非一蹴而就的过程。每个产品发布都是团队运行的一组 MVP 和 MVA 实验，旨在更好地了解客户需求并交付价值。因此，每一次发布都可以被视为 MVP/MVA 组合的一个新版本。
敏捷、精益与复杂性
Dave Snowdon 的 Cynefin 框架 提出了四个问题空间：
明显的（Obvious），在这种情况下，选项清晰，对因果关系的共识很容易达成。
复杂的（Complicated），在这种情况下，可能存在多个 “正确” 的解决方案，需要专业知识来诊断和决定。
难以理解的（Complex），在这种情况下，可能没有“正确”的解决方案，因为它们太不可预测，无法应用已被证明的解决方案或确定因果关系。解决这些问题需要采用经验方法来形成和测试假设，并根据结果进行调整。
混乱的（Chaotic），在这种情况下，没有因果关系，最好的做法是尽量减少混乱，并建立一定程度的秩序和稳定。例如，紧急情况和自然灾害响应都属于此类。精益方法确实注重可预测性，并在处理明显和某些复杂问题时展现出其独特的优势。在这些情境中，问题的解决方案相对明确或至少是可定义的。当满足这些条件时，减少浪费、改进效率以及提高可预测性是追求的关键目标。
当面对目标和解决方案不明确定义的复杂问题时，敏捷方法则展现出其独特的价值。在这种情境下，没有现成的解决方案可以套用，只有一系列带有权衡和假设的部分解决方案。
这并不意味着精益方法在解决复杂问题时完全无用。相反，在软件开发的许多环节中，一些工作仍然十分简单或者没有那么复杂，如构建和测试过程，特别是使用持续交付管道或减少团队之间的交接浪费。构建正确的产品是一个复杂的问题，而正确地构建产品并没有那么复杂。
敏捷、精益与软件架构
为软件产品构建架构是一项复杂的任务，每个产品都面临着一系列独特的挑战，要求架构师通过细致的权衡来寻找最佳的解决方案。在之前的 文章 中，我们深入探讨了这一决策过程，并引入了最小可行架构（MVA）的概念，它作为这些权衡决策的重要反映。MVA 是最小可行产品（MVP）的架构补充，确保 MVP 在技术层面是可行、可持续且具备未来可扩展性，这是 MVP 与一次性概念验证的区别所在。
虽然精益方法主张将软件开发的核心聚焦于工作流程的改善，但从架构的视角来看，其核心问题在于如何构建既是最小可行产品又是最小可行架构的解决方案。
MVA 的一个显著特点在于它是在一系列产品发布的过程中逐步发展和完善的。开发团队通过收集和分析每次发布的实证数据，不断验证和调整对 MVA 适用性的假设。在没有充分实证数据支持的情况下，团队无法准确判断 MVA 是否适合当前的 MVP，也无法预测其在产品生命周期内的可行性。团队需要不断获取反馈，解决出现的问题，并在后续发布中持续改进 MVA。这种基于实证的反馈循环与敏捷方法的核心理念相契合。
鉴于开发团队在构建架构过程中需要作出多种类型的决策，且工作本身具有新颖性，因此这项任务本质上具有不可预测性。团队成员面对的是前所未有的挑战，他们的工作重点并非追求效率，而是确保决策的有效性。当然，通过应用一些精益原则，如减少在做的事情的数量（WIP）、缩短等待时间、减少中断和交接等，可以在一定程度上提高团队的工作有效性。他们当然对缩短获得反馈的时间感兴趣，但并没有显式地关注如何优化他们的工作流程。
精益方法适用于需求相对稳定且问题定义明确的情境，其优化目标在于消除不必要的浪费。然而，架构工作的挑战在于，在产品生命周期的早期阶段（有时是在产品生命周期的后期），形成架构的需求（我们称之为质量属性需求或 QAR）往往没有被透彻理解。
精益方法还追求减少浪费，这是一个有价值的目标。架构工作的问题在于，开发团队在缺乏实验验证的情况下难以判断决策的正确性。实验过程中，一些决策可能会被证明是错误的，但这样的 “失败” 并非真正的浪费，而是为团队提供了宝贵的反馈信息，有助于减少未来的浪费。
在软件开发过程中，精益方法特别关注由流程本身产生的浪费，尤其是那些已开始但未完成的工作造成的浪费。过多在做的事情（WIP）是造成这类浪费的常见原因，但在软件产品中，推迟决策、技术债务往往会造成一种特殊的浪费。敏捷交付周期的反馈能够揭示出技术捷径和推迟决策对产品满足 QAR 能力的潜在损害。当这种情况发生时，开发团队通常需要投入额外的时间和精力来解决技术债务并重新设计架构。从精益的角度来看，这可能会暂时打乱工作流程。然而，从长远来看，这是减少因产品无法维持其价值而产生的更大浪费所必需的。
结 论
组织既需要敏捷方法，也需要精益方法，但原因不同。敏捷方法的核心在于提供及时的反馈，确保团队正在构建的产品能够精准地满足客户需求，特别是在产品未能满足预期时，敏捷方法能够迅速揭示问题所在。他们也需要精益方法来消除浪费，帮助组织以更成本效益的方式交付高质量产品。因此，精益方法是敏捷方法的补充。
对于开发团队而言，敏捷实践是获取关于 MVP 及其相关 MVA 是否达到预期目标的关键途径。他们需要在后续产品中持续改进 MVP/MVA。如果 MVP/MVA 未能达成既定目标，单纯追求效率和生产力将无助于团队提供更优质的解决方案。
一旦团队对产品的发展方向和架构实现的目标有了较为明确的信心，他们可以将关注点逐渐转向效率、生产力和成本控制等方面。然而，即便在此时，团队也应牢记每次产品发布都是对产品价值和可持续性的一次实验性测试。
作者简介
Kurt Bittner， 拥有超过 30 年的经验，通过短期、以反馈为驱动的周期交付可工作的软件。他帮助了各种各样的组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售组织，以及大型政府机构。他曾为或与包括甲骨文、惠普、IBM 和微软在内的大型软件交付组织工作过，并曾是 Forrester Research 的技术行业分析师。他的重点是帮助组织建立强大的、自组织的、高绩效团队，交付客户喜爱的解决方案。他是与软件开发相关主题的四本书的作者，包括《用于扩展 Scrum 的 Nexus 框架》。他目前居住在科罗拉多州博尔德，并担任 Scrum.org 的企业解决方案副总裁。
Pierre Pureur，是一位经验丰富的软件架构师，具有广泛的创新和应用开发背景，对金融服务行业有着广泛的了解，拥有广泛的咨询经验和全面的技术基础设施知识。他过去担任过一家主要金融服务公司的首席企业架构师，领导过大型架构团队，管理过大规模的并发应用开发项目和指导创新计划，以及制定战略和业务计划。他是书籍《持续架构实践：在敏捷和 DevOps 时代的可扩展软件架构》（2021）和《持续架构：在敏捷和云为中心的世界中的可持续架构》（2015）的合著者，并在该领域发表了许多文章并在多个软件架构会议上做过演讲。
