从传统的产品开发过程(如瀑布式开发)到现代敏捷框架(如Scrum)的转变可能是一个巨大的挑战挑战用户体验. 我们必须学习一套全新的术语,适应完成研究或设计工作的新时间框架,走出我们的舒适区,与跨职能合作伙伴合作,其中许多人我们以前从未合作过。一旦我们开始做这些改变,我们很快就会意识到敏捷不仅仅是在时间限制的冲刺中工作。

与瀑布不同,Scrum有许多经常性的会议,通常被称为仪式,包括每日站立会议(也称为每日Scrum),积压优化(也称为积压整理),短跑计划,演示,回顾. 作为用户体验人迁移到敏捷,他们可能想知道是否需要参加每个仪式,以及应该做什么来充分准备和参与。在本文中,我将概述UX在每次Scrum仪式上应该做些什么,以保持开放的沟通,影响产品的成功,并为团队做出有成效的贡献。本文的大部分讨论将集中在Scrum敏捷框架上,但许多概念也可以应用于其他敏捷方法。

UX应出席并参与仪式

敏捷团队中的用户体验参与这不仅仅意味着向前冲刺,快速、持续地向产品所有者、利益相关者和开发人员交付想法。这也意味着在当前的sprint中,在所有的会议和仪式上,成为一名在场的积极参与者。简单地说,在敏捷环境中工作的用户体验专业人员不应该跳过Scrum仪式,也不应该在这些仪式期间置身事外。

当我们决定跳过或不完全参与仪式时,我们可能会忽视:

  • 大局、我们的产品愿景和预期结果
  • 我们为用户解决的问题
  • 与我们的团队有共同的目标和目标
  • 实施可行性和实用性与发展
  • 开发人员如何在代码中转换我们的设计意图
  • 在即将到来的冲刺中优先考虑什么
  • 哪里需要发现或额外的sprint 0工作
  • 以用户为中心的证据揭穿基于意见的设计的机会
  • 邀请团队参与的机会看到研究或参与研讨会
  • 用户体验可以改进产品的领域
  • 用户故事需要更多具体的UX细节
  • 我们可能需要通过测试支持QA

不参加典礼,我们还对团队内部关系和沟通施加了不必要的压力. 不要强迫你的队友在仪式后告诉你讨论的内容,以此来挫败你的队友。许多人不会从繁忙的日程中抽出时间来赶上你,所以以积极的态度参加仪式,以避免误解和减少关系。

如果你发现自己过于分散,无法参加仪式,那么你很可能试图在给定的冲刺中做得太多。重新调整工作负载的优先级,以支持当前sprint中需要完成的工作,从而确保开发人员拥有下一个sprint所需的工作。以这种方式改变你的心态应该会让你有时间参加仪式。随着时间的推移,当您练习平衡完成工作的时间和花在会议上的时间时,您将能够将更多的活动重新添加到sprint工作负载中。敏捷就是要对变化做出反应,所以这是很重要的,检查自己,并确保你没有做得太多,以至于你无法参加仪式。

如果在所有这些之后,您仍然无法参加仪式,请与您的经理、产品负责人和Scrum主管讨论您的工作量,以相应地调整您的时间。你的队友应该是你的盟友,并且理解为什么你的出席和参与在这些重要事件中至关重要。如果他们没有,教育他们关于为什么在Scrum仪式中将用户体验表示为用户的声音对团队和产品来说是富有成效的。如果没有这种声音,团队就有可能引入用户体验的债务不得不删除、重新设计或重构那些没有考虑到最终用户的特性。

如果你不专注于一个产品团队呢?

当用户体验支持单个产品团队时,参加仪式更容易,但当用户体验必须支持多个开发团队时,相互冲突的日程安排可能会使用户体验难以参加每一个仪式。尽你最大的努力去参加所有的Scrum仪式,尤其是当你的项目从发现到交付的时候。

你在典礼上的表现应该是积极的和参与性的,而不是简单地说你做到了。确保你的出席为谈话增添了一些有价值的东西,无论你是否带来从你的研究中获得的见解或者利用你的演讲时间积极的与开发人员联系谁在写你设计的故事,看看他们是否需要澄清。如果您有相互冲突的会议或相互竞争的工作负载优先级,请依靠您的产品负责人或Scrum主管让您了解团队在错过的仪式上讨论的内容。

