企业级敏捷框架：业务驱动型敏捷与产品需求团队

本文介绍了一种新的企业级敏捷框架——业务驱动型敏捷（Business-driven Agile）与 PRT（Product Requirement Team），旨在解决传统敏捷方法中需求定义的瓶颈，从而提升产品价值并提高开发效率。原文: A new enterprise Agile framework: Business-driven Agile with PRT (Product Requirement Team)

在作为 Scrum Master 改造了几个敏捷项目之后，我意识到所有项目都面临着相同的瓶颈，那就是“需求应该由谁定义？”以及“如何高效定义需求？”尽管官方 Scrum 指南明确指出，产品负责人（Product Owner）负责产品 Backlog 的管理，但并没有明确谁应该定义需求以及如何定义需求。通常情况下，由于频繁的会议和沟通，产品负责人无暇定义所有详细需求，而由开发人员定义则会减少开发时间，降低开发速度。值得注意的是，当项目规模扩大时，这个问题会变得更加突出。因此，本文将创建一个新的企业级敏捷框架，名为“业务驱动型敏捷与 PRT（产品需求团队）”（简而言之，业务驱动敏捷），以解决这一问题。

什么是采用 PRT 的业务驱动型敏捷框架？

业务驱动型敏捷框架是一种新的企业级敏捷框架，它设置了 PRT（Product Requirement Team，产品需求团队），明确了如何有效定义需求，以提高效率并最大化产品价值。如前所述，业务驱动型敏捷的主要目的是简化需求定义过程，而这往往是开发的瓶颈，据我所知目前还没有相关框架。

业务驱动型敏捷基于 Scrum，因此继承了 Scrum 的价值观、角色和实践。业务驱动型敏捷可用于单个 Scrum 团队，但在大规模团队中效果更好，因为需求定义过程往往是瓶颈。要了解业务驱动型敏捷如何运作，需要了解如何定义需求和附加角色，下面将对此进行解释。

需求的 3 个基本组成部分

在不同软件项目中，定义需求的方法大相径庭，很多人都有自己的方法。然而，除非有令人信服的理由，否则应避免使用独创的方法，因为这些方法通常无效，会造成重复劳动，应该尽量遵循最佳实践。

业务驱动型敏捷定义了定义需求的三个基本组成部分：用户故事（User Story）、验收标准（Acceptance Criteria）和视觉图像（Visual Image）。长期以来，用户故事和验收标准一直作为敏捷最佳实践被广泛应用，而视觉图像则是软件项目中普遍需要的。

用户故事

用户故事（User Story）是一个简单的单行句子，概括的描述了用户想用产品做什么以及为什么。它最初是作为 XP（极限编程）的实践之一而产生，并被用于各种敏捷框架中，这是一种涵盖所有重要方面（谁、做什么、为什么）的强大描述。首先创建用户故事，然后根据用户故事进行讨论。用户故事有标准格式，如下面的登录示例。

[结构] 作为……，我希望……，以便……。

[示例] 作为用户，我想用电子邮件和密码登录平台，以便安全的使用平台。

验收标准

验收标准是支持用户故事的详细要求，将用于验收测试。这意味着验收标准扮演了两种角色：详细需求和验收测试。这种方法非常有效，因为在瀑布式项目中，它们通常是分开编写的，这会造成工作和文档的重复。首先编写验收标准被称为 BDD（Behaviour-Driven Development，行为驱动开发），其概念源于 TDD（Test-Driven Development，测试驱动开发），明确了产品应如何满足用户的期望。

编写有效的验收标准是业务驱动型敏捷的关键，因为这是最具挑战性的过程，需要技巧和时间。说到由谁来写，总是会引起争议。虽然产品负责人是合适的人选，但他往往忙于工作，无暇编写验收标准。由开发人员编写则会减少编码时间，降低开发速度。因此，以业务为导向的敏捷技术设置了一个新角色：需求定义者（Requirement Definers），稍后将对此进行解释。

强烈推荐使用 Cucumber 创始人 Aslak Hellesøy 创建的 “小黄瓜语法（Gherkin Syntax” 来编写验收标准，它涵盖了所有必要的方面：Given（条件）、When（操作）、Then（结果）。

