• 00
  • 00小时
  • 00
  • 00
2023敏捷武林大会-上海站,正火热免费报名中...
Search
Close this search box.

用户故事究竟该有多详细?

在写用户故事时,人们最容易犯的错误与在正确的时间引入适当的细节有关。
这是一项非常重要的平衡技巧。如果在充分理解敏捷用户故事之前就将其带入迭代,那么团队就会有太多的未决问题,从而无法在迭代内完成。但是,如果试图解决每一个未决问题,并在故事中加入每一个小细节,那么最终的结果会导致功能需要花费太长时间才能呈现给用户。

就像《金发女孩与三只熊》中的故事一样,我们不希望产品待办列表中的项目包含太少或太多的细节,而是希望细节恰到好处。

用户故事的恰当细节水平

为了理解用户故事(或任何产品待办项)的恰当细节水平,可以考虑这么一个例子。

我刚刚下了一个超市配送订单。我的订单中包括五个苹果,我选择的是Honeycrisp苹果,并且准确无误地收到了。

我没有指定苹果的直径必须正好是三英寸,也没有指定苹果要结实、不发霉。

下订单时,我必须提供适当的细节,以确保我得到我想要的东西:苹果的品种和数量。

对于产品负责人来说,在要求团队构建新功能时也是如此。他们需要在适当的时间提供适当的细节,以获得他们想要的产品。

细节不足的问题

如果产品负责人编写的用户故事包含的细节太少,开发团队在制定Sprint计划时就没有足够的信息,无法理解要开发什么功能。这意味着:

  • 团队将在Sprint期间花费宝贵的时间去问问题
  • 团队成员可能会错误地开发某些东西
  • 估算很有可能是不准确的
  • 基于这些估算而对干系人或客户做出的承诺很可能是无法达成的

尽管这些问题可能很严重,但Scrum团队仍然需要小心,不要走极端地通过增加过度的细节来解决这些问题。

细节过多的问题

“用户故事写得过于详细” 一开始听起来可能像一个自相矛盾的说法,你不可能太富有、太瘦,或者在产品待办项上有太多细节。但事实上,在产品待办项中包含过多的细节是完全可能的。

当故事细节过多时,花在添加非必要的细节上的时间和金钱都是一种浪费。如果要求超市配送员一定要找到直径三英寸的苹果,这对我和他来说都是浪费时间,除非在特殊情况下确实需要对苹果的直径有精确要求。

也许比浪费时间和金钱更糟糕的是,开发人员可能会因为过多的细节感觉受到人为约束。假设我向一位超市送货员提出以下要求:

  • 买五个苹果

  • Honeycrisp品种

  • 直径三英寸

  • 结实的

  • 没有淤斑

如果符合所有要求的苹果没有五个该怎么办?是否可以选择一个略大一点的?直径三英寸直径是最重要的吗?我是偏向于选择没有斑块的较大一点的苹果,还是大小刚好但有一个淤斑的苹果?

这些在买苹果的情况下可能看起来微不足道,但在开发产品时就不是这样了。当团队收到用户故事必须满足的冗长需求清单时,即使有更好的方法来开发功能,许多团队也会因为拒绝偏离清单上的任何要求而不予考虑。

迭代式获取用户故事的适当细节

产品待办列表很难一开始就拥有恰到好处的细节,这意味着团队可能需要逐步迭代到适当的细节水平。

我发现当团队从较少的细节开始时,他们更容易找到正确的细节水平。也许可以先在用户故事模板中填写最基本的产品功能和细节。

当团队从过多细节开始时,团队成员可能甚至不会注意到有问题。请记住,细节过多的一个重大问题是,在需要这些细节之前就浪费了时间用来收集。不过,团队成员可能没有注意到这一点,或不认为这是浪费。他们可能只是看到迭代顺利进行,很少有最后一刻的新发现干扰他们,并对这种细节水平感到满意。

然而,如果团队在开始时得到的细节太少,他们就会注意到由此造成的问题。团队成员很难在迭代内完成所有内容,有太多问题需要解决。他们可能感到在所知甚少的情况下被要求对一些工作进行估算。

因为这些都是有明显影响的实际问题,所以团队成员很清楚他们得到的细节太少。解决方法也显而易见:收集更多细节。

通过在启动时产品待办项上的细节不足,团队将能够迅速检视和调整,找到合适的细节水平。

适度的细节是什么样的?

当产品待办项包含适度的细节时,团队成员会觉得在迭代期间恰好勉强能完成待办项。他们会觉得已经提前确定了足够多的细节,但又不会太多,以至于迭代中的创造力被剥夺。