例如,如果一个团队每天的日常工作发生在上午,但是你同时为另一个团队提供冲刺计划,而另一个团队则在发布一个重要的发布时,支持Sprint计划会议,但是在了解UX可以帮助解决的另一个团队中的任何拦截器之后,与你的产品所有者或Scrum Master进行检查。在这些情况下,用户体验必须分而治之,对于UX人员来说,依靠团队成员尽可能地了解和参与是完全可以接受的。

在直接冲突和资源限制中确定优先次序

当由于时间冲突或资源限制无法参加所有仪式时,找出哪些会议对用户体验不重要,并偶尔跳过它们。问自己以下5个问题,以帮助优先考虑与Scrum仪式的直接冲突,并管理无法始终参加所有团队的所有会议的现实。

  • 我缺席仪式是否会阻碍或延迟开发团队实现sprint目标?
    • 如果是,请参加相关仪式
    • 如果没有,你可以把时间花在其他地方
  • 我是否有重要信息要与团队分享,这些信息可能会对我们的产品和最终用户的体验产生重大影响?
    • 如果是,请参加相关仪式
    • 如果不是,你可以把时间花在其他地方
  • 仪式中是否有其他人可以代表用户体验并在之后向我提供最新信息?
    • 如果是的话,把时间花在别处是可以接受的
    • 如果没有,请参加有关仪式
  • 我是否有足够的时间与开发人员合作,以确信他们理解我的设计意图和用户研究的证据?
    • 如果是的话,把时间花在别处是可以接受的
    • 如果没有,请参加有关仪式
  • 在过去的2次冲刺中,我是否错过了3次以上的颁奖典礼?
    • 如果是,请参加相关仪式
    • 如果不是,你可以把时间花在其他地方
问问自己这些问题,以决定是否应该参加scrum仪式。
当用户体验变得过于分散时,使用此决策树来确定您是应该参加Scrum仪式,还是应该跳过它而选择其他关键活动。

UX应该在每个Scrum仪式中做什么

站立会议(每日例会)

大多数Scrum团队都有一个日常会议,称为站立会议或日常Scrum。(Scrum既是敏捷框架的名称,也是许多敏捷团队日常活动的名称。)会议的时间非常短,通常不超过15分钟,重点是与团队沟通,以确保工作按计划进行,任何障碍都可以共享并迅速解决。团队的每个成员,包括用户体验,都站着鼓励对以下每个问题做出简洁的回答:

  • 你昨天做了什么?
    • 讨论你所从事的设计领域
    • 概述发生的任何与跨职能伙伴的协作
    • 讨论你计划、实施或分析的任何研究
    • 在相关情况下,与团队分享简单的研究结果或用户见解
  • 你今天要做什么?
    • 让团队知道你当天计划做什么,包括设计、用户研究、设计评审、研讨会、设计冲刺
    • 提及您希望从工程或产品部门获得投入的领域
    • 提出协作的方法,如结构化草图或白板会议
    • 邀请团队成员参加当天进行的可用性测试和其他研究
    • 通过向你的团队宣布、承诺和确认你正在做的事情,让自己对完成工作负责
  • 你怎么了?
    • 提出任何阻碍你完成工作的内部或外部因素
    • 依靠你的Scrum master来帮助你消除这些阻碍进步的障碍
    • 如果你需要与团队成员进行具体的讨论,建议在站立会后召开一个快速的周转会议

用户体验通常比工程团队提前一个或多个冲刺阶段,保持团队一致已经是一项挑战。正是因为这个原因,参加每日的站立会议,清晰、简洁地交流用户体验的工作是如此重要。此外,用户体验应在站立时听取其他队友的意见,以了解用户体验能够解决或帮助解决的任何潜在障碍或问题。

积压优化

待办事项细化(有时也称为待办事项梳理)通常发生在当前sprint的中途。这个仪式的目的是检查待办事项列表中的项目,以确保它们为即将到来的sprint计划会议(以及最终的sprint)做好了准备。

在本次会议中,产品负责人将审查其当前产品中的待办事项优先顺序并调整优先级以满足业务和用户需求。产品负责人将领导与团队的讨论,以了解是否需要其他故事,或者是否需要编辑或删除现有故事。在某些情况下,团队将一起重写或添加故事细节,以确保涵盖所有内容。

