18、用户故事：从需求到价值交付的变革

用户故事：从需求到价值交付的变革

1. 确保用户故事与业务目标对齐

在软件开发过程中，确保所实现的用户故事与业务目标保持一致至关重要。传统上，从客户那里提取需求时，往往存在沟通差距。通常会有中间人将用户或客户的需求转化为文档，再交给开发团队，而团队很少能直接接触到需求方。

为了解决这个问题，需要让客户全程参与到团队工作中，不仅在冲刺评审阶段，在待办事项梳理和细化等合适的时机都应如此。参与的人员可以包括业务利益相关者和用户体验利益相关者，涉及的范围越广越好。如果用户故事涉及架构方面的影响，还应让架构师参与讨论。

1.1 “三 amigos” 模式

“三 amigos” 是软件开发中的一个概念，通常由开发、测试或质量保证以及产品管理的代表组成。他们紧密合作，共同定义和细化软件需求。根据故事类型，也可以有来自架构或 DevOps 团队的成员加入。这些 “朋友” 并非只是编写需求，而是以协作的方式塑造需求，确保价值的交付。

1.2 验收标准的重要性

很多公司没有充分利用验收标准，或者没有有效地对其进行优先级排序。验收标准需要平衡，既不能过多导致价值混乱，也不能过少或不合理。

对于测试人员来说，验收标准可以帮助他们了解客户认为重要的内容，从而对测试进行优先级排序。基于风险的测试方法，就是对应用或功能中更有价值的部分进行更多测试。而验收标准如果以价值为导向编写，就能为测试人员提供关于产品所有者和客户认为有价值的提示。

对于开发人员来说，与性能相关的验收标准不是一个简单的勾选框，而是需要认真考虑如何将其集成到整体系统设计中的关键因素。

2. 衡量用户故事的成功

在衡量用户故事的成功时，不应仅仅关注 “故事完成度” 等指标，而应更注重价值驱动的结果。作为咨询公司，更强调提供能直接影响客户及其客户群的切实利益。

2.1 泪滴指标

“泪滴指标” 可以衡量客户的满意度，例如客户表示 “这正是我所设想的” 就是积极的泪滴指标。除了直接的结果，还可以考虑吞吐量指标（衡量在给定时间内完成的工作量）和批量指标。

2.2 批量指标

批量指标常用于制造业和供应链管理，基于特定数量的单位进行性能或质量的测量。例如，在质量控制中，缺陷率是一个常见的批量指标，用于衡量给定批次中缺陷单位的数量；在供应链管理中，批量指标可以指存储或运输特定批量大小的成本。

批量大小的决策在库存管理中也很关键，不同的批量大小技术（如经济订货量、逐批订货或定期订货量）旨在平衡持有成本和订货或设置成本。

3. 从需求到用户故事的哲学转变

3.1 传统需求模式的问题

传统上，业务分析师会要求客户详细定义产品需求，这个过程往往过于繁琐和耗时。用户倾向于列出他们可能想要的所有东西，而不仅仅是他们真正需要的。这些需求会被转化为正式文档，作为与开发团队的合同，但这种方式往往让开发团队失望。

3.2 用户故事的新范式

用户故事是未来对话的占位符，不需要是详细的需求，只需要足够用于估算所需资源。它改变了开发过程的基调，从正式的合同转变为友好的对话，建立了完全不同的动态。

用户故事可以作为规划游戏中的占位符，在需要处理时，团队可以与客户进行实时协作。这种方式使得协作成为一个持续的过程，而不是局限于特定阶段或项目启动时。

3.3 用户故事带来的影响

这种转变使得开发过程从刚性、线性的过程转变为灵活、迭代和协作的过程，就像敏捷方法所体现的那样。它不仅对客户有影响，对团队其他成员也有积极影响，简化了流程，从冗长的书面文档转变为更直观的表示，如团队房间墙上的索引卡。

索引卡成为团队的共享资源，团队成员可以直接与之互动。例如，测试人员可以从索引卡开始创建满意度条件，并从一开始就与开发人员和产品所有者进行讨论。这种方法将问题解决转变为共享的、积极的讨论，鼓励持续的协作问题解决，而不是孤立的工作。

下面是一个简单的流程图，展示从传统需求到用户故事的转变：

