质量始于意图。

-W。 爱德华兹戴明

Quality begins with the intent.

—W. Edwards Deming, Out of the Crisis [1]



 

解决方案意图

解决方案Intent是用于存储，管理和传达当前和预期解决方案行为的知识的存储库。如果需要，这包括固定和可变规格和设计;参考适用的标准，系统模型，功能和非功能测试;和可追溯性。

构建大型软件和网络物理系统是当今业界最复杂和最具挑战性的工作之一。这需要在两个核心问题上保持一致：

1.     我们正在建造什么？
2.     我们如何构建它？

更重要的是，这两个问题是相互关联的，并且相互影响。如果您不知道如何以经济或技术可行的方式构建某些东西，则必须在“如何”的背景下重新考虑正在构建的“什么”.SAFe将此关键知识库标记为解决方案意图 - 基本了解当前和不断发展的需求，设计和意图 - 即解决方案的更大目的。

某些解决方案意图是固定的，对于它必须做或已经做的事情具有不可协商的要求。一些解决方案意图是可变的，需要进一步讨论和探索，因为事实表面。理解和导航这些差异，并允许可变性（甚至在时间轴的后期），是解开大规模解决方案开发灵活性的关键。

细节

在构建具有不可接受的高成本故障的系统时，需要更严格的定义和系统行为验证是敏捷采用的重大障碍。虽然许多从业者对“敏捷宣言”[1]的价值陈述产生了共鸣，即“工作软件优于综合文档”，但这一概念可能会为需要两者的企业产生相互冲突的优先级。

工程复杂且高度可靠的解决方案需要并创建大量技术信息。其中大部分反映了解决方案要求和设计 - 功能和功能，故事，非功能需求（NFR），系统架构，域级模型和设计（例如电气和机械），系统接口，客户规范，测试和测试结果，以及可追溯性。其他相关信息记录了系统的一些关键决策和发现。这可能包括来自贸易研究的信息，实验结果，设计选择的推理以及其他项目。在许多情况下，无论是必要性还是法规，这些信息都必须成为官方记录的一部分。

在解决方案意图中捕获知识

解决方案意图是一个关键的知识库，用于存储，管理和交流“正在构建的内容”和“如何构建它”。它有多种用途：

•     提供有关解决方案的预期和实际行为的单一事实来源
•     记录并传达需求，设计和系统架构决策
•     促进进一步的勘探和分析活动
•     使客户，开发团队和供应商与共同的使命和目标保持一致
•     支持合规和合同义务

未来和当前的解决方案意图

图1说明了解决方案意图的复杂性：

•     当前和未来的状态 - 复杂系统的开发人员必须经常知道两件事：当前系统究竟做了什么，以及未来状态的变化
•     规格，设计和测试 - 只要包含三个主要元素：规范（系统行为的文档定义），设计和测试，就可以以任何合适的形式捕获当前和未来状态的知识。

图1.解决方案意图的剖析

当构建必须完全符合预期的系统时 - 包括生命关键，关键任务和其他受法规标准约束的系统 - 可追溯性有助于确认系统将按预期运行。它将解决方案意图的元素彼此连接，并连接到实现其完整行为的系统组件。解决方案意图本身是协作创建的，并且基于学习而发展，如图1所示。

解决方案意图的特定元素可以以多种形式实现：从文档，电子表格和白板会话到形式要求和建模工具，如基于模型的系统工程（MBSE）中所述。但是解决方案意图是构建解决方案的一种手段，因此捕获它的方法不应该产生不必要的开销和浪费（参见下面的充分讨论）。

使解决方案意图动态化

传统上，一组详细的，前期的，固定的需求充当解决方案意图的代理。但SAFe原则＃3，假设可变性;保留选项，告诉我们在前期过于紧密地定义需求和设计会导致不太成功的结果。需要一种不同的方法，一种支持理解已知的方法，但允许在开发过程中出现未知的方法。

解决方案意图不是静态的一次性声明：它必须支持整个开发过程并继续发展。图2将传统的早期固定需求分解与精益敏捷方法进行了对比，在这种方法中，执行工作的人员在适当的时间进行分解。

图2.解决方案Intent随着解决方案开发的所有步骤而发展并支持它们

解决方案意图作为未来系统的愿景，使这些团队及其积压工作保持一致。它提供了建立当前愿景所需的详细信息，但允许团队灵活地探索构建解决方案的未知因素。由此产生的知识（我们能否建立未来的系统，以及我们从探索中学到了什么？）提供了有关未来系统的反馈和适应的机会。

使用固定和可变解决方案意图保持选项打开

解决方案意图有多种用途。但是，它们都没有要求预先创建完全定义的“点解决方案”规范。这些早期决策限制了对更好的经济替代方案的探索，并经常导致浪费和返工。 [2]为了防止这种情况，SAFe描述了解决方案意图的两个要素，固定和可变，支持一般的自适应要求和创造最佳经济结果的设计理念。

固定意图代表'知识'。它们可能是不可谈判的，或者它们可能在开发过程中出现。例子包括：