让用户体验专业人士参加本次会议,以促进白板草图或其他思维技巧可以帮助团队一起解决问题。对于团队在sprint中需要做额外发现工作以获得开放问题的答案的项目,也可以将峰值添加到待办事项列表中。

当待办事项达到可接受的详细程度和上下文时,它们还必须符合团队对待办事项的定义,这一点很重要准备好冲刺了吗.这一需求保护了团队,使他们免于获得缺乏进行生产性工作所需信息的sprint票据,从而不得不花费原本应该是工作时间的时间来理解首先应该做什么。的的定义准备好了对于每个待定项,团队通常会有所不同,但如果结果是面向用户的,则应该通过以下UX标准:

  • 用户故事和验收标准在票证中明确阐述
  • 可用的可视化和轻量级文档
  • 解决方案已通过用户测试,没有出现严重问题
  • 设计遵循风格指南、模式库或设计系统
  • 这个项目已经被用户体验、开发和产品所有者审查过了

UX参与待办事项整理可以为开发团队在下一个sprint中的工作带来远见,并为产品所有者提供额外的支持。虽然产品所有者应该像用户体验一样了解用户需求和业务机会,但他们有许多责任需要处理(例如,工程团队的实现现实,业务涉众的战略目标,团队的核心性能指标),所以有时候你的产品负责人可能需要来自用户体验的额外帮助和责任。UX应该有助于确保产品所有者在选择下一个待定项时为用户和产品做出正确的决定。

Sprint计划

冲刺计划通常发生在冲刺的第一天,或者有时提前一天。sprint计划的目标是再次检查优先待办事项,并估计完成这些待办事项所需的工作量。与细化非常相似,产品负责人领导这场讨论,在审核每一张票的同时,从团队中寻求关键的意见。最终,sprint计划的结果是反映团队速度的sprint backlog——团队在sprint中轻松完成的工作量。Sprint planning也是团队设定一个现实的Sprint目标,这是一个简短的、一句或两句话的描述,描述团队在Sprint期间计划实现的目标。sprint目标是团队未来几周的愿景。

用户体验参与到sprint计划中是很重要的,因为就像开发工作一样,用户体验工作也应该如此在积压工作中有所说明,或者使用与工程部门共享史诗的单独UX票据,或者作为相同票据的一部分,将UX工作组织到父用户故事的子任务中。在评估你的用户体验工作时,使用t恤衫尺寸,而不是故事点。如果您的scrum团队只在工程工作中使用velocity,这是很常见的。如果用户体验工作包含在团队的速度中,请使用与工程团队相同的方法参与估算故事点。

在敏捷中,使用t恤衫尺寸来评估用户体验工作。
在不影响工程团队速度的情况下,使用t恤衫尺寸而不是故事点是估算项目所需用户体验工作的好方法。大小为S的项目只需要很少的用户体验工作,而大小为L的项目需要很多(实际上可能会占用sprint期间的所有用户体验资源)。跟踪用户体验工作负载对于确保用户体验在冲刺过程中不会承担太多任务非常重要,因此在未来的冲刺过程中会给开发团队带来阻碍的风险。

不管所使用的票证结构如何,UX工作都需要对开发团队的其他成员可见,以确保不会跳过研究和设计任务。参与sprint计划有助于保持团队的一致性,并了解用户体验在sprint期间将做什么。这种方法可以帮助工程团队和产品团队成员认识到设计和研究过程的严格性;不断地看到和听到每个项目所需的用户体验工作,将有助于水泥在以后购买新的方法和变更建议。

确保在sprint规划中考虑用户测试这样团队就知道会发生什么,并有机会参加会议或汇报。对于更大的研究计划或研讨会,如设计冲刺,这是很重要的整个团队都要参与进来,建议将sprint的速度稍微降低一点,这样工程师就有时间参加研究,而不会觉得在研究过程中必须同时完成多项任务才能实现sprint目标。

