product-software-agile-adaptation

name	product-software-agile-adaptation
description	当团队使用敏捷却发现产品探索、设计和开发混在一起，导致迭代只是快速做错东西时调用。不适用于定制项目的普通 Scrum 培训。
source_book	《启示录：打造用户喜爱的产品》 Marty Cagan
source_chapter	第 26 章 合理运用敏捷方法
tags	["agile","product","process"]
related_skills	[]

产品软件敏捷适配

R — 来源依据 (Reading)

原书依据见本节来源说明。

依据产品软件领域使用敏捷方法的诀窍。

本仓库不收录原书全文；此处只保留章节级依据和方法论重述。

I — 方法论骨架 (Interpretation)

• 敏捷适用于产品软件，但不能照搬定制软件。
• 产品经理和设计师应领先开发一两个迭代周期。
• 原型和用户故事要作为开发基础，开发团队自主估算实现。

A1 — 书中的应用 (Past Application)

案例 1: 产品经理即产品负责人

• 问题: 客户需求代表不能和产品负责人割裂。
• 方法论的使用: 产品经理保持与开发密切联系。
• 结论: 避免敏捷中需求断层。
• 结果: 团队持续讨论产品。

A2 — 触发场景 (Future Trigger)

用户会在什么情境下需要这个 skill?

当团队使用敏捷却发现产品探索、设计和开发混在一起，导致迭代只是快速做错东西时调用。不适用于定制项目的普通 Scrum 培训。

语言信号

• "敏捷团队产品越来越乱"
• "设计跟不上开发"
• "MVP 是不是不用规划？"

与相邻 skill 的区分

• 本 skill 处理 产品软件敏捷适配 这一单点问题；若问题跨越多个环节，请先读本书 INDEX.md 选择组合顺序。

E — 可执行步骤 (Execution)

1. 分离探索与交付

   • 完成标准: 明确哪些是假设验证，哪些进入开发。

2. 前置设计节奏

   • 完成标准: 产品和设计领先 1-2 个迭代。

3. 用原型和用户故事交接

   • 完成标准: 让开发看到已验证体验。

B — 边界 (Boundary)

不要在以下情况使用此 skill

• 不要把敏捷当省略产品规划。
• 复杂架构不能依赖后期随意重构。

作者的盲点 / 时代局限

• 书较早，部分互联网实践已演进。
• 以软件产品为主，硬件和 AI 产品需要补充约束。

相关 skills

• depends-on: {}
• contrasts-with: {}
• composes-with: {}

审计信息

• 验证通过: V1 ✓ / V2 ✓ / V3 ✓
• 测试通过率: 100% 设计通过；结构校验见本书 QUALITY_REVIEW.md
• 蒸馏时间: 2026-06-18