graph LR
    A[传统需求模式] --> B[业务分析师收集需求]
    B --> C[转化为正式文档]
    C --> D[交给开发团队]
    D --> E[可能出现沟通问题]

    F[用户故事模式] --> G[用户故事作为占位符]
    G --> H[团队与客户持续对话]
    H --> I[协作完成开发]
    I --> J[更好地满足客户需求]

4. 用户故事的中断模式与反馈循环

4.1 传统需求过程的不足

传统的项目需求过程存在诸多问题。团队往往被灌输需求，但这些需求可能无法完全满足客户的实际需求。在构建全新的东西时，假设客户清楚自己的需求并将需求固定下来，往往会导致失败。实际中会不断出现小问题，通过变更请求解决这些问题会引发客户和开发团队之间的争议和指责。

4.2 用户故事的中断模式

用户故事是一种中断模式，它打破了人们传统上向下传递需求的思维方式。用户故事不是对所需创建内容的完整详细描述，因为在为客户提供服务时，我们实际上并不知道如何创建满足他们需求的东西。我们需要与提出需求的人进行良好的对话，以找到满足他们当前理解的最佳方式。

4.3 用户故事的反馈循环

用户故事不仅是未来对话和协作的承诺，还完成了与客户的反馈循环。我们可以询问客户是否在意我们所构建的内容，是否会实际使用，以及如何改进。

在信息无处不在、技术选择繁多的当今世界，频繁的沟通和快速响应变得至关重要。用户故事有助于我们更好地适应这种变化，使开发过程更加灵活和贴近实际需求。

4.4 工作场所的人性化转变

工作场所正变得更加人性化，从将组织视为可运行的机器转变为将其视为共同繁荣、生存或消亡的生态系统。这种转变让我们更加关注实际发生的事情，而不是强行推动事情的发展。

在复杂的世界中，我们不知道自己不知道什么，直到我们开始共同行动。用户故事促进了提出需求的人和创建产品的人之间的合作，在这个过程中给予了真正的责任感和灵活性。

5. 对待用户故事的态度

虽然用户故事实践并非万能，但我们可以像对待敏捷方法一样对待它。如果想要改变与用户故事相关的某些方面，只要能坚持敏捷框架的价值观，就可以尝试。

最重要的是不要忘记检查和适应的循环。尝试新的方法后，要了解其是否有效，如果无效则退回，如果有效则继续前进。但由于涉及到人类，每个人都有自己的边界和不愿意跨越的地方，这使得这个过程既美好又复杂。

以下是一个表格总结不同专家对于用户故事的观点：
| 专家 | 主要观点 |
| ---- | ---- |
| Bob Galen | 强调客户参与、“三 amigos” 模式和验收标准的重要性，以及价值驱动的指标衡量 |
| Michael Spayd | 阐述从需求到用户故事的哲学转变，用户故事是未来对话的占位符，改变了开发过程的动态 |
| Lyssa Adkins | 指出用户故事是中断模式，完成反馈循环，适应信息时代的变化，促进工作场所的人性化 |

综上所述，用户故事在软件开发中带来了从需求到价值交付的变革，通过多种方式确保与业务目标的对齐、衡量成功、促进协作和适应变化。在实际应用中，我们应充分利用用户故事的优势，同时根据具体情况灵活调整，以实现更好的软件开发成果。

6. 用户故事实践的具体应用案例

6.1 案例一：制造企业的生产流程优化

某制造企业在引入用户故事实践后，对生产流程进行了优化。在项目开始前，通过与业务利益相关者、生产工人以及质量控制人员等多方进行沟通，形成了一系列用户故事。

在待办事项梳理阶段，“三 amigos” 模式发挥了重要作用。开发人员、测试人员和产品管理人员共同参与，确保每个用户故事都清晰明确且与业务目标一致。例如，有一个用户故事是 “生产工人能够快速准确地记录产品的生产数据”，架构师也参与到这个故事的讨论中，确保系统架构能够支持高效的数据录入和存储。

在验收标准方面，制定了详细且合理的规则。测试人员根据验收标准对系统进行测试，重点测试与生产效率和数据准确性相关的功能。通过基于风险的测试方法，优先测试对生产流程影响较大的功能，提高了测试效率和质量。

在项目实施过程中，采用了用户故事作为规划游戏的占位符。团队成员将用户故事写在索引卡上，贴在墙上。当需要处理某个故事时，立即与相关的生产工人进行沟通，了解他们的实际需求和使用场景。这种持续的沟通和协作使得项目能够快速响应生产过程中的变化，最终成功优化了生产流程，提高了生产效率和产品质量。

