功能是满足利益相关者需求的服务。 每个功能均包括收益假设和接受标准，并按需要调整大小或拆分，以由单个Increment Release Train在程序增量中交付。 —扩展敏捷框架（SAFe）
这就是SAFe定义功能的方式。 但这足以提供高质量的功能描述吗？ 为什么高质量不仅对实现的功能很重要，而且对它的描述也很重要？
功能定义了要实现的内容。 每个软件工程师都知道：“垃圾进，垃圾出”。 这就是为什么我们需要确保定义的质量实际上允许我们为每个功能交付价值。 与推动者相比，我们不仅为内部客户（主要利益相关者群体）创造功能的价值，而且为最终用户创造价值。
在Swisscom，我们与Creaholic携手合作，在定义质量和最终用户价值方面迈出了一步。
在一系列由不同部门的产品经理组成的混合试点小组的一系列研讨会和会议中，我们采取了迭代的方式来解决该主题。 在评估过去编写的功能的信息质量时，我们很快注意到，我们在信息的编写方式方面仍然有很大的自由度，因为SAFe到目前为止尚未对此提供任何更具体的要求。 例如，在许多情况下，收益假设实际上并未公式化为假设。 但是，对于敏捷开发，在编写功能时，收益和假设要素都是必不可少的：
- 我们使用收益一词是因为我们想创造价值。 如果功能定义甚至没有指示其值，则实现该功能也不太可能提供所需的值。
- 我们使用“假设”一词，因为世界具有波动性，不确定性，复杂性和歧义性（VUCA）的特征，即我们只能做假设。 重要的是实际描述一个假设，而不是陈述一个假定的固定目标。 这种假设应该为验证提供可能性，从而使功能实现后可以被接受或拒绝。 反过来，这可以为功能的未来开发提供重要的见识。 换句话说，应该吸取教训。
专题写作画布
为了提高功能的质量，我们开发并测试了画布：
在这里，我们将更详细地探讨画布的三个方面：收益假设，受益人和接受标准。
受益人
当我们希望为利益相关者或用户创造价值时，首先要问自己的问题是：我什至知道用户是谁？ 我知道他们需要什么吗？ 当然，对于较大的IT项目，这通常很难实现。 尽管如此，我们应该意识到，除非我们与最终用户联系，否则我们可能不会完全理解这些要求。 因此，我们不仅应遵循客户的领导，而且还应本着敏捷工作的精神，在有关最终用户的问题上挑战他们。
在画布中，此部分非常简单：名称或角色列表。 但是，这些信息也可以帮助产品经理挑战自我：我对要求有多自信？
利益假设
我们建议对利益假设使用以下标准措辞：
如果（提议），则（好处）
该提议描述了我们计划开发的产品。 收益描述了我们期望其实现的价值。 收益的类型多种多样，可以有多种形式：提高效率，降低成本或提高业务端的透明度。 它们还可以提高用户的满意度，功能或简便性。
因此，编写功能的产品经理应该使用画布来挑战自己，例如提出以下问题：该功能是否真的可以提供预期的价值？ 这实际上是该功能所能实现的吗？ 我如何确定正是此功能将提供此价值？ 我是否试图验证这个假设？
验收标准
验收标准不仅为评估实施是否达到目标提供了基准。 他们还应确保提供实际利益。
验收标准用于确定实施是否正确并带来业务收益。 验收标准可减轻实施风险，并能够尽早验证收益假设。 而且，接受标准通常是各种故事以及功能测试的来源。 —规模化敏捷框架（SAFe）
接受标准不能用作待办事项，也不能描述功能的实现方式。 他们应使用功能性，已实现的功能描述系统的状态。 他们回答了该命题的最低要求是什么，以确保可以提供利益假设中描述的利益。
利益假设和接受标准可以按1：n的比例定义，即每个利益假设至少具有一个或多个接受标准。
结论
标准化的书写格式是提高功能质量的第一步。 这与我们在故事中看到的相似，在故事中特定的写作形式得到发展并取得了成功。 但是，确保功能提供附加值的关键因素是促使产品经理了解他们的用户。 这意味着从旧的基于任务的结构转向敏捷的产品发现：对功能的追求，与用户的交谈，理解他们的需求以及使用原型验证假设。
一个功能并非像故事一样小。 总体而言，我们将大量资源用于实现功能。 我们越准确地理解主张和利益并能够描述它们，要求就越清晰，并且优先级，实施和测试就越容易进行。 因此，良好的功能是创造成功产品的关键一步。
下载专题文章画布