[描述] “情景（Scenario）”描述测试（需求）的内容。“给定（Given）”描述用户采取任何行动前的初始情境或状态。“当（When）”描述用户采取的行动。“然后（Then）”描述用户行动的预期结果或后果。

[示例] 场景：成功登录。给定：用户拥有平台账户。当：用户输入电子邮件地址和密码。然后：按下登录按钮。 然后：成功登录平台。

视觉图像

视觉图像能让团队成员对需求有共同的理解。它可以采取任何形式，如草图、线框或复杂的设计，只要能帮助团队成员直观理解产品的外观和工作方式即可。由于“用户故事”和“验收标准”是基于文本的表达方式，其效果有限，而视觉图像则可以弥补这一不足。人类是高度视觉导向的动物，因此呈现视觉图像有助于我们加深理解。

PRT（产品需求小组）

PRT 负责需求定义并将其正确传达给开发人员。PRT 由产品负责人、需求定义者和设计者组成。下图展示了 PRT 与 Scrum 团队的组成。

产品负责人

产品负责人（Product Owner）的角色与标准 Scrum 相同，负责明确需求并做出决策。虽然设计人员和需求定义人员会帮助产品负责人定义需求，但产品负责人是唯一的决策点，从而避免决策过程的混乱。

产品负责人与设计师、需求定义者、Scrum 团队和利益相关者密切沟通，因此他的主要工作就是与人沟通。

要求定义者

需求定义者（Requirement Definer）是业务驱动型敏捷中新定义的职位，其职责是通过与产品负责人（Product Owner）和设计师密切沟通来定义详细需求。如上所述，详细需求被定义为验收标准，而需求定义者的主要任务就是编写验收标准。

虽然理想情况下需求定义者是专职职位，尤其是在大规模项目中，但当项目无法聘请专职人员时，需求定义者也可以兼任其他职位，如测试人员、设计人员、Scrum Master 等。例如，如果项目预算太紧，无法雇用专职的需求定义者，那么设计人员或测试人员就可以兼任需求定义者，应根据具体业务环境来定义和分配实际职责。

设计师

设计师负责绘制草图、插图或设计图等视觉图像，供整个团队共同理解。人类是高度视觉导向的动物，视觉图像有助于我们理解应该做什么。关键一点是，只要有助于共同的理解，视觉图像可以采取任何形式，其目的是让每个人的理解都保持一致。

整体流程

需求定义的整体流程如下图所示。通常，产品负责人首先根据利益相关者的想法创建用户故事。然后，设计师和需求定义者制作视觉图像和验收标准。尽管图中是顺序排列，但通常需要反复来回多次。

何时定义需求

需求定义应在 Sprint 之前进行，所需时间与 Sprint 相同。例如，如果项目 Sprint 为期一周，那么需求定义应该在前一周完成。这是因为需求定义所需时间通常比我们预期的要多，而且精确的需求定义对估算、优先级排序和范围管理都很重要。

Sprint 计划是团队确定 Sprint Backlog 的地方，Sprint Backlog 是选定的 PBI（Product Backlog Items，产品待办事项），预计在即将到来的 Sprint 中完成。换句话说，在敏捷中，范围是根据 Sprint 来控制，而 Sprint Backlog 就是 Sprint 的实际范围。需求、估算和优先级应被定义为确定 Sprint Backlog 的输入。这意味着团队不仅要确定需求，还要在前一周确定估算和优先级。由于这些要素相互交织，因此通常需要来回讨论。下图说明了 Sprint 计划的整体流程。

大规模模式

业务驱动型敏捷的设计是为了扩展，因为当项目规模变大时，需求定义过程往往会成为瓶颈，不过可以应用于单个团队。虽然 PRT 的架构不会改变，但需求定义者和设计者的数量会根据 Scrum 团队的规模和数量进行调整。下图描述了大规模团队架构。

即使项目规模扩大，产品负责人仍然是一个人，而不是委员会，以明确谁应该做出决策，防止决策过程中出现混乱。

采用 PRT 的业务驱动型敏捷实践

业务驱动型敏捷项目设置了多种实践，以最大限度提高产品价值和管理效率，这些实践包括 BDD、看板和路线图、无故事点估算和长期决策。

