Scrum敏捷项目管理

记录用户故事

用户故事是记录敏捷世界中用户需求的主要格式之一。但是,在开始冲刺之前,Scrum团队应该就可用的信息量进行辩论。在本文中,ZuziŠochová建议尽量减少用户故事的大小,并定义简单的满足条件,而不是编写接受标准。

作者: Zuzana“ Zuzi”Šochová, http://sochova.cz/

用户故事 是记录产品待办事项的最常用格式之一。它具有特定的格式,迫使人们专注于业务价值。

作为[用户|角色|角色]
我想获得[功能]
这样我就可以得到[业务价值]

作为我的在线啤酒商店“ Berrer”的用户故事的示例,我们可以编写以下内容:

作为乔恩(忙碌的经理,没有时间)
我想让“啤酒”选择啤酒
这样我就可以通过各种稀有品牌打动我的朋友。

它将为我们提供三种不同的信息-谁,什么以及为什么-这些信息必须融合在一起,一旦您向某人阅读,它就会一起创造一致的故事。您可能已经注意到,用户故事从业务角度看待功能,并且以客户为中心(请注意,客户都是用户,利益相关者,其他团队……)。我们从不定义解决方案的精确程度,而仅描述我们想要实现的业务影响。

编写验收标准绝不是好主意

有了这个定义,公司经常会错过编写确切规范的地方。但是没有。都是关于对话。它应该适合小索引卡。话虽如此,团队仍在努力,并设法使其尽可能接近传统的详细规范。添加细节作为接受标准是实现此目标的一种方法。它们通常是您应该/不会实施的所有可能细节的清单。对于对业务和产品了解有限的团队来说,这似乎很有用,但事实并非如此。为了给您提供上述用户案例的此类接受标准的示例,它们看起来可能像这样:

*来自各大洲的啤酒
*至少一种比利时啤酒
*几家当地小型啤酒厂
*一盏浅色,深色,淡啤酒,啤酒

根据这些标准,开发团队不再参与故事的定义。他们只是将这些观点一一加以落实。如果由于我们错过了某些东西而无法正常工作,那不是他们的错,但是他们会责怪他们。他应将缺失的部分作为验收标准的一部分。因此,让我们来看看更好的解决方案。

将用户故事牢记在心:对话

定义满足条件

如前所述,用户故事是关于进行对话的。它应该简单,清晰并且易于记忆。如果写得好到足够小,则不需要在卡的背面添加任何其他信息。但是有时您可能会发现强调某些预期的行为或影响很有用。在这种情况下,我们会翻阅用户故事卡并写出满意的条件。对于上面定义的故事,它们可能是:

乔恩(Jon)可以从世界各地的微型啤酒厂中选择各种不同口味的啤酒来打动他的朋友。

结果,该团队现在专注于解决用户问题,而不是实现以前定义的内容。实现通常从对话开始。我们如何才能以更少的努力实现更多价值?我们必须提供的最低功能是什么?我们如何解决他的需求?我们需要每个人都参与,每个人都感兴趣,每个人都应了解整体业务,角色,他们的需求和梦想。

开始时可能会花费一些时间,但是值得投入精力,因为依赖产品生存的忠诚团队始终可以提供比a更好的解决方案。

写作 验收标准 是传统软件开发界的遗产,同时定义满足条件非常敏捷。敏捷和Scrum是一种心态。如果有的话,写用户故事就没关系,因为您已经了解了根本的区别。它是关于要交付给客户的价值,而不是工作量,项目交付或速度。如果您没有这种想法,仅更改标签将无济于事。您将必须大大改变您对积压项目的思考方式。这可能是一个非常痛苦且漫长的过程,在此过程中满足条件的用户故事格式将有所帮助。在敏捷培训期间,我与几家公司一起经历了这一变化,这总是值得的。如果您想多练习一点,我也在 CSPO(Scrum认证产品负责人) 类。

关于作者

Zuzana“ Zuzi”Šochová是一名独立的敏捷教练和培训师,并且是一位经过认证的Scrum培训师,在IT行业拥有超过15年的经验。她于2005年在美国实施敏捷方法时开始从事Agile和Scrum的工作。从那时起,她在全球许多公司和团队的敏捷转型和实施方面享有盛誉。通过建立和维持敏捷的领导力,祖兹相信工作和生活的世界可以变得更加幸福和成功。本文最初发表于 http://agile-scrum.com/index.php/2016/11/02/user-story-as-a-card/ 并经ZuzanaŠochová的许可在此处复制。