6.2 案例二：供应链管理系统的升级

一家供应链管理公司对其系统进行升级时，运用了用户故事的方法。在项目初期，与业务利益相关者、物流人员和仓库管理人员等进行深入交流，收集了大量的用户需求，并转化为用户故事。

在衡量项目成功方面，采用了多种指标。除了关注客户满意度的 “泪滴指标” 外，还使用了吞吐量指标和批量指标。例如，通过吞吐量指标衡量在一定时间内处理的订单数量，通过批量指标评估库存管理的效率和成本。

在开发过程中，用户故事促进了团队成员之间的协作。测试人员根据用户故事中的验收标准，提前参与到开发过程中，与开发人员共同解决问题。同时，通过与客户的频繁沟通，不断调整和完善用户故事，确保系统能够满足供应链管理的实际需求。最终，系统升级项目成功上线，提高了供应链的运作效率和响应速度。

7. 用户故事实践的挑战与应对策略

7.1 挑战一：团队成员对用户故事的理解不一致

在引入用户故事实践时，团队成员可能对其概念和作用理解不一致。有些成员可能仍然习惯于传统的需求文档方式，对用户故事的灵活性和迭代性感到不适应。

应对策略：开展培训和知识分享活动，让团队成员深入了解用户故事的概念、价值和使用方法。可以邀请有经验的专家进行讲解，或者组织内部的案例分享会，让团队成员亲身体会用户故事在实际项目中的应用效果。

7.2 挑战二：客户参与度不足

虽然强调客户全程参与团队工作，但在实际项目中，客户可能由于各种原因参与度不足。例如，客户可能没有足够的时间参与讨论，或者对项目的关注度不够。

应对策略：建立有效的沟通机制，定期与客户进行沟通和反馈。可以通过线上会议、面对面交流等方式，及时向客户汇报项目进展情况，并邀请客户参与关键环节的讨论和决策。同时，向客户强调他们的参与对项目成功的重要性，提高客户的参与积极性。

7.3 挑战三：验收标准难以制定

制定合理的验收标准是一个挑战。如果验收标准过于严格，可能会增加开发和测试的难度；如果过于宽松，又可能无法保证产品的质量。

应对策略：由 “三 amigos” 共同参与制定验收标准。开发人员从技术实现的角度提供建议，测试人员从测试的可行性和有效性出发，产品管理人员从业务需求和客户期望的角度进行把关。在制定过程中，要充分考虑项目的实际情况和风险，确保验收标准既能够保证产品质量，又具有可操作性。

以下是一个流程图，展示应对用户故事实践挑战的过程：

graph LR
    A[发现挑战] --> B[分析挑战原因]
    B --> C[制定应对策略]
    C --> D[实施策略]
    D --> E[评估效果]
    E --> F{是否解决问题}
    F -- 是 --> G[继续推进项目]
    F -- 否 --> B

8. 总结与展望

用户故事作为一种新兴的软件开发方法，在确保与业务目标对齐、衡量项目成功、促进团队协作和适应变化等方面具有显著的优势。通过让客户全程参与、采用 “三 amigos” 模式、重视验收标准以及建立有效的反馈循环等方式，能够更好地满足客户需求，提高软件开发的质量和效率。

然而，在实际应用中，用户故事实践也面临着一些挑战，如团队成员理解不一致、客户参与度不足和验收标准难以制定等。我们需要采取相应的应对策略，不断完善和优化用户故事的应用方法。

未来，随着技术的不断发展和业务需求的日益复杂，用户故事实践有望进一步发展和创新。例如，结合人工智能和大数据技术，对用户故事进行更深入的分析和挖掘，以更好地预测客户需求和优化开发过程。同时，用户故事也可能在更多领域得到应用，为不同行业的项目开发带来新的变革。

总之，用户故事为软件开发带来了新的思路和方法，我们应该积极探索和应用，以适应不断变化的市场环境和客户需求。

以下是一个表格总结用户故事实践的优势、挑战和应对策略：
| 方面 | 详情 |
| ---- | ---- |
| 优势 | 确保与业务目标对齐、促进团队协作、完成反馈循环、适应变化、提高客户满意度 |
| 挑战 | 团队成员理解不一致、客户参与度不足、验收标准难以制定 |
| 应对策略 | 开展培训和知识分享活动、建立有效沟通机制、“三 amigos” 共同制定验收标准 |