在用户故事中应该包含多细的细节？(译)——来自 Mike Cohn

Bruce 有话说

就像原文中副标题写到的，我们应该从只有少量细节开始，迭代演进的方式直到找到正确的需求细节程度。平时我们很多团队都会一味的要求需求细节越多越好。似乎这样才能保证做出来的就是客户希望的。项目才能成功。而往往会发现，无论多少细节似乎最后总会有新的发现，甚至花费好几个月编写的需求规格说明书，最后用户确认签字，仍然会有做得不对的情况发生。这篇文章给了我不一样的视角：

1. 过多的细节会阻碍团队思考，因为默认认为细节已经全部获得。而减少了过程中的检视和调整。

2. 信息少更能激发团队来寻找更多细节，而这个过程会让方向和细节更精确。减少跑偏，同时只获得更需要的信息。

3. 细节太多会让团队进行抵制偏离细节列表的行为，即使有更好的方式，而这便造成了浪费。

希望本文能够给你带来更多的视角和思考。

正文

几分钟前我叫了外卖。我点的菜里有苹果。我要的是蜜脆苹果，我得到的就是蜜脆苹果。我没有指定苹果的直径应该正好是 3 英寸。我没有指定苹果要硬而不发霉。在下单时，我必须提供一点细节:苹果的品种和数量。我必须提供足够的细节，以确保我能得到我想要的。这与产品负责人要求团队构建新功能时的情况非常相似。提供的细节太少，你就得不到你想要的。但提供太多细节也会带来问题。在本文中，我将讨论细节过多和过少的问题，如何确保添加正确数量的细节，以及何时应该添加细节。

细节太少的问题

如果产品负责人写了一个用户故事，或者更普遍地说，任何产品待办事项列表项，包含的细节太少，团队就不知道要构建什么。这意味着:

• 团队会利用宝贵的时间来提问

• 团队成员可能不想问一些问题，所以会构建一些不正确的东西

• 评估更有可能是错误的，因为它们是基于对待办事项的不全面的理解来进行的

• 基于这些评估给利益相关者或客户的承诺很可能是错误的

尽管这些问题可能很糟糕，但团队需要小心，不要通过转向相反的极端或添加太多的细节来解决它们。

细节过多的问题

过多的细节乍听起来像是一种矛盾——对于产品待办事项列表项目，你不可能太丰富，也不可能太少了，也不可能有太多的细节。除了产品待办事项列表项可能有太多的细节。如果包含过多的细节，那么就会浪费时间添加不必要的细节，添加细节的人所支付的金钱也会被浪费了。告诉我的杂货店员帮我找到直径为 3 英寸的苹果是在浪费我和店员的时间，除非在某些少见的情况下确实需要正好直径为 3 英寸的苹果。也许比浪费时间和金钱更糟糕的是，开发人员可能会人为地受到过多细节的限制。假设我向一个杂货店员提供了以下规范:

• 买五个苹果

• 蜜脆品种

• 三英寸直径

• 坚硬的

• 没有瘀青

如果没有 5 个苹果满足所有这些要求，店员该怎么办?最后一个苹果选择稍微大一点可以吗?还是三英寸直径最重要?我想要一个没有淤青的大苹果，还是一个大小适中但有淤青的苹果?

这对于苹果来说似乎微不足道。但在开发产品时却不是这样。当向团队提供了一长串用户描述必须满足的需求时，许多团队会抵制偏离该列表中的任何内容，即使有更好的构建特性的方法。

做对它

一个团队不太可能立即在其产品待办事项列表中捕捉到正确数量的细节。这意味着团队可能需要迭代以获得适当数量的细节。我发现，当团队成员只带着很少的细节开始时，他们更容易找到合适的数量。当一个团队一开始就有太多的细节时，团队成员甚至可能不会注意到有问题。请记住，过多细节的最大问题是，在需要之前收集细节会浪费时间。然而，团队可能不会注意到这一点，或者认为这是一种浪费。团队成员可能只看到他们的迭代平稳地运行，很少有最后一刻的发现使他们偏离轨道，并且会满足于这样的细节量。然而，这有点像提前六个月列购物清单。我知道，六个月后，我几乎肯定需要买鸡蛋和苹果，这是我家附近的两种主食。但是，提前 6 个月列一份购物清单是没有必要的。

从不充分的细节开始

当一个团队在开始时细节太少时，他们会注意到由此产生的问题。团队成员将努力在迭代中完成所有项目;有太多悬而未决的问题有待解决。当他们只知道基本的需求时，他们可能会觉得自己被要求评估一些东西。因为这些都是具有明显含义的真实问题，所以当团队成员收集的细节太少时，他们就会很清楚。解决办法很明显:收集更多的细节。与上面相反的情况是团队添加太多细节，似乎一切进展得会很顺利。通过从产品待办事项列表中不充分的细节开始，团队将能够快速检视和调整以找到适当的细节量。

刚刚够用的细节看起来什么样？

当产品待办事项列表项包含了正确数量的细节时，团队成员会觉得在迭代过程中他们几乎无法完成这项工作。他们会觉得好像已经提前确定了足够的细节，但又并不会在迭代过程中删除太多的创意的机会。在争取这些感觉的过程中，重要的是不要过早地在产品待办事项列表中添加太多的细节。

举个例子

一个例子将有助于了解应该包含多少细节。假设一个团队正在构建一个新的应用程序，并且正在处理一个允许成员登录系统的用户故事。为该故事确定了各种验收标准，也称为满意条件，说明用户:

• 必须提供一个唯一的电子邮件地址

• 必须指定强密码

• 可以通过他们的 Facebook 账户登录吗?

考虑提供强密码的要求。这一描述没有提供多少细节。密码必须有多长?是否需要包含任何特殊字符?特殊字符?有多少?用户可以将密码更改为以前使用过的密码吗?编写和测试这个用户故事的团队成员需要知道这些问题的答案。但是他们不需要知道这些问题的答案，然后才能开始用户故事登录这个用户故事。答案可以在团队成员开始处理这个故事之后发现。也许这些细节是在程序员和测试人员开始编写故事的一小时后添加的。他们带着问题列表去找公司的首席安全官谈话，回来的时候知道了详细的答案。关键是，在第一次编写故事时，“必须指定强密码”就足够了。有关强密码构成的细节可以稍后确定。

对于一些超级安全的系统，我承认我错了。但是，对于我们大多数人登录的大多数系统，我已经准确地描述了情况。

通过 Facebook 登录我们的另一个验收标准是，用户可以通过他们的 Facebook 账户登录。这是过早提供过多细节的一个例子。

在第一次写登陆故事的时候，只说用户可以通过社交账号登陆，而不是通过 Facebook 登陆会更好。在大多数情况下，我们没有理由预先确定 Facebook 是用户唯一的额外登录方式。

适量细节的乐趣

学会在产品待办事项列表中包含正确数量的细节是团队及其产品负责人真正理解敏捷的有力标志。个人都会意识到，尝试添加适量的细节，有时会包含得太少。这意味着一些产品待定项无法在迭代中完成。但这没关系，因为每个人都会明白，避免这种情况有时需要包含太多的细节。团队、产品负责人和利益相关者将会意识到，添加太多的细节比偶尔因为包含的细节太少而遗漏一个代办列表项更糟糕。

原文引用

-What Level of Detail Should Be Captured in a User Story?

【欢迎关注我的博】