我们也建议你对待参与者招募作为估计工作量的重要组成部分。编写筛选程序和招募用户通常需要很长时间,因此,当你需要可用性数据时,你越有系统地进行招募,就越容易进行研究。招聘需要计划,你希望避免它成为招聘过程中的瓶颈。维护潜在用户列表,尽可能添加到其中。试着挖掘你当前的客户群,投放广告,与市场研究公司合作,或者在表格或调查中加入额外的问题,以建立你的研究参与者库。

在sprint计划结束时,团队应该有他们的工作负载,以便进行sprint。但是,请记住在sprint计划中讨论的用户故事是为了与您的工程师进行进一步的对话和协作。不要只是把设计附加到用户故事上,然后把它们扔到墙上,然后抱着最好的希望;在当前的冲刺过程中,与您的团队保持联系,并随时接受提问或讨论。

Sprint回顾(演示)

Sprint回顾(通常称为演示)通常发生在Sprint的第二天到最后一天。在许多情况下,如果团队在sprint结束时启动,这个仪式将在代码发布的前一天举行。在这次会议上,产品负责人将向涉众和其他可能受到团队在sprint中完成的工作影响的人展示工作代码。sprint评审是UX支持产品负责人展示已完成工作的好机会。这也是一个很好的论坛检查测试结果插入以用户为中心的见解通知当前版本或将对产品的下一次迭代产生积极影响。

有时候,用户体验可能会因为新特性请求的数量或收到的不太理想的反馈而让sprint演示感到不知所措。当这种情况发生时,用一种有组织的方式记录反馈,比如用诸如待办事项,澄清,劝说. 与您的产品负责人和scrum主管合作,帮助导航反馈,并优先考虑演示中产生的新需求。您的团队可能需要在sprint期间尽早、频繁地与某些跨职能合作伙伴举行会议,以避免出现意外情况或使期望落空。

回顾

冲刺后回顾通常发生在冲刺的最后一天,旨在让团队回顾事情的进展。理想情况下,一个中立的代表,例如来自另一个团队的Scrum主管,或者来自组织另一部分的项目经理,将进行回顾,以保持对话流畅、公正。每个团队成员将讨论在sprint中哪些进展顺利,哪些存在问题,以及可以采取哪些不同的措施来提高Scrum团队的效率。

回顾是UX谈论流程变化的好时机;因为会议的主题是反思团队的流程,所以人们会更容易接受建议。在以开发人员为中心的环境中,很难提倡过程改进,这将提高交付UX工作的能力,因此考虑将您的想法定位为在下一次冲刺期间进行测试的实验。

回顾也是讨论以下问题的适当时机:

  • 当你没有足够的背景信息或研究时间去设计某样东西时
  • 实现错误或沟通错误,开发人员没有按照您的预期实现您的设计
  • 关于你的工作的问题可交付成果“完成”的定义你提供的设计
  • 传达设计规范的方式:是否存在问题、混乱或不够具体
  • 让产品、工程和业务涉众观察可用性测试会议

除了分享为什么过去的sprint可以做得更好之外,还可以倾听改进与团队其他成员沟通方式的方法。您的设计规范容易理解吗?您是否用与当前sprint无关的用户数据压倒了您的团队?您的设计解决方案在使用现有体系结构或框架实施时是否具有挑战性?关注你是否在帮助团队其他成员解决他们自己的特殊问题,因为这就是为什么用户体验可以被视为真正的资产,而不是瓶颈。

回顾也是提出用户观点的好时机。通常情况下,团队必须做出权衡在sprint过程中,用户体验可能会被忽略,而倾向于将工作交付,因此,如果最近完成的任何用户故事包含用户体验的债务或者从用户体验的角度进行妥协。

如果您的团队没有进行回顾,那么您的流程就不是敏捷的。每个团队都应该找到自己的方法,但只有当团队发现什么有效,什么无效时,方法的真正价值才会实现。因为在敏捷团队的生活中有太多的回顾,有可能最终会听取一些与用户体验相关的建议。一个很好的经验法则是,团队的实施速度不应超过其所能学到的速度。

结论

UX专业人士很容易质疑他们是否应该参加Scrum仪式,有时候,UX甚至认为这些会议是生产力的障碍。然而,用户体验应该参与到Scrum仪式中,以保持参与并了解团队正在发生的事情。想了解更多关于在Scrum仪式中平衡UX工作量和责任的信息,请花一整天的时间精益与敏捷课程