# Story设计核心理念 ## 🆚 传统做法 vs PromptX做法 ### **传统User Story格式的问题** ```markdown 网上标准格式: "作为<角色>，我想要<功能>，以便于<价值>" 问题分析: ❌ 关注解决方案而非问题本身 ❌ 容易变成功能需求列表 ❌ 缺乏对用户真实困难的深度理解 ❌ 开发团队被限制在预设解决方案中 ❌ 难以激发创新的解决思路 传统案例: "作为产品经理，我想要一键导入角色配置，以便快速使用AI角色" → 这是在描述期望的功能，而非用户遇到的真实困难 ``` ### **PromptX障碍导向的优势** ```markdown PromptX格式: "作为<角色>，我在<任务>时，遇到<障碍>，导致<后果>" 优势分析: ✅ 深度挖掘用户真实痛点 ✅ 让开发团队理解问题本质 ✅ 为创新解决方案留下空间 ✅ 促进以用户为中心的思考 ✅ 提高解决方案的针对性和有效性 PromptX案例: "作为新用户，我在配置AI角色时需要手动输入大量参数，经常出错导致重新开始" → 这是在描述用户遇到的具体困难和影响 ``` ### **从传统到PromptX的转换示例** | 传统格式（功能导向） | PromptX格式（问题导向） | 解决方案空间 | |------------------|---------------------|------------| | 作为用户，我想要实时进度条，以便了解系统状态 | 作为用户，我在系统运行时无法知道当前进度，经常不确定是否需要等待 | 进度条/状态指示/时间预估/通知机制等多种可能 | | 作为开发者，我想要命令行工具，以便快速获取提示词 | 作为开发者，我在获取角色提示词时需要手动拼接多个文件，容易遗漏依赖 | CLI工具/聚合API/IDE插件/配置管理等 | | 作为管理员，我想要批量导入功能，以便管理大量数据 | 作为管理员，我在处理100+条记录时只能逐条手动操作，耗时且易错 | 批量导入/模板填写/API批处理/自动化脚本等 | ## 🤔 Story = 任务障碍问题发现 ```markdown Story的本质：发现用户在执行具体任务时遇到的障碍 核心思考：作为XX角色，我在完成XX任务时被什么困难阻碍了？ 问题导向框架： 📋 提问题层: Epic → Feature → Story (需求定义) 🛠️ 解决问题层: Task (技术实现) ✅ 验证层: TestCase (质量保证) 🎯 价值确认层: Milestone (交付确认) ``` **Story的职责边界**： - ✅ 发现用户在具体任务中遇到的障碍和困难 - ✅ 识别任务执行过程中的中断点和痛点 - ✅ 定义用户在特定操作中的困扰体验 - ❌ 不设计具体功能实现方案 - ❌ 不定义技术解决方案 - ❌ 不描述"用户想要什么功能" ## ⚠️ 常见陷阱与避免方法 ```markdown 陷阱1: 写成功能需求单 错误表述: "作为用户，我想要一键导入角色配置文件，以便快速使用" 正确表述: "作为新用户，我在配置AI角色时需要手动输入大量参数，经常出错导致重新开始" 陷阱2: 描述解决方案而非障碍 错误表述: "作为开发者，我想要命令行聚合工具，以便获取完整提示词" 正确表述: "作为开发者，我在获取角色提示词时需要手动拼接多个文件，容易遗漏依赖" 陷阱3: 关注期望功能而非当前困难 错误表述: "作为用户，我想要实时状态反馈，以便了解系统运行情况" 正确表述: "作为用户，我在系统运行时无法知道当前进度，经常不确定是否需要等待" 陷阱4: 任务描述过于宽泛 错误表述: "作为产品经理，我想要管理产品需求，以便规划产品发展" 正确表述: "作为产品经理，我在制定Sprint计划时无法快速评估需求优先级，经常延误规划" ``` ## 🔄 实践转换指南 ### **Step 1: 识别用户真实任务** ```markdown 问自己: 用户在什么具体场景下需要完成什么任务？ 避免模糊表述: ❌ "管理数据" → 太抽象 ❌ "使用系统" → 太宽泛 寻找具体任务: ✅ "导入客户数据" → 具体操作 ✅ "配置AI角色参数" → 明确任务 ✅ "评估需求优先级" → 清晰目标 ``` ### **Step 2: 挖掘任务执行障碍** ```markdown 追问方式: 1. "用户在执行这个任务时，哪个步骤最困难？" 2. "什么情况下用户会失败或中断？" 3. "用户最常在哪里出错或感到困惑？" 4. "哪些因素让任务变得低效或烦躁？" 障碍类型检查: 📋 操作复杂: 步骤太多、容易出错 ⏰ 时间成本: 等待太久、重复劳动 💭 认知负担: 信息不足、选择困难 🔄 流程中断: 依赖缺失、错误恢复 ``` ### **Step 3: 量化障碍影响** ```markdown 影响维度: 📊 频率: 多少用户会遇到？多久遇到一次？ ⚡ 严重性: 对任务完成影响多大？ ⏱️ 时间损失: 额外花费多少时间？ 😤 挫败感: 用户情绪影响程度？ 具体化表述: ❌ "经常出问题" → 模糊 ✅ "每次配置时30%概率需要重试" → 具体 ❌ "很慢" → 主观 ✅ "等待时间超过30秒" → 可量化 ``` ### **Step 4: 障碍表述检查清单** ```markdown 格式检查: □ 用户角色具体明确（不是"用户"泛称） □ 任务场景具体可观察 □ 障碍描述详细具体 □ 影响后果明确可量化 内容检查: □ 没有包含解决方案暗示 □ 没有使用"想要"、"需要"、"希望"词汇 □ 从困难角度而非期望角度描述 □ 开发团队看后能理解要解决的具体问题 质量检查: □ 其他团队成员能够理解障碍 □ 可以想象多种不同的解决方案 □ 障碍解决后用户体验会明显改善 □ 符合INVEST原则要求 ``` **问题导向自检清单**： - [ ] Story描述中是否包含"想要"、"需要"、"希望"等需求词汇？ - [ ] 是否先描述用户遇到的具体困难，而非期望得到的功能？ - [ ] 能否用"什么阻碍了用户完成任务"来概括Story？ - [ ] 开发团队看到Story能理解要解决的具体障碍？ # Story设计流程 ```mermaid flowchart TD A[Feature问题域拆解] --> B[识别具体任务场景] B --> C[分析任务执行障碍] C --> D[编写障碍描述格式] D --> E[INVEST原则验证] E --> F[编写问题解决标准] F --> G{障碍完整性检查} G -->|完整| H[Story就绪] G -->|不完整| I[补充障碍分析] I --> C B1[主要任务路径] --> B B2[异常处理路径] --> B B3[边界操作场景] --> B ``` ## Story障碍识别方法 ```mermaid mindmap root((障碍识别)) 操作困难 步骤繁琐复杂 操作容易出错 学习成本高 信息缺失 状态不明确 反馈不及时 结果不可见 流程中断 等待时间长 依赖不可用 错误恢复困难 体验痛点 操作重复冗余 界面不友好 响应速度慢 ``` ## 📊 任务障碍量化模板 ```markdown ### 具体障碍描述 - 任务场景: [用户尝试完成什么具体任务] - 遇到困难: [在哪个步骤遇到什么障碍] - 困难表现: [障碍如何具体表现，如错误、延时、复杂] - 当前处理: [用户如何绕过或处理这个障碍] ### 障碍影响分析 - 影响频率: [多少比例的用户会遇到此障碍] - 困难程度: [障碍对任务完成的阻碍程度] - 时间成本: [障碍导致的额外时间损失] - 错误风险: [障碍可能导致的错误概率] ### 解决期望 - 理想体验: [障碍消除后用户应该有什么体验] - 成功标准: [如何验证障碍得到解决] - 性能指标: [时间、错误率等具体改善目标] ``` ### Story障碍描述标准格式 ``` 作为 [具体用户角色] 我在 [执行具体任务时] 遇到 [具体障碍和困难] 导致 [任务中断或效率低下的后果] ``` - **用户角色**: 具体明确，避免"用户"这样的泛化表达 - **任务场景**: 具体的任务执行情境，不是抽象目标 - **障碍描述**: 详细说明遇到的具体困难和阻碍 - **影响后果**: 明确障碍对任务完成造成的具体影响 ### 障碍解决标准编写(GWT格式) ``` 给定 [用户执行任务的初始状态] 当 [用户遇到特定障碍情况时] 那么 [障碍应该如何被消除或减轻] ``` - **覆盖障碍场景**: 主要障碍、边界情况、异常处理 - **解决标准具体**: 避免主观词汇，使用可验证的改善标准 - **完整性**: 操作改善、信息改善、体验改善 ### Story障碍复杂度分级 | 障碍类型 | 复杂度 | 解决时间 | Story Points | 影响范围 | |---------|-------|---------|-------------|---------| | 简单操作障碍 | 低 | 0.5-1天 | 1-2点 | 单一操作 | | 标准任务障碍 | 中 | 1-3天 | 3-5点 | 任务流程 | | 复杂体验障碍 | 高 | 3-5天 | 8点(需拆分) | 跨任务影响 | ### Story到Task问题解决策略 ```mermaid flowchart LR A[Story障碍] --> B[前端改善Tasks] A --> C[后端改善Tasks] A --> D[体验优化Tasks] A --> E[其他Tasks] B --> B1[界面优化] B --> B2[交互改善] C --> C1[性能优化] C --> C2[逻辑简化] D --> D1[流程优化] D --> D2[反馈改善] E --> E1[文档改善] E --> E2[监控添加] ``` 1. **INVEST原则强制遵循** - Independent: Story间障碍独立，可单独解决 - Negotiable: 保持障碍描述灵活性，通过对话细化问题 - Valuable: 每个Story解决的障碍都有明确用户价值 - Estimable: 障碍清晰，解决方案明确，可准确估算 - Small: 1-2周内解决，单人可独立处理 - Testable: 有具体改善标准，可验证障碍消除 2. **Story格式强制要求** - 必须使用"作为...我在...遇到...导致..."障碍描述格式 - 用户角色必须具体明确，不能使用"用户"泛称 - 任务场景必须具体，避免抽象的目标描述 - 障碍描述必须具体可观察，避免解决方案暗示 - 影响后果必须明确，说明障碍造成的具体问题 3. **解决标准强制要求** - 必须使用Given-When-Then格式描述改善标准 - 至少包含3个场景：正常改善、异常处理、边界优化 - 标准必须具体可测，避免主观判断 - 必须包含操作改善、体验改善、性能改善标准 4. **拆分触发条件** - 超过8 Story Points必须拆分 - 解决时间超过1周必须拆分 - 涉及多个用户角色的障碍需要拆分 - 包含技术复杂性或不确定性需要拆分 1. **用户认知约束** - 用户对系统理解程度影响障碍识别 - 用户技能水平影响障碍严重程度 - 用户使用习惯影响障碍感知 2. **技术实现约束** - 现有架构限制障碍解决方案 - 性能瓶颈影响体验改善程度 - 兼容性要求限制改善范围 3. **业务流程约束** - 业务规则限制流程优化 - 合规要求影响操作简化 - 数据安全约束体验改善 4. **项目资源约束** - 迭代时间限制障碍解决数量 - 测试资源影响改善验证 - 人员技能影响障碍解决复杂度 | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 | |---------|---------|---------|-----------| | INVEST符合度 | 完全符合6个INVEST原则 | 基本符合，个别项可改进 | 不符合多个INVEST原则 | | 障碍描述质量 | 障碍具体可观察，场景明确 | 基本清晰可理解 | 障碍模糊或偏向功能需求 | | 格式规范性 | 严格按照障碍描述格式 | 基本符合格式要求 | 格式不规范或要素缺失 | | 用户视角 | 完全从用户困难角度描述 | 基本体现用户视角 | 偏向系统或解决方案视角 | | 影响量化 | 障碍影响具体可量化 | 影响基本明确 | 影响不明确或过于抽象 | | 独立性 | 障碍独立可单独解决 | 基本独立，少量依赖 | 严重依赖其他Story | | 可验证性 | 改善标准具体可重复执行 | 基本可测试验证 | 难以验证或标准主观 | | 复杂度合理性 | 1-2周解决，复杂度适中 | 大小基本合理 | 过大过小影响解决效果 | **快速检查要点**： 📝 **障碍导向**: 描述用户困难而非功能需求，避免"想要"、"需要"、"希望"等词汇 🎯 **任务具体**: 从用户执行具体任务的障碍角度定义问题 📊 **困难量化**: 障碍影响和后果必须具体可观察，有明确改善标准 🔍 **场景明确**: 任务场景具体，障碍描述准确，可独立解决和验证