用户研究和敏捷是不总是最好的朋友．敏捷开发通常侧重于构建特性，并将工作分解成小块小块的工作。用户研究并不总是与单一功能挂钩，这使得它很难完美地适应两到三周的增量(典型的sprint持续时间)。我们如何将用户研究纳入敏捷框架?
敏捷中的用户研究是一个挑战
通常，在敏捷环境中，用户研究(例如用户访谈那可用性测试,日记研究）以相同的方式接近，其中团队方法建立新功能：通过将其划分为咬合的作品大小，产生有形的东西。
这种类型的思维导致了许多挑战：
- 研究跨越了多个冲刺阶段。团队不可能在一个sprint中完成整个研究，待办事项在几个sprint中仍然是开放的。
- 研究完成后，没有考虑研究结果。团队从用户获得反馈，但反馈不会汇回积压才能完成工作。
- 这项研究没有产生任何有形的人工制品。利益相关者和团队不知道如何处理研究的学习，因为它们习惯于携手完整的设计或代码，即准备生产。
因为所有这些挑战，UX研究经常会结束被忽视的或者在敏捷环境中被完全抛弃。
关注结果，而不是功能
在产品开发中，最大的陷阱之一是专注于输出在结果- 也就是说，在明确定义其目的之前讨论了建立的功能。这种思维方式优先考虑创造闪亮的功能，以了解提供给用户和业务的价值。
例如，Venmo这样的应用可能会决定创建一个功能，向另一个人转账，这样用户就可以不用现金就很容易地支付给别人。输出是要构建的功能:发送钱特性。结果是用户从中得到什么——另一种付费方式。为了理解我们正在解决的问题并弄清楚结果是什么，我们需要做用户研究。
敏捷的主要价值之一是回应变革在计划之后。团队应该专注于持续发现 - 即在整个项目中持续学习。研究应该是这种持续发现背后的驱动力，并在整个项目中都应该在进行中。许多团队将研究视为为期6周的项目或一个开发前的发现阶段随着项目的继续，再也不要做研究了。但如果他们有这个目标，就会在打造以用户为中心的产品方面取得更大的成功一些研究每个Sprint。这样他们总是在学习和改进他们的项目目标。
代表对待办事项的研究
就像设计和开发工作一样，我们需要代表了对我们敏捷backlog的研究成果．当研究工作没有反映在积压中，它们就会被忽视，不可避免地被忽略——眼不见，心不烦。
要记录对待办事项的研究，请遵循以下步骤:
- 将研究工作作为一个单独的待定项添加到待定项中用户故事．
- 将研究分解成小块，并在研究待办事项中添加相应的任务。
- 在完成任务时，将它们标记为在将研究积压项目打开的情况下，直到所有任务已完成。
让我们来看看一个例子。
示例：具有6名参与者的可用性测试
对于此示例，想象一下，您希望使用6名参与者进行可用性测试，以了解用户（或不）如何在应用程序中使用键盘快捷键。
为了完成这项研究，您需要完成以下任务:
- 招募和安排每个参与者
- 进行会话
- 分析数据
- 向利益相关者展示调查结果
对于每个参与者，您将添加到对应于招聘，调度和进行会话的对应的Backlog单独任务。然后，您可以为数据分析添加一个或多个任务，并向您的利益相关者展示调查结果。有些团队开始在数据收集中途的模式中寻找模式，因此他们可能会分析数据并在这项研究工作期间提出一些初始调查结果。
重要的是接受和交流这项研究的努力将在多个sprint中保持开放．对于一些利益相关者来说，这个想法很难理解，所以要提醒他们，研究工作交付的是结果，而不是产出——也就是说，它们交付的是目标和需求，而不是特性。问问自己是否离目标更近了。如果是，那么你正在学习——这是一件好事!在sprint回顾中，你可以谈论研究进展如何，到目前为止你可能听到过令人难忘的引语，以及接下来会发生什么。这种方法将强化这样一种想法，即研究一直在进行，并将继续建立买入。
中点也是让涉众参与过程的绝佳机会!现在他们已经看到了一些早期的反馈，他们可能想要参与研究的后半部分——这是第一步制作研究团队运动．如果您的学习迅速，您不需要中途核对，但您对过程的透明越透明，您的团队和利益相关者越有可能理解它为项目带来的价值。
一旦这个待定项中的所有任务都完成了，这项研究工作就被认为完成了，可以结束了。
根据研究结果更新待办事项
研究完成后，您可能会得到一个bug修复列表，用户体验的债务，潜在的新特性，以及未来研究的机会。这些都应该集中到你的待办事项列表中——可以是现有待办事项列表项上的任务，也可以是需要修复的bug，或者是新的待办事项列表项。
在sprint回顾中展示完你的研究成果之后，把这些项目列出来，这样就可以对它们进行优先排序，并立即添加到待办事项列表中。由于您的涉众已经出席了sprint评审，您将不需要要求他们参加另一个会议。
不管如何您添加了将您的研究结果纳入积压，确保您正当行事。一个不解决所接收的反馈的团队只是发现新信息，而不是响应变更。
沟通敏捷研究的学习
敏捷团队知道很多但研究和持续学习应该同样重要。为了克服在敏捷中进行用户研究的挑战，请记住:
- 研究工作可能会跨越多个冲刺阶段。您将重点关注可能影响多个功能的用户目标，因此在Sprint评论期间，对研究如何移动该团队，对该团队进行透明。经常沟通随着研究的完成，将建立买入和共同点．
- 将研究结果反馈到backlog中。对于在敏捷环境中构建可行的软件来说，持续发现并响应变化是很重要的。确保团队不仅要听取用户的意见，还要回应他们的需求。
- 研究以学习的形式而不是有形的工件的形式为团队提供价值。您的研究中的了解将通知即将到来的功能，建立要求和验收标准，并帮助您了解您的用户。这些都是将团队前进并提供价值的所有事情。
参考
Josh Seiden。2019。结果胜于产出:为什么顾客行为是企业成功的关键度量标准。理智与回应出版社，美国。
分享这篇文章: