编写用户故事的协作工具
许多软件团队将期望的产品功能描述为产品backlog:用户描述的列表。这些故事描述了谁需要这项工作，这项工作是什么，以及为什么需要它。团队经常期望产品负责人是待办事项安排的唯一来源，但任何人都可以(也应该)编写用户故事。产品Backlog构建画布通过提供一个开发用户故事的简单过程来支持这一点，从描述产品用户的角色和他们所做的活动开始。这些活动产生了特性:它们与产品的交互。特性被分解为待办事项项，然后可以从角色和活动的背景中制定到用户故事中。
2022年6月14日
保罗结论:(是一个专家的初始化促进者Thoughtworks总部位于西班牙马德里。20多年来，他一直在帮助巴西、印度、美国、拉丁美洲和欧洲的企业通过数字产品取得成功。2000年，他接触了Extreme Programming，从那时起，他开始专注于敏捷和精益的过程和实践。除了产品待办事项列表构建而且精益《盗梦空间》，他也是有趣的回顾:使敏捷回顾更吸引人的活动和想法。
Kent Beck介绍了用户故事这个术语极限编程培养一种更加敏捷和对话的需求收集风格。几年后，Mike Cohn出版了他的《应用用户故事:用于敏捷软件开发》(2003)一书，该书被认为是关于该主题的重要参考文献之一。华体会登录网址
最初，敏捷团队中的任何人都习惯于编写用户故事来沟通要完成的工作。然而，随着时间的推移，很大程度上是受扩张的驱动Scrum框架产品负责人成为编写这些故事并将它们组织到产品backlog中的主要人员。然而，任何人都可以(也应该)编写用户故事。法比奥•阿吉亚尔我写了一本关于产品待办事项建立技术帮助团队中的每个人编写优秀的用户故事。
在介绍PBB画布之前，了解一个好的用户故事是如何形成的是很有用的。我会介绍各种常用的启发式。
用户故事是对需求进行简明描述的一种文本格式，它试图回答三个来自缩写为3Ws的特定问题:谁?什么?,为什么?
在书中极限编程探索， William C. Wake分享了首字母缩写INVEST，其中每个字母代表用户故事的六个重要特征之一:
几年之后，迈克·科恩(Mike Cohn)最终把字母S从小改到了合适的大小，因为有些人把故事写得大一点，但又适合他们的背景。
名片:用户故事描述必须放在索引卡上，包含足够的内容来识别用户故事。最常见的格式是:
作为一个«角色/概要»
我想«行动/活动»
这«/原因»中获益
下面是一个例子:
”作为一个参与者,我想注册一个事件这我可以参加。”
谈话:用户故事描述应该适合索引卡。主要原因是没有太多的写作空间，这迫使书面描述必须简短。因此，需要进行大量的对话来澄清疑问，并详细说明执行它所需的工作。使用用户故事意味着接受关于工作的对话将是持续进行的，而不仅仅是在需求最初设定时放在开头。最好的文档帮助人们记住对话，而不是取代它们。
确认:这是确定用户故事目标是否实现的地方。要做到这一点，接受标准确认用户场景已经正确实现并成功交付。在团队开始实现每个故事之前，必须为它定义接受标准。这样，在检查完成和验证结果时就不会出现意外。
这本书更详细地介绍了建立产品积压的过程，包括一个构建产品待办事项列表构建画布的逐步指南．
如前所述，编写用户故事基本上回答了三个主要问题:谁?什么?为什么?
“谁?”指的是角色。“什么?”指的是构建这个人需要的动作或活动的工作项;“为什么?”说明了使用它的好处。
在PBB的书中，Fábio和我分享了通过PBB画布逐步识别角色、功能和工作项以构建优秀用户故事的方法。在本文中，我将分享如何填充画布并为数字产品示例编写用户故事。它是关于“演讲集合”(Talks Collection)的，这是一个由区域性敏捷社区创建的数字产品，用于准备一系列演讲和组织活动。
图1:PBB画布
接下来描述整理PBB画布的Persona、Features和Product Backlog Items块的三个步骤。我使用了一些Talks Collection示例人物角色和特性来说明它。
人物角色代表产品的用户，因此描述不仅应该谈到这个人的角色，还应该谈到他们的需求和目标。这创建了用户的真实表现，帮助团队从谁将使用该产品的角度描述功能。
从以下问题描述主要角色:“这个人的简介是什么?”这个人是做什么的?这个人想要什么?”
图2:角色块示例
目前，发现工作坊相对普遍，这个硕果，以及生成关于角色的工件和知识的其他活动——例如移情地图．如果是这种情况，分享之前构建的材料。但是请记住，在PBB的时候，重点是人物角色及其活动的概况，这是下一步的必要点。
在对角色及其活动有了很好的理解之后，是时候分析它们中的每一个，重新阅读它们，并寻找角色与产品的动作或交互，这样您就可以将每个交互表示为一个功能。
图3:从角色到功能
通过回答以下问题来描述功能:用户试图做某事，所以产品必须有相应的功能。它是什么?这个特性解决了什么角色问题?它给角色带来了什么好处?
图4:特性块示例
把功能描述写在一张大的便利贴上，然后把挑战和好处写在小的便利贴上，放在便利贴上的旁边，描述功能。
特性通常在比出现在开发计划中的工作项更高的级别上进行描述。在开始开发一个特性之前，必须对它进行分析，必须对它的工作项进行描述和量化。在PBB Canvas中，您首先识别、理解特性并确定其优先级，然后在产品待办事项列表项中详细描述它们。
产品待办事项列表项(pbi)是组成产品待办事项列表的元素。它们反映了改进产品和满足客户或涉众需求所需的开发工作。在前面的步骤中，您描述了这些特性及其挑战和好处。现在我们有必要进一步分解这些内容，以便创造更小、更准确的内容。这些被称为pbi。
为了识别产品待办事项列表中各自的PBIs，请参与者回答以下问题:“这个特性的第一个工作项(或步骤)是什么?”和第二个?下一个呢?”
图5:产品待办事项项块示例
每个PBI必须代表用户对产品执行的一个操作。例如:1)“买一本书”和2)“为会议增加一位演讲者”。这些操作以文本形式进行描述，以提供上下文并唯一标识项目。
产品待办事项列表项构成了用户描述列表的基础。您使用每个PBI并使用角色和特性来充实典型的用户故事模板。下图显示了这方面的一个例子。
图6:使用PBB编写用户故事
所以最后的故事是这样的:
作为一个演讲者
我想完成作品的出版
这我可以提供内容
在编写了用户故事的核心元素之后，是时候用关于验收标准、任务、用户界面和支持因素(如果有的话)的额外信息填充它了。您可以在PBB画布的Product Backlog Items区域中完成它，或者开始在您的首选工具上记录用户故事。
以下是关于Talks Collection数字产品的三个功能的详细描述，包括一些用户故事、验收标准、任务和界面:
下面是三个示例特性及其各自的角色和用户故事。
角色:演讲者
特点1:发表谈话
角色:参与者
功能2:参加一个活动
角色:组织者
功能3:组织活动
这个简单的模板是用户故事的核心，但是还有许多其他的元素值得记录下来。虽然PBB Canvas对这些进一步的细节没有帮助，但在这里描述它们是有用的。您可以将这些添加到画布中的pbi中，或者使用其他工具进行故事跟踪。
接受标准旨在描述如何验证用户故事。在这样做的过程中，验收标准提供了一个清单，它决定了用户故事何时完成、完成和工作。下面是《产品待办事项列表构建》一书中的一个用户故事示例:
“作为一个账户持有人，我想在自动取款机上取钱，以避免银行排队”。
以下是该上下文的一个可能的接受标准:
所呈现的格式与用于验证故事是否完整和有效的检查表相比较，也就是说，它是否通过了所有的接受标准。
通过声明“这些是任务”，将用户故事分解为关于必须完成的工作的更小的部分是非常常见的。通过列出构建故事所需的任务，开发团队将深入了解如何实现小片段的技术细节。与故事不同，任务不遵循已定义的文本格式。从开发团队到开发团队，它们更直接，使用非常技术的语言。
任务确定需要做的事情，一个故事所必需的事情。因此，任务不一定是自包含的，也不会显示业务价值。他们中的大多数倾向于为程序员，用他们使用的术语来描述。任务的一些例子是，更改输入表字段，为用户创建测试帐户，以及自动化数据生成脚本。
不是每个工作项都与接口相关联。但是对于将与某些用户界面(或UI)相关联的项目，您需要在用户故事的上下文中阐明这种关联。
一个界面可以用几种方式来描述:草图(或在纸上的简单图画)、线框、模型或原型。描述它的方法因团队而异，取决于团队文化和详细描述它所花费的时间。
这时出现的一个问题是，需要定义多少接口才能开始处理故事?答案基本上是团队同意从UI的角度来决定故事是否已经准备好。最重要的是团队要团结一致，对要做的工作感到满意。
有时候，写一个特定的故事是很困难的。尽管您尝试使用INVEST和3Ws技术作为指导，但在某些情况下，您仍然不能令人满意地编写它。如果发生这种情况，试着看看你是否正在处理以下两种情况之一:
在这两种情况下，你可以创造一个更大的故事并将其视为其中的一部分，或者你可以将其分解为一些单独的内容:一个推动者．这种“分离的东西”被称为使能者，因为它不符合故事格式。它是启用另一个故事所需的工作项。
“作为一名开发人员，我想研究异步消息传递是如何工作的，以便决定如何实现聊天。”这不是一个故事，也不需要这样描述。这是一种探索性的使能器，需要在用户故事(例如:“作为一名参与者，我想在事件聊天中发送消息以与其他参与者交互”)之前使用。
此示例演示了在处理故事之前需要使用探索性使能器—“研究异步消息传递是如何工作的”。探索性使能者执行研究、背景活动、澄清和/或在选项之间进行选择，以实现故事的有效工作。
斯派克是探索性使能器的常见同义词。
非功能性需求、重构、管道或测试基础设施改进——这些是活动的华体会app下载二维码一些例子，有时需要花费太多的精力来考虑作为用户故事的一部分。在这些情况下，您可以将它们描述为技术使能器。您还必须指出哪些故事依赖于它们。但是，要非常小心，不要做得太过了，最后只会产生一个启用程序积压。
没有必要以User Story格式编写技术支持。与其使用“作为开发人员，我想迁移自动化测试套件以提高性能”，不如使用更直接的文本格式，例如:“执行自动化测试迁移”。
现在，看看一个故事的例子，“发表谈话”功能的谈话集合。它提供了一个完整的用户故事示例，包括接受标准、任务、Ui和启用器。
1.1用户故事
作为一个演讲者，我想要连接外部的演示，以整合演讲。
验收标准1
场景1:跨演示文稿共享平台链接演示文稿
假设在SlideShare平台上有一个有效的链接
当我关联外部演示链接时
然后它将在屏幕上显示演示的预览
验收标准2
场景2:在发表演讲时联系演示
假设演示链接是有效的
当我发表演讲的时候
然后它将在发表的演讲细节中显示相关的演示
任务:
界面示意图
探索性的推动者:
研究与在线演示文稿共享平台(SlideShare和Speaker Deck)的端点API集成。技术因素:
使用oEmbed端点作为头中的链接标记，以便在嵌入表示时自动检测它。准备(DoR)的定义是团队之间的协议，表明PBI何时准备好被拉入Sprint，也就是说，当它有足够的信息进入计划、执行和交付时。人们经常说，“这个项目已经准备好开始工作了”，通常这表明团队:
对于下一个Sprint(或工作迭代)的每个PBI候选人，团队检查PBI准备清单:
这个列表是DoR清单的一个例子。通常，团队定义并维护他们的检查列表，这显示了他们在准备工作中的偏好。
产品待办事项列表的改进必须是持续的。团队将持续地工作在下一个候选项目上，为下一个Sprint或工作交互做好准备。现成定义和已完成定义的使用不仅仅局限于Scrum;在使用它时，这也是一个非常有用的实践看板以及其他敏捷方法。
完成的定义(DoD)是一份协议，它证明了PBI的质量，其中“完成”确认了每个人对完成的工作的满意。
国防部澄清了作为产品增量一部分的已完成工作的理解。一旦PBI满足完成的定义，就意味着增量已经准备好释放到产品中。
如果一个PBI不符合国防部的要求，它就不应该被发布，甚至不应该出现在Sprint评审中。对于团队来说，它必须是一个正在进行的工作(WIP)。
对于每个被认为已经完成的PBI，团队演示了以下项目:
这个清单是国防部的一个清单示例。团队定义并维护检查列表，以演示他们在工作验证中的偏好。
您可以从产品待办事项列表构建中下载这些示例DoR和DoD检查列表作为额外资源在这里．
本文中分享的大部分内容来自于从书关于使用产品待办事项列表构建画布以及如何编写有用的用户故事，你可以阅读更多的深度。我有一篇文章在Scrum的背景下描述了这种方法。我为合作计划和运行项目写了更多的主题我的博客．
2022年6月14日:发表