Linux有创新。我为一些非常好的技术特性感到骄傲。Linux中有一些其他操作系统所没有的功能。

—Linus Torvalds, creator of Linux



 

特性和功能

特性是满足涉众需求的服务。每个特性都包含一个收益假设和验收标准，并且根据需要由一个敏捷发布培训(ART)在一个程序增量(PI)中交付。

能力是一种更高级的解决方案行为，通常跨越多种艺术。功能的大小被划分为多个特性，以便于在一个PI中实现它们。

特性也适用于精益UX流程模型，该模型包括最小可销售特性(MMF)的定义、收益假设和接受标准。MMF有助于限制范围和投资，增强灵活性，并提供快速的反馈。功能的行为方式与功能相同。但是，它们处于更高的抽象级别，并且支持大型解决方案的定义和开发。

细节

特性和功能是安全需求模型的核心。它们对于定义、规划和实现解决方案价值至关重要。图1为这些工作项提供了更广泛的上下文:

图1所示。安全上下文中的特性

图1显示了使用特性开发的解决方案。每一个都反映了系统提供的服务，它满足了涉众的一些重要需求。它们被保存在计划Backlog中，并被调整成适合PI的大小，以便每个都交付新的值。特性可以来自于艺术的本地上下文，也可以来自于分离的史诗或功能。

程序和解决方案看板系统支持特性和功能流，它们通过漏斗、分析、积压、实现、验证、部署和发布状态进行处理。这个过程为增量实现提供了合理的经济分析、技术影响和策略。

产品管理和系统架构师/工程分别拥有特性和启用器。非功能需求(NFRs)定义系统属性，如安全性、可靠性、性能、可维护性、可伸缩性和可用性。NFRs作为跨不同积压的系统设计的约束或限制。使用加权最短作业优先(WSJF)对特性进行优先级排序，并在PI边界处进行规划和评审。它们被分解为故事，并随着功能的可用而实现、集成、测试和演示。

描述的功能

功能是使用功能和好处(FAB)矩阵定义的:

• 特征-提供名称和上下文的短短语
• 利益假设——对最终用户或企业提出的可衡量的利益

避免使用旨在支持一个用户角色的“用户故事语音”格式定义功能;特性通常为多个用户角色提供功能。此外，使用相同的方法来描述用户故事和特性可能会让业务人员感到困惑，特别是因为他们通常不熟悉故事。

图2展示了一个具有四个不同特性的FAB示例:

图2。特征与利益矩阵

创建和管理特性

产品经理与产品所有者和其他主要涉众协作，在艺术的本地上下文中定义特性。有些是史诗分裂的结果。

系统架构师通常创建启用器特性。程序backlog用于在业务特性的同时维护启用程序。推动者为架构铺平道路并支持探索，或者可能提供开发、测试和集成计划所需的基础设施。

就像业务特性一样，使能特性可能来自于史诗，也可能出现在本地的艺术级别。通过看板系统的启用程序将受制于计划安排中的容量分配，以确保对进一步解决方案和扩展体系结构跑道给予足够的重视。在每一个PI边界上，分配给新特性(或功能)的资源与启用程序的百分比被估计为指导培训。

排序功能

WSJF优先级模型用于根据产品开发流程的经济性对作业(例如特性、功能)进行排序。由于按照正确的顺序实施正确的工作可以产生最大的经济效益，因此很难高估这个关键过程的重要性。

产品和解决方案管理有权对特性进行优先级划分，而系统和解决方案架构师和工程人员有权对启用特性进行优先级划分。

评估功能

特征估计支持预测价值交付，应用WSJF优先级，并通过将史诗划分为特征并将其单独的估计相加来对史诗进行分级。特性估计通常发生在程序看板的分析状态中，并且依赖于标准化的估计技术，类似于敏捷团队使用的方法(有关详细信息，请参阅迭代计划文章)。在分析过程中，从艺术领域中选择从事探索活动和初步定量化的学科专家。在分析状态期间，调整特性的大小不需要将它们分解为故事或者包含所有可能开发它们的团队。

接受功能

验收标准用于确定实现是否正确并交付业务利益。图3提供了一个例子:

图3。带有验收标准的特性

验收标准降低了实现风险，并使收益假设能够得到早期验证。此外，验收标准通常是各种故事和功能测试的来源，功能测试是开发和自动化的，以支持重构和回归测试。虽然通常应用于事例，但是行为驱动开发(BDD)为特性创建了更好的一致性和详细的验收测试。

产品管理负责接受产品特性。他们使用验收标准来确定功能是否得到了正确的实现，以及是否满足了非功能需求。

功能

本文的大部分内容致力于描述特性的定义和实现，因为它们是对系统行为最常见的描述。功能与特性具有相同的特性和实践。例如,他们:

• 是用短语和利益假说来描述的吗
• 尺寸是否适合一个圆周率，然而，他们往往采取多种艺术实现
• 使用解决方案看板进行推理和批准。解决方案Backlog拥有已批准的功能
• 相关的推动者是否描述并使所有支持有效开发和交付业务功能所需的技术工作可见
• 是否为解决方案管理人员所接受，他们使用接受标准来确定功能是否适合用于目的

功能可能起源于解决方案的本地上下文，也可能是跨多个价值流的投资组合史诗的拆分的结果。另一个潜在的功能来源是解决方案上下文，其中环境的某些方面可能需要新的解决方案功能。

分割特性和功能

功能必须分解为要实现的特性。反过来，它们又被分解为可由团队在迭代中使用的故事。SAFe提供了10种用于分割工作的模式，如Leffingwell[1]第6章所述。

• 工作流步骤
• 业务规则的变化
• 主要工作
• 简单和复杂
• 数据的变化
• 数据的方法
• 推迟系统质量
• 操作
• 用例场景
• 拔尖

图4演示了将功能划分为特性。

图4。将功能划分为多个特性

了解更多

• [1]Leffingwell,院长。敏捷软件需求:团队、程序和企业的精益需求实践。addison - wesley, 2011年。

原文：https://www.scaledagileframework.com/features-and-capabilities/

本文：https://pub.intelligentx.net/safe-features-and-capabilities

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