编写用户故事是任何进入敏捷环境的软件工程师的基本技能。尽管许多团队依赖数字平台来管理任务，但理解无需依赖软件的用户故事核心机制，能打下更坚实的基础。本指南聚焦于手动流程，使用便利贴、白板和索引卡等实体工具来制定清晰、可操作的需求。目标是思维的清晰，而非屏幕的便利。
当你移除软件后，你被迫深入参与内容。没有自动补全功能或预设模板可以依赖。你必须明确表达价值、执行者和需求。这种手动训练确保团队在编写任何代码之前就充分理解问题领域。以下，我们将探讨故事的结构、验收标准，以及在无数字辅助下优化想法的方法。
📖 理解核心概念
用户故事是从希望获得新功能的人的角度出发，对功能的轻量级描述，通常是系统的用户或客户。它不是一份规格说明书，而是一次对话的占位符。将故事写在卡片或纸上这一物理行为，强化了这一意图。它本应被移动、编辑、丢弃或合并。数字系统往往过早地将你锁定在僵化的结构中。手动方法能保持故事的灵活性。
为什么要手动操作？
有几个强有力的理由支持新工程师练习手动编写故事：
- 关注价值：没有需要填写的字段，你就能专注于实际的价值主张。
- 认知负荷：手写会放慢你的节奏，让你在写下文字前有时间思考。
- 协作：实体卡片让团队能够实际移动工作内容，直观地展现流程和优先级。
- 独立性：你对格式掌握得如此熟练，即使工具不可用，也能写出有效的需求。
📋 手动故事的结构
每个用户故事都遵循特定的结构。手动编写时，应在索引卡或便利贴上使用一致的格式。这种一致性使团队在计划会议中能快速浏览信息。标准格式由三个不同部分组成。切勿跳过任何一部分。
1. 角色（谁）
明确具体的用户角色或类型。避免使用“用户”等泛泛的术语。要具体。是“管理员”、“访客”还是“高级订阅者”？角色决定了功能的权限和上下文。
2. 行动（做什么）
描述用户希望执行的功能或操作。这是动词。应为高层次的目标，而非技术实现细节。例如，“搜索项目”比“将查询输入SQL数据库”更合适。行动代表了用户的真实意图。
3. 价值（以便于）
这是新手常忽略的最关键部分。用户为什么想要这个？它提供了什么价值？如果你无法回答，这个故事可能并无价值。“以便于”部分将功能与业务或用户成果联系起来。
示例结构
写在一行或两行内。保持简洁。
- 作为一个 [角色]，
- 我想要 [行动]，
- 以便于 [优势].
📝 定义验收标准
一个故事如果没有验收标准就不算完整。这些是故事被视为完成所必须满足的条件。手动编写时，应将这些标准直接列在故事卡下方，或附在故事卡上的单独纸页上。它们充当工程工作的测试用例。
验收标准消除了歧义。它们定义了功能的边界。如果没有这些标准，两位工程师可能会为同一个故事实现不同的解决方案。手动编写迫使你在开发开始前就思考边界情况。
Given/When/Then 格式
为了精确的条件，使用 Given/When/Then 结构。这是行为驱动开发（BDD）的手动转化。它能清晰地组织逻辑。
- Given（给定）： 初始上下文或状态。
- When（当）： 发生的事件或采取的操作。
- Then（那么）： 预期的结果。
示例标准
- 当用户已登录时，
- 当他们点击登出按钮时，
- 那么他们将被重定向到登录页面。
- 当他们点击登出按钮时，
标准类型表
存在不同类型的准则。表格有助于在手动编写过程中对它们进行分类。
| 类型 | 描述 | 示例 |
|---|---|---|
| 功能型 | 系统的具体行为 | “系统在表单提交后发送邮件” |
| 非功能型 | 性能或安全约束 | “页面加载时间少于2秒” |
| 业务逻辑 | 数据管理规则 | “折扣仅适用于超过50美元的订单” |
| 可用性 | 易用性要求 | “按钮在不滚动的情况下必须可见” |
🌐 使用INVEST模型进行验证
当你手动编写完一个故事后，必须验证其质量。INVEST模型是这一过程的标准框架。你可以在一张单独的纸上使用检查清单，在将故事添加到待办事项列表之前对其进行评估。这可以确保工作是可管理且有价值的。
独立性
故事应该是自包含的。它不应依赖于另一个故事首先完成才能产生价值。虽然存在技术上的依赖关系，但其价值应能独立存在。如果你必须等待故事A完成后才能构建故事B，那么应考虑是否可以将故事B拆分。
可协商性
故事是一个讨论的承诺，而不是一份合同。它允许工程师与利益相关者之间进行交流。如果文本过于详细，它就变成了规格说明，而不是一个故事。应为技术探索留出空间。
有价值
每个故事都必须为用户或业务带来价值。如果一个故事无法有效满足“所以”（So That）的要求，就应该被丢弃或重新编写。价值是待办事项列表的主要驱动力。
可估算
团队必须能够估算所需的工作量。如果一个故事过于模糊，就无法估算。如果过于复杂，应将其拆分。手动编写有助于识别模糊之处，因为必须亲自写出细节。
小规模
一个故事应该小到可以在一个迭代或冲刺内完成。大型故事存在风险，常常导致工作不完整。如果一个故事感觉像一个项目，就应将其拆分为更小、按顺序排列的故事。
可测试
你必须能够验证故事是否已完成。如果没有验收标准，这个故事就无法测试。手动编写迫使你明确“完成”意味着什么。
INVEST检查清单
在规划期间使用此表格来审查你的故事。
| 字母 | 需要询问的问题 | 状态 |
|---|---|---|
| I | 这个故事能否在不依赖其他故事的情况下开发？ | [ ] |
| N | 范围是否开放以供讨论？ | [ ] |
| V | 它是否提供了明确的价值？ | [ ] |
| E | 我们可以估算一下工作量吗？ | [ ] |
| S | 它能在一个冲刺中完成吗？ | [ ] |
| T | 是否有明确的通过/失败条件？ | [ ] |
🔍 优化流程
优化，也称为梳理，是指为未来开发准备故事的活动。你不需要软件来进行优化。事实上，将卡片在桌面上移动这一物理行为，可以更好地帮助理解流程。一次优化会议包括审查故事、澄清细节以及拆分大型任务。
步骤1：审查
召集团队围坐在一张大桌子旁。摆出卡片。逐个大声朗读每个故事。这个简单的动作可以发现静默阅读时不易察觉的错误。注意‘以便’部分是否存在歧义。
步骤2：拆分
如果一张卡片感觉太重，就将其拆分。在一张新卡片上写下新的、更小的故事。将新卡片放在原卡片上方或旁边。确保原卡片更新以反映拆分情况。这种视觉上的分离有助于控制范围。
步骤3：提问
在审查过程中，团队会提出问题。将这些问题写在另一张纸上。不要立即回答。问题表明知识上的空白。它们将成为下一次会议的行动项。这使规划与解答过程分开。
步骤4：排序
按照依赖关系或价值对卡片进行排序。使用桌上的绳子或胶带表示连接关系。如果卡片A必须在卡片B之前完成，则在它们之间画一条线。这种视觉流程有助于在开发开始前识别瓶颈。
📈 优先级排序技巧
当你有一份故事列表后，就必须决定先开发什么。手动优先级排序方法通常比数字排序更有效，因为它们涉及对工作的实际互动。
MoSCoW 方法
用颜色标记你的卡片，或使用不同形状来表示优先级。这是一种经典的手动方法。
- M – 必须有：对发布至关重要。不容例外。
- S – 应该有：重要但非关键。如需可延迟。
- C – 可能有：理想但非必需。
- W – 不会包含： 已同意不包含在当前范围内。
加权最短作业优先（WSJF）
对于更数学化的方法，为价值和时间分配数值。将数值写在卡片上，手动计算比率。这迫使团队量化价值，而不是依赖直觉。这对新工程师理解商业权衡非常有价值。
⚠️ 需要避免的常见陷阱
即使采用手动方法，错误仍会发生。新工程师在没有软件验证指导的情况下编写故事时，常常陷入特定陷阱。
1. 技术术语
不要从系统的角度编写故事。避免使用“数据库”、“API”或“后端”等词汇。应从用户的角度出发。系统对用户来说是不可见的。如果你写“系统更新缓存”，用户并不关心。他们关心的是页面的加载速度。
2. 缺少验收标准
很容易写出“作为……”的部分，却忘记“以便……”或验收标准。没有标准的故事只是一个待办事项，而不是用户故事。这会造成歧义。在卡片被认为完成之前，必须始终要求提供标准。
3. 细节过多
编写故事不是编写规格说明书。如果在一张卡片上写了五段文字，很可能已经过度细化。保持卡片简洁。细节应出现在细化过程中的讨论中，而不是写在卡片上。
4. 忽视边缘情况
手动编写通常只关注正常流程。你必须明确写出出现问题时的情况。为错误状态添加验收标准。“当网络中断时，用户提交后，应看到重试提示。”
5. 缺乏协作
独自编写故事是浪费时间。故事是引发讨论的起点。如果你在没有与同事讨论的情况下编写故事，很可能被误解。务必与同事手动进行评审。
👩💻 后续过渡到数字化
虽然本指南聚焦于手动方法，但团队最终会转向数字化系统进行跟踪和报告。你在这里学到的技能可以直接迁移。当你最终使用数字化平台时，你会写出更好的故事，因为你理解了核心结构。你不会依赖软件来为你定义价值。
如果基础扎实，过渡将非常顺利。数字化工具成为你已深入思考的手动工作的存储库。你只需将卡片内容复制到系统中。逻辑保持不变。
📝 新工程师的实践练习
为了巩固这些概念，请尝试以下练习。它不需要软件，只需纸和笔。
- 步骤1： 选择一个你每天使用的功能（例如，网站上的搜索栏）。
- 步骤2： 使用标准格式在索引卡上编写用户故事。
- 步骤3： 使用Given/When/Then格式编写三条验收标准。
- 步骤4： 将INVEST模型检查清单应用到卡片上。
- 步骤5： 写下你对这个故事的两个问题，这些问题是一个开发者会提出的。
- 步骤6： 与同伴一起审查这张卡片。请他们对“所以”部分提出批评意见。
💬 关于手动纪律的最终思考
掌握用户故事的艺术在于精准与共情。你需要设身处地为用户着想。你需要表达清晰且简洁。手动过程剔除了软件界面的干扰，只留下核心信息。这种纪律让你成为更优秀的工程师，也让你成为更出色的沟通者。
当你摒弃工具后，剩下的只有逻辑。正是这种逻辑推动着软件的发展。通过手动练习，你可以在让计算机执行之前确保自己的逻辑是正确的。这种方法减少了返工，提升了质量。这是对自己定义价值能力的一种沉静而坚定的信心。
记住，目标不是填满一个数字待办事项列表。目标是为一个人解决问题。保持人在流程中。保持故事简单。保持标准清晰。无论你最终使用什么工具，这些原则都会对你大有裨益。
📊 关键要点总结
- 结构： 始终使用“作为……，我想要……，以便……”的格式。
- 标准： 明确给出“给定/当/那么”以确保清晰。
- 验证： 最终确认前，对照INVEST原则进行检查。
- 协作： 与团队一起实地审查卡片。
- 重点： 优先考虑用户价值，而非技术实现。