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