- Agility捷行
- 2026-03-18
- 来源：
第二册【Scrum 模式语言16】定期产品增量（Regular Product Increment）
译者导读：
本文揭示了Scrum团队在固定周期内交付价值的真实挑战：真正的“完成”在于交付完整价值，而非孤立组件。产品的生命力源于市场真实反馈，而非内部各种指标。这是给陷于敏捷形式主义团队的一剂清醒良药，旨在帮助有困扰的朋友重拾对价值本质的敏锐感知。
在理想状态下，母鸡每天下一个蛋, 但实际上，母鸡的产蛋频率是固定的，需要26小时下一个蛋
..在当前的 ¶75产品周期中， ¶11 产品负责人 需要负责管理 ¶54 产品待办列表， ¶14开发团队 则需要努力完成 ¶71 Sprint目标。
通常，在每个¶46迭代中，团队创造的价值很难被验证。然而，产品负责人仍期望确保产品价值能够在一个接一个的Sprint中稳定地持续增长。
产品负责人总是期望采用正确的方式来创造高价值的产品，然而他们的构想与实际市场需求之间往往存在各种各样的差异。因此，产品负责人必须定期验证¶55产品待办列表中已完成的功能是否正朝着预期的价值方向发展。虽然已经有很多抽象的方法或模型（例如：挣值分析）可用于此类验证，但这些度量方法与产品实际的特性是脱节的，因此它们无法准确反映客户对价值的真实感受。
为了打造有价值的产品，¶7 Scrum团队在¶24迭代计划 中制定了Sprint目标，并在Sprint期间推动工作向Sprint目标发展。在Sprint结束时，团队应根据实际情况来核对与Sprint目标中所明确的预期价值是否一致。
利益相关者期望在Sprint结束时，开发团队能够交付有价值的成果。当由来自多个组织部门职能孤岛的专业人士组成的开发团队合作时，这些专业人员在完成开发任务后可能会认为他们已经创造了一个真正的产品。然而，由于缺乏统一的产品视角，他们可能仅仅生产出了相互独立的组件。实际上，整个产品的价值远超过其各个组件单独价值的总和，真正的价值在于将这些独立的组件整合成一个连贯的、整体的产品。市场并不关心开发团队是如何为了开发的便利性而划分产品模块的。
所以，在每个Sprint阶段，Scrum团队都致力于交付一个符合"完成定义"（参见¶82完成定义）、可用且具备潜在可发布性的产品增量。团队会通过产品增量来验证是否提升了产品价值，并了解产品在市场上的实际表现。从长远来看，终端用户将会更加满意，而当前的使用反馈也能够磨砺团队的预见力，从而帮助团队提前规避诸多未来的风险。
Scrum的主要价值就在于为利益相关者生产可使用的产品，每次交付一个可以评估的增量，并且通过使用和构建产品的实践经验来持续增加知识的积累。 这些知识能够帮助团队学会逐步改进流程和产品，参见¶101关于持续改善与突破性改善的内容。Sprint可以视为Scrum团队对产品的意图与现实之间的一道光。
开发团队将定期交付具有价值的产品增量，这些增量需支持¶39愿景，能够体现产品负责人的路线图（¶220产品路线图），并需要满足团队的"完成定义"。
增量与Sprint目标之间存在着紧密的联系。理想的产品增量不仅能实现Sprint的目标，而且应包含一系列相互关联的产品待办事项。我们采用Scrum中的Sprints的主要原因之一，就是为了交付一个贯穿始终、具有完整性的产品增量。
Scrum产品的定义、所有权和管理权归属于产品负责人。产品负责人同样肩负着提升产品价值的责任（¶246的“价值与投资回报率”部分）。Scrum本身并不规定产品的完整流程；因此，我们可以将自行车和飞机统一定义为一个产品，或者将浏览器和操作系统视为一个综合整体。一个产品可以支持一个或多个¶41价值流：既面向终端用户，也面向Scrum团队，他们本身即是产品成功的关键利益相关者。卓越的Scrum产品通过支持单一市场（终端用户）的价值流来实现精准的市场定位。任何特定的产品增量都会在一条或多条价值流中创造价值。
为了顺利交付产品增量，开发团队必须是一个¶10跨职能团队，能够在Sprint期间跨越其组织或角色的界限，以支持增量的交付。这对采用Scrum框架的组织来说是一项挑战。组织中的个体将通过他们的日常工作实践，展现出该组织真正奉行的价值观（与公开宣称的价值观形成对比）。如果设立仅强化局部工作考核的个体绩效指标，将阻碍跨职能协作，使开发团队无法完成产品增量。
当一个团队或组织能够交付产品增量时，将会对组织产生新的影响力量，包括：
l 关于“三重约束”或所谓的“铁三角”（时间、范围、成本），我们必须进行调整。鉴于Sprint周期是固定的，时间维度无法变动，因此我们只能通过调整范围和成本来适应这一要求。
l 尽管时间是固定的，但交付的频率也是固定的；不存在延迟交付的情况。
l 交付报告变得更加简洁明了：只需指出增量是已完成还是未完成。
l 那些曾阻碍产品增量开发的内部障碍，将随着团队跨职能协作的加强而逐渐消除。这将促使管理者的角色从资源调配转变为更加注重员工发展（一个常被忽视的领域）和意见领导力。
在每个Sprint的开发时间盒结束之后，团队应当举行¶35 Sprint评审会议，其中审查产品增量是一项关键议题。然而，产品发布后市场必然会产生更多反馈；为了尽快获取这些反馈，团队应将每个产品增量部署（而不仅仅是交付或发布）给实际使用它的用户群体。团队能够逐步将已批准的产品增量推向市场，范围逐渐扩大，可能始于风险较低的测试版发布，随后扩展至紧密合作伙伴，最终实现对整个市场的覆盖；参见 ¶86 发布阶段分层。在产品生命周期中，其对用户生活品质的提升、对构建其社区的贡献，以及对更广泛群体的影响，都应提升至¶93最大可能价值。
在Sprint结束时，团队还应举行¶36Sprint回顾会，以评审产品开发流程。
如果产品的价值流在各个市场中展现出差异化特征，企业应考虑对产品进行拆分；参见第90条《价值流分叉》。
译者：吴梦竹
校对：Nick
点击回顾第一册 Scrum模式语言合集
Tips：以上带符号黑体是模式语言
