并非所有内容都需要成为用户故事：不如来试试使用FDD功能

面对用户的时候，一个简单、清晰的用户故事是很有必要的。但有的时候，由于系统或产品的用户与研发团队离得太远，以至于团队很难将用户的需求放入用户故事中。当团队开始写用户故事并以“作为一名开发人员”或“作为一名产品负责人”开头的时候，用户故事就不再是面向用户的了。

一般来讲，有比创建无效的“用户故事”更好的方法。如果要寻找替代的解决方案，那么第一步就是要认识到，产品待办列表中不是所有的内容都要被创建为用户故事的。

从具体某个团队的产品待办列表来看，近85%的故事是合格的用户故事，而近10%的故事是机械的，更有约5%的故事含义不明。

这5%的用户故事大概都是团队成员在匆忙之中添加进去的。最初，为了避免遗忘，这些内容会被放进待办事项列表中。其中一部分故事会被重新创建，并规整为合格的用户故事。还有一些类似于“升级 Linux 服务器”的内容，这类内容可以作为一个故事被重写。另一方面，这样的项目往往很容易被理解，并且它们不会长期存在于产品待办事项列表中。

真正值得关注的是占比10%的项目，这些项目技术性更高，但它们并没有使用规范的“作为什么，我想要做什么，以便于什么”的用户故事编写规范。

在这篇文章中，我们所讨论的产品是面向用户的，但并非产品研发的所有部分都是面向用户的。这类问题很普遍，因为一般情况下，产品的后端往往是用户无法接近的。在这种情况下，团队可以编写用户故事来反映用户如何从这些系统功能中获益。例如：作为一个用户，我希望备份所有数据，以便可以完全恢复数据。

在某些时候，这些用户故事的效果很好。但其他时候，例如故事所描述的功能与真实的用户距离太远，或者在找不到真实用户的情况下编写用户故事时，编写用户故事就不仅显得很假，还会让人感到很蠢。

在这种情况下，可以尝试着用一下特征驱动开发过程中的语法。特征驱动开发(FDD)从1997年就出现了，但在整个敏捷舞台上仍处于次要地位。最初，Jeff De Luca 发明了FDD，在这个对扩展敏捷感兴趣的时代，它有很多值得推荐的地方。

对于 FDD 的描述，网络上有很多详尽的资料，所以在这里只描述其中的一小部分：功能。FDD 功能就类似于 Scrum 中的产品待办事项。正如许多团队发现将用户故事作为产品待办事项列表项使用“As a, I want so that”语法很有用一样，FDD 也有自己推荐的功能语法。

FDD 功能是这样写的：

示例：

估计股票的收盘价
生成交易的唯一标识符
更改显示在 kiosk 上的文本
合并重复交易的数据

在每种情况下，功能描述都以一个动作（动词）开始，以系统中的对象结束。FDD 非常适合于面向对象的开发。

在开发诸如应用程序编程接口(API)之类的东西时，这会是一种非常好的语法。而且它对其他类型的后端功能也同样有效。正如在文章一开始所说的，团队的产品待办事项列表中大约有10%是适用于这种语法的。如果大家发现自己正在为某个系统的某些部分编写产品待办事项列表项，并且正在努力思考如何为这些项编写合适的用户故事，那么不妨考虑一下使用 FDD 的功能。你一定会发现它的有用之处。

起源

流派

视频

书籍

敏捷动态

培训

关于我们