BDD（Behaviour-Driven Development，行为驱动开发）

BDD 是敏捷最佳实践之一，即在编码前编写带有验收标准的验收测试。BDD 明确了产品的行为方式，以满足用户期望以及业务人员和软件工程师之间的共同理解。BDD 是业务驱动型敏捷的核心，是需求的关键要素，能带来准确的估算、决策并防止产生 bug。如前所述，Gherkin Syntax 被强烈推荐用于实践 BDD 和编写验收标准，它是广泛使用的最佳实践。

看板和路线图

业务驱动型敏捷同时使用看板和路线图来管理开发状态和长期业务战略。看板是一种显示开发流程和任务状态的可视化板，在敏捷中被广泛使用。看板适合短期管理，能显示细粒度信息。另一方面，路线图适合中长期管理，能显示详细信息和总体进度，适用于与企业管理层等利益相关者进行讨论。业务驱动型敏捷在有效管理的背景下利用了两者的优势。

无故事点估算

业务驱动型敏捷从不使用故事点进行估算，因为故事点有几个缺陷。最关键的原因是，故事点无法支持产品负责人的决策。虽然估算的最终目的是支持业务决策，但业务人员无法根据故事点做出决定，因为它并不是标准的度量单位。业务驱动型敏捷的目的是加强业务人员与软件工程师之间的协作，最大限度提高产品价值，而故事点并不能帮助实现这两点。

相反，业务驱动型敏捷采用简单、标准的计量单位，如小时、天或周，以便于理解。只要能支持业务决策并让团队成员理解，可以采用任何单位。

长期决策

20 世纪 60 年代末和 70 年代初，人们做了一个著名的实验，叫做“棉花糖试验”，这个实验一直被人们讨论和铭记。一位教授把孩子们一个个放在小房间里，桌子上放着一个棉花糖，并告诉他们：“如果你们能等上 15 分钟，就能得到两个棉花糖。如果等不及，就只能得到一个”。有些孩子能等上 15 分钟，有些孩子却等不了。教授对这些孩子进行了长达数十年的跟踪调查，结果发现，与不能等待的孩子相比，能等待的孩子在经济稳定、学业成绩和事业成功方面都更胜一筹。实验证明，“延迟满足”和“耐心”有助于取得长期成功。

业务驱动型敏捷采用“延迟满足”和“耐心”，从长远角度思考和决策，因为软件项目通常是长期的，而长远思考会带来成功。例如，人们往往会被拖着开发新功能，认为这是“即时满足”，而拖延重构、重新设计数据库和基础设施，或教育下一任领导者。虽然后者不能立竿见影，但从长远看，它们会产生巨大影响。下图是“影响力矩阵（Impact Effort Matrix）”，描述了在短期和长期内哪些是重要的，哪些是不重要的。

结论

采用 PRT（产品需求团队）的业务驱动型敏捷框架是一种新的企业级敏捷框架，可简化需求定义流程（该流程往往成为软件开发的瓶颈），并最大限度的提高产品价值。由谁来定义需求一直是个有争议的问题，因为没有一个敏捷框架能明确这一点。业务驱动型敏捷通过设置 PRT 和描述如何定义需求来解决这个问题。

PRT 由产品负责人、需求定义者和设计者组成。产品负责人的角色与标准 Scrum 并无不同，其主要职责是做出决策，最大限度提高产品价值。需求定义者是新设立的角色，他们通过与产品负责人密切沟通，定义带有验收标准的详细需求。设计人员制作视觉图像，以便共同理解产品的外观和性能。

业务驱动型敏捷还建立了一些实践：BDD、看板和路线图、无故事点估算和长期决策。BDD 是源于 TDD（测试驱动开发）的一种软件开发实践，在编码前定义了产品应如何满足用户期望。看板有助于将开发过程和任务状态可视化，以管理短期开发，而路线图则通过消除细粒度信息来描述长期计划的概况。避免使用故事点，因为它们对业务不友好，不能支持业务决策，而这正是估算的最终目的。最后，团队应决定长期计划，因为软件开发不是短跑，而是马拉松，延迟满足将对长期发展产生巨大影响。

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！