•     某些性能规格（“起搏器波形必须如下”）
•     合规标准（“符合所有PCI合规信用卡要求”）
•     定义解决方案的核心能力（“Baja Adventure Ride拥有四名成年骑手”）

可变意图代表了允许探索可满足需求的要求和设计备选方案的经济权衡的要素。一旦建立起来，这些新的见解最终将成为固定的要求。

从变量到固定需要获得知识来做出决策。启动者是SAFe探索未知因素并记录解决方案意图中的知识和决策的工具。遵循基于设定的设计实践，团队探索替代方案以达成最佳经济决策。这些决策可以在路线图中开发下游功能（图3）。

图3.从变量移动到固定解决方案意图

在每个计划增量（PI）中，团队同时构建我们所知道的内容，同时探索我们尚不了解的内容。

固定知识不会从零开始，因为即使在图3的左端，也知道很多。例如，重用以前开发的系统中的元素。然后，通过开发过程，随着迭代，PI和解决方案演示显示系统的功能，可以更快地了解更多信息。通过这种方式，可变意图随着时间的推移变得固定，并且对系统的作用和需要做的事情有了充分的了解。

协同开发解决方案意图

解决方案意图是团队和项目领导之间的协作。产品和解决方案管理以及解决方案架构师和系统工程负责最高级别的系统范围决策（系统分解，接口以及对各种子系统和功能的需求分配）。他们还建立了解决方案意图的组织结构，以支持未来的分析和合规性需求。解决方案意图有助于推动团队积压中的本地化决策，如图4所示。

图4.解决方案Intent通过协作发展

由此产生的工作向计划领导提供有关进展和方向的反馈。

如图5所示，积压项定义填充解决方案意图的工作，将变量假设移向固定决策。

图5.开发解决方案意图

解决方案的意图始于Vision，它描述了解决方案的目的和关键功能，以及系统的非功能需求。这些知识以及新兴的路线图和关键里程碑指导团队创建积压和规划他们的工作。但路线图和解决方案意图充满了假设。 SAFe对持续交付的指导通过最小可行产品（MVP）验证假设，这些产品通过频繁，可量化的实验提供经过验证的学习。注意：解决方案意图中经过验证的学习主要是技术性的，但Build-Measure-Learn和Pivot或Persevere的以业务为中心的精益创业原则仍然适用。

在整个供应链中连接解决方​​案意图

系统的解决方案意图不一定是孤立的。许多解决方案是参与更高级别系统系统的系统。在这种情况下，其他系统以及供应商提供了加速开发的独特知识和解决方案元素。例如，供应商通常会为其子系统或功能提供单独且独立的要求，设计和其他规范。从他们的角度来看，这是他们的解决方案意图因此，最终（顶级）解决方案意图必须包括沟通决策，促进探索，协调团队和支持合规性所需的相关供应商知识和信息。这种“菊花链”需求会在系统层次结构中上下移动设计决策，如图6所示。

图6.解决方案Intent层次结构

创建最小但足够的文档

解决方案意图是达到目的的手段 - 它是指导，促进和沟通决策以及证明合规性的工具。规划解决方案意图的内容，组织和文档策略应从这些目的开始。但更多不一定更好。在记录需求，设计和架构时，精益敏捷社区建议保持清晰[5]。最佳做法包括：

•     偏好文档模型 - 持续变化的环境挑战以文档为中心的方法来组织和管理解决方案意图。如果应用得当，模型（包括由现代实践产生的模型，如设计思维和以用户为中心的设计）可以提供更容易维护的管理方式，如MBSE中进一步讨论的那样。
•     保持解决方案意图协作 - 没有垄断创新，解决方案意图不是产品和解决方案经理，架构师和工程师的专有领域。许多团队成员参与解决方案意图信息的创建，反馈和改进。
•     保持选择开放 - 将决策推迟到当地关注的问题，并尽可能晚地做出决定。只要经济上可行，对需求和设计的自适应方法就可以保持有希望的选择。基于集合的设计实践有助于避免过早地承诺设计和要求。
•     仅在一个地方记录项目 - 在一个地方记录任何要求和设计决策，一个单一的事实来源，作为每个人和所有事物的记录存储库。
•     保持高水平 - 尽可能高地进行沟通，并且不要过度指定。提供一系列可接受的行为。用意图描述解决方案行为，而不是特异性。分散要求和设计决策权。
•     保持简单 - 只记录需要的内容。解决方案意图是在遵守合同和合同义务的同时构建产品的方法。少即是多。

 

学到更多

• [1] Agilemanifesto.org。
• [2] Ward，Allen和Durward Sobek。精益产品和流程开发。精益企业研究所，2014年。
• [3] Reinertsen，Don。产品开发流程原则：第二代精益产品开发。 Celeritas Publishing，2009。
• [4] Leffingwell，Dean和Don Widrig。管理软件需求：用例方法。艾迪生 - 韦斯利，2003年。
• [5] Ambler，Scott。 “敏捷架构：扩展敏捷开发的策略。”敏捷建模，2012。http://agilemodeling.com/essays/agileArchitecture.htm。

讨论：请加入知识星球【首席架构师圈】