在追求这些感觉的过程中,重要的是不要过早地为产品待办项添加太多细节。

 

用户故事示例

来看一个具体的用户故事示例可以帮助理解。假设团队在开发一个新的应用程序,正在编写的用户故事里说到会员可以登录系统。团队为这个故事确定了各种验收标准,又称为满意条件,规定用户需要满足:
  • 必须提供唯一的电子邮件地址

  • 必须指定强密码

  • 可以通过Facebook帐户登录
从这个用户故事中,我们可以学到几条经验。

经验1:并非所有事情都需要在开始前确定

在着手处理用户故事时,一个有用的小知识是:要意识到团队不需要在开始一个故事之前了解所有的细节。所有未确定的问题都需要在故事完成之前得到解答,但并不需要在故事开始之前得到所有答案。
例如必须提供强密码这个需求,在这句话中提供的细节非常少。
密码必须有多长?是否要包括任何特殊字符?哪些特殊字符?多少个?用户能否将密码改成以前使用过的密码?
编写和测试这个用户故事的团队成员需要知道这些问题的答案,但他们并不需要在着手处理这个用户故事之前就得到所有答案。
答案可以在团队成员开始处理故事之后揭晓。也许这些细节是在开发和测试人员开始这项工作后的一个小时内添加的,他们去找公司的首席安全官,提出一系列问题,并得到了详细的解答。
关键是,“必须指定强密码”这句话在故事首次编写时就足够了。有关强密码的详细信息可以稍后再确定。
(对于某些安全性要求超级高的系统来说,我可能是错的。但是,对于我们大部分人登录的大多数系统来说,我已经准确地描述了情况)。

经验2:过早添加过多细节有害无益

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

在最初编写登录故事时,最好只说明用户可以通过社交媒体登录,而不是可以通过 Facebook 登录。在大多数情况下,没有理由事先确定 Facebook 是用户登录的唯一附加方式。

适度细节的乐趣

学会在产品待办项上包含适当的细节,是团队和产品负责人真正理解什么是敏捷的有力指标。每个人都会意识到,如果试图添加适量的细节,有时难免出现细节过少的情况。这意味着有些产品待办项无法在迭代过程中完成。
但这是可以接受的,因为大家都会理解,要避免这种情况,有时就会引入过多的细节。团队、产品负责人和干系人将意识到,添加过多的细节比偶尔因为细节太少而遗漏一个待办项更糟糕。

你的团队在控制适度的细节方面表现如何?从包含太少或太多细节的故事中你看到了哪些问题?你的团队采取了哪些措施来保持适当的故事细节?欢迎在评论区分享你的经验和观点。

注:部分图片来源于网络

原文地址:How Detailed Should a User Story Be? (mountaingoatsoftware.com)

 

关于作者

【作者】Mike Cohn
Mike是敏捷联盟及Scrum联盟创始人之一,是帮助企业适应和改进敏捷过程及技术,以建立极致高效团队的专家。著有《用户故事与敏捷方法》,《敏捷估算与规划》,《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。

 

关于Scrum中文网

Scrum中文网是全球第一个Scrum中文网站,中国最早的Scrum和敏捷教育及推广机构,也是国际Scrum联盟(ScrumAlliance)官方授权教育机构,大规模敏捷SAFe官方机构SAI中国区金牌授权合作伙伴,和Scrum.org官方授权教育机构。

Scrum中文网是国内领先的敏捷培训及教练咨询机构,作为中国敏捷教练的摇篮,启蒙和培养了数万名敏捷专业人士,帮助数百家知名企业成功转型敏捷。

 

Search
最新敏捷认证课 ~ 火热报名中
4月20-21日
Leading SAFe领导大规模敏捷认证课
Eric & Scott 授课
4月20-21日
专业Scrum Master (PSM I) 认证公开课
丁志润 Derek Ding 授课
5月25-26日
Scrum Master (CSM) 认证课
Lance Zhang 授课
6月22-23日
Scrum Master (CSM) 认证课
Scott Dunn & Eric Liao授课
6月22-23日
专业Scrum产品负责人(PSPO)认证公开课
丁志润 Derek Ding 授课
分类文章
9月15-17日
SAFe ScrumMaster & Leading SAFe官方认证双证班
Eric Liao & Scott Wang 授课
9月18-22日
SAFe认证-SPC SAFe认证培训师导师班
Kurt Jäger & Eric Liao 授课

预约回电

课程顾问将尽快给您回电
电话咨询 400 696 6280