用户故事及拆分原则

INVEST原则

image.png

如何写好用户故事

image.png

如何拆分用户故事

横切/侧切方法

image.pngimage.png
优点：快速实现核心逻辑，快速上线验证假设
缺点：第一个版本用户体验差
image.pngimage.png

用户故事的八种拆分方法

image.png
1）按工作量大小拆分
image.png
2）按CRUD分分解
image.png
3） 按业务规则可变性
image.png
4） 按操作类型
image.png
5）按流程步骤
image.png
6） 推出性能实现
image.png
7）简单到复杂
image.png
8） 故事穿刺
image.png

image.png

image.png

敏捷需求的梳理

需求的准入/准出标准

误解：敏捷就是快，需求没定义清楚就急于开工
image.png

需求分层

image.png

敏捷需求的核心

  • 结构化 - 史诗/特性/故事/任务
  • 故事化 - 故事/价值
  • 原型化 - 原型界面/更好理解
  • 规格化 -任务拆分 + 验收标准

image.png

如何写好验收标准

image.png
image.png

用户故事模板

image.png

用户故事地图

如何有效的组织和管理用户故事？

image.png

image.png
image.png

MVP

image.png

洞察客户需求
image.png

增量开发&迭代开发

image.png
Incremental development – 增量开发
不要与迭代开发混淆了（见下文）。增量开发是指一次完成一小部分产品的构建（一开始很清晰要做什么），直到全部完成。每次增量中都添加一部分，这些增量可能很小或很大。你可以通过增量开发来使用CI，但是使用增量开发可能难以实现持续交付或持续部署，因为你必须等到所有增量完成之后才能交付价值。

解释增量式和迭代式开发之间差异的一个很好例子，是Jeff Paton的蒙娜丽莎。(译注：见下图的说明，意思就是达到目标的不同方式)
image.png

Iterative development – 迭代开发
不要与增量开发混淆（见上文）。迭代开发是从一点点开始逐次构建产品（一开始并不清楚用户想要什么），不断完善直到完成。产品是迭代开发的，意味着同样的部分每次迭代都要改进。在不同的迭代版本中功能特性有别，在这之间计划和预期产品的变更。你可以使用持续集成、持续交付或持续部署进行迭代开发。
image.png

image.png

用户故事地图示例

image.pngimage.png
image.png
image.png
image.png

用户故事的估算

故事点 (Story Points)
Scrum指南告诉我们，估算应该由将要完成工作的人提供，但它并没有告诉我们应该如何提供估算。它把这个决定留给了我们。Scrum团队使用的一种常见策略是使用称为故事点的度量单位进行估算。但为什么要使用Story Points而不是几小时或几天或任何其他众所周知的时间单位？我们是故意试图混淆吗？在本文中，我将介绍使用Story Points的优缺点，并得出一个令人惊讶的结论。

“故事点是一个相对的度量单位，由各个Scrum团队决定和使用，以提供完成要求的努力的相对估计 “

为什么要使用Story Points？
故事点旨在使团队评估更容易。与其他产品积压项目 (product backlog items) 相比，团队只考虑产品积压项目需要多少工作量 (effort)，而不是查看产品积压项目并在几小时内估算出来 。
好的，所以它使评估更容易，但它有用吗？
我们无法对成本和可交付时间进行任何预测，至少直到我们从可能需要几个月的几个冲刺(sprints)中获得了速度(velocity)的平均值

使用时间作为度量单位有什么问题？
几百年来，我们有了标准的时间单位。为什么我们不能使用几小时或几天？好吧，简而言之，因为你的小时与我的小时不一样。

如果您要求两位开发人员估算相同的任务，您将得到两个不同的答案。虽然一些差异可能是由规范或理解上的差距来解释的，但事实是开发人员拥有不同的知识和经验，因此需要花费更多或更少的时间来完成相同的工作。
要求这两个开发人员评估完成一个产品积压项目(Product backlog item) 相对于另一个产品积压项目所需的工作量，并且您更有可能最终达成共识。

实际执行过程中，大家习惯用“人天”作为故事点单位。

使用Story Points的真正原因
因此，到目前为止，您可能不相信使用Story Points的必要性。好吧，他们展示了完成不同产品积压项目工作的相对工作量，但这对任何事情有何帮助？在我们了解团队的速度之前，我们仍然无法预测产品积压项目何时可能完成。更糟糕的是，如果团队成员发生变化，速度会发生变化，我们将不知道新的速度是什么，直到一段时间。

所有这些问题导致许多人试图在故事点和时间之间建立关联，但正如 Mike Cohn 在他关于将故事点与小时相关的文章中 指出的那样，这并不是微不足道的。
但是，尝试将故事点数与小时相匹配是不容忽视的。重要的是团队可以在冲刺 (sprint)中完成多少个故事点 (story points)，称为速度 (velocity)。当你知道这一点时，你可以做出一些预测而且你知道什么，它们可能是好的。很好。

使用Story Points的真正原因是它们是准确的。
谁这么说？Jeff Sutherland，Scrum指南的合着者。在他关于为什么故事点比几小时更好的文章中 他这样说：使用故事点因此比小时更快，更好，更便宜，而表现最好的团队完全放弃任何每小时估计，因为他们认为它是浪费，只会减慢他们的速度。

参考