从传统的产品开发过程(如瀑布式)到现代敏捷框架(如Scrum)的转变可能是一个困难挑战用户体验．我们必须学习一套全新的术语，适应新的时间框架来完成我们的研究或设计工作，并走出我们的舒适区，与跨职能伙伴合作，其中许多人我们以前从未合作过。一旦我们开始做出这些改变，我们很快就会意识到敏捷不仅仅是在有时间限制的sprint中工作。
不像瀑布，Scrum有很多重复的会议，通常被称为仪式，包括每日站立会议(也称为每日Scrum),积压优化(也称为积压整理),sprint计划，演示,回顾. 作为用户体验人迁移到敏捷，他们可能会想他们是否需要参加每个仪式，他们应该做什么来充分准备和参与。在这篇文章中，我将概述UX在每个Scrum仪式上应该做些什么，以保持开放的沟通，影响产品的成功，并对团队做出富有成效的贡献。本文的大部分讨论将集中在敏捷的Scrum框架上，但是许多概念也可以应用到其他敏捷方法中。
UX应出席并参与仪式
敏捷团队中的用户体验参与这意味着不仅仅是提前冲刺，快速且持续地向产品所有者、涉众和开发人员传递想法。这也意味着在当前的sprint中，在所有的会议和仪式中，成为一个present和积极的贡献者。简单地说，在敏捷中工作的UX专业人员不应该跳过Scrum仪式或在仪式期间缺席。
当我们决定跳过或不完全参加仪式时，我们可能会忽视:
- 更大的图景，我们的产品愿景，以及预期的结果
- 我们为用户解决的问题
- 与我们的团队有共同的目标和目标
- 实施的可行性和实用性与发展
- 我们的设计意图是如何被开发者转化成代码的
- 在即将到来的冲刺中应该优先考虑什么
- 哪里需要发现或额外的sprint 0工作
- 以用户为中心的证据揭穿基于意见的设计的机会
- 邀请团队的机会观察研究或参与研讨会
- UX可以改进产品的领域
- 用户故事需要更多具体的UX细节
- 我们可能需要通过测试支持QA
不参加典礼，我们还对团队内部关系和沟通施加了不必要的压力．不要强迫你的队友在仪式之后告诉你讨论了什么，这会让他们感到沮丧。许多人不会从他们忙碌的日程中抽出时间来和你联系，所以以积极的态度参加仪式，以避免误解和减少关系。
如果你发现自己过于分散，无法参加仪式，那么你很可能试图在给定的冲刺中做得太多。重新调整工作负载的优先级，以支持当前sprint中需要完成的工作，从而确保开发人员拥有下一个sprint所需的工作。以这种方式改变你的心态应该会让你有时间参加仪式。随着时间的推移，当您练习平衡完成工作的时间和花在会议上的时间时，您将能够将更多的活动重新添加到sprint工作负载中。敏捷就是要对变化做出反应，所以检查一下自己很重要，确保你没有做得太过以至于无法参加仪式。
如果，在所有这些之后，你仍然不能参加仪式，与你的经理、产品负责人和Scrum管理员讨论你的工作量，相应地调整你的时间。你的队友应该是你的盟友，并理解为什么你的出现和参与在这些重要的事件中是至关重要的。如果他们不这样做,教育他们为什么在Scrum仪式中，用户体验代表用户的声音对团队和产品来说是富有成效的。如果没有这种声音，团队就有可能引入用户体验的债务不得不删除、重新设计或重构那些没有考虑到最终用户的特性。
如果你不专注于一个产品团队呢?
当用户体验支持单个产品团队时，参加仪式会更容易，但当它必须支持多个开发团队时，冲突的日程安排会让用户体验参加每个仪式变得很有挑战性。尽量参加所有的Scrum仪式，特别是当项目从发现阶段进入交付阶段时。
你在典礼上的表现应该是积极的和参与性的，而不是简单地说你做到了。确保你的出席为谈话增添了有价值的东西，无论你带来了什么从你的研究中得到的见解或使用你的说话时间积极与开发人员联系谁在写你设计的故事，看看他们是否需要澄清。如果您有相互冲突的会议或相互竞争的工作负载优先级，请依靠您的产品负责人或Scrum主管让您了解团队在错过的仪式上讨论的内容。
举个例子,如果一个团队每日站立会议发生在早上,但是你sprint规划的同时另一个团队是谁在中间的一个重要的版本,sprint计划会议,但与产品所有者或Scrum master理解其他团队上的任何阻滞剂后,用户体验可以帮助解决。在这些情况下，UX必须分而治之，对于UX人员来说，依靠团队成员尽可能地了解和参与是完全可以接受的。
在直接冲突和资源限制中确定优先次序
当由于时间冲突或资源限制而不可能参加所有的仪式时，找出哪些会议对用户体验不是至关重要的，偶尔跳过它们。问自己以下5个问题，以帮助优先考虑与Scrum仪式的直接冲突，并管理无法一直参加所有团队的所有会议的现实。
- 我缺席仪式是否会阻碍或延迟开发团队实现sprint目标?
- 如果是，请参加相关仪式
- 如果没有，你可以把时间花在其他地方
- 我是否有重要信息要与团队分享，这些信息可能会对我们的产品和最终用户的体验产生重大影响？
- 如果是，请参加相关仪式
- 如果不是，你可以把时间花在其他地方
- 典礼上还有其他人能代表UX，然后给我更新吗?
- 如果是的话，把时间花在别处是可以接受的
- 如果没有，请参加有关仪式
- 我是否有足够的时间与开发者合作，让他们确信他们理解了我的设计意图和来自用户研究的证据?
- 如果是的话，把时间花在别处是可以接受的
- 如果没有，请参加有关仪式
- 在过去的2个短跑比赛中，我错过了3个以上的比赛吗?
- 如果是，请参加相关仪式
- 如果不是，你可以把时间花在其他地方
UX应该在每个Scrum仪式中做什么
站立会议(每日例会)
大多数Scrum团队都有一个日常会议，称为站立会议或日常Scrum会议。(Scrum既是敏捷框架的名称，也是许多敏捷团队日常活动的名称。)会议要非常短，通常不超过15分钟，重点是与团队沟通，以确保工作在正轨上，任何障碍都被共享并迅速解决。团队的每一个成员，包括UX，都站着鼓励大家对以下问题给出简洁的答案:
- 你昨天做了什么？
- 讨论你所从事的设计领域
- 概述发生的任何与跨职能伙伴的协作
- 讨论你计划、实施或分析的任何研究
- 与团队分享简单的研究结果或用户见解
- 你今天要做什么?
- 让团队知道你当天计划做什么与设计、用户研究、设计评论、研讨会、设计冲刺有关的事情
- 提到你希望从工程或产品方面获得信息的领域
- 提出协作的方法，如结构化草图或白板会议
- 邀请团队成员参加当天的可用性测试和其他研究
- 通过向你的团队宣布、承诺和确认你正在做的事情，让自己对完成工作负责
- 是什么阻碍了你?
- 提出任何阻碍你完成工作的内部或外部因素
- 靠在你的scrum master上，帮助您删除这些障碍进展
- 如果你需要与团队成员进行具体的讨论，建议在站立会后召开一个快速的周转会议
自UX通常会比工程团队领先一个sprint或更多在美国，保持团队一致已经是一个挑战。正是出于这个原因，每天站起来清晰而简洁地交流UX在做什么是如此重要。此外，UX应该在站立期间听取其他团队成员的意见，以解决任何潜在的障碍或问题，UX可以解决或帮助解决。
积压优化
待办事项细化(有时也称为待办事项梳理)通常发生在当前sprint的中途。这个仪式的目的是检查待办事项列表中的项目，以确保它们为即将到来的sprint计划会议(以及最终的sprint)做好了准备。
在这个会议中，产品所有者将回顾当前的待定项优先顺序并调整优先级以满足业务和用户需求。产品负责人将领导与团队的讨论，以了解是否需要其他故事，或者是否需要编辑或删除现有故事。在某些情况下，团队将一起重写或添加故事细节，以确保涵盖所有内容。
让UX专业人士出席会议，以促进白板草图或其他思维技巧能够帮助团队一起解决问题。对于团队在sprint中需要做额外发现工作以获得开放问题的答案的项目，也可以将峰值添加到待办事项列表中。
当待定项达到可接受的细节和上下文级别时，重要的是它们也满足您的团队的定义准备好冲刺了．这一需求保护了团队，使他们免于获得缺乏进行生产性工作所需信息的sprint票据，从而不得不花费原本应该是工作时间的时间来理解首先应该做什么。的的定义准备好了对于每个待定项，团队通常会有所不同，但如果结果是面向用户的，则应该通过以下UX标准:
- 用户描述和验收标准在票据中清晰地表达出来
- 可用的可视化和轻量级文档
- 解决方案已通过用户测试，没有出现严重问题
- 设计遵循风格指南、模式库或设计系统
- 这个项目已经被用户体验、开发和产品所有者审查过了
UX参与backlog梳理可以让开发团队预见到下一个sprint中要做什么，并为产品所有者提供额外的支持。Though product owners should be as informed of user needs and business opportunities as UX, they have many responsibilities that they need to juggle (e.g., implementation realities from the engineering team, strategic goals from business stakeholders, core performance metrics of the team), so there may be times when your product owner needs additional help and accountability from UX. UX should help ensure that product owners make the right decisions for users and the product when choosing which backlog items come next.
Sprint计划
“冲刺”计划通常在“冲刺”的第一天进行，有时甚至提前一天进行。“冲刺”计划的目标是再次检查优先排序的待定项，并估计完成它们所需的努力水平。就像优化一样，产品负责人会引导讨论，在评审每一张票的同时，寻求团队的关键意见。最终，“冲刺”计划的结果是一个“冲刺”待办事项列表，它反映了团队的速度——团队在“冲刺”中愿意承诺完成的工作量。Sprint计划也是团队设定一个现实的Sprint目标的时候，这个目标是一个简短的，一两句话的描述，描述团队在Sprint期间计划要达到的目标。sprint目标是团队接下来几周的愿景。
用户体验参与到sprint计划中是很重要的，因为就像开发工作一样，用户体验工作也应该如此在积压中得到解释，或者使用与工程共享史诗的独立UX票据，或者作为相同票据的一部分，将UX工作组织到父用户故事的子任务中。在评估你的UX工作时，使用t恤的尺寸，而不是故事点。如果你的scrum团队只在工程工作中使用速度，这是很常见的。如果UX工作包含在团队的速度中，那么使用与工程团队相同的方法参与估算故事点。
不管使用什么样的票券结构，用户体验工作都需要让开发团队的其他成员看到，以确保研究和设计任务不会被跳过。参与“冲刺”计划有助于保持团队的一致，并告知用户体验在“冲刺”期间将做什么。这种方法可以帮助工程团队和产品团队成员认识到进入设计和研究过程的严谨性;不断地看到和听到每一项所需的UX工作，将有助于以后对新方法和更改建议的接受。
确保在sprint计划中考虑到用户测试这样团队就知道会发生什么，并有机会参加会议或汇报。对于更大的研究计划或研讨会，如设计冲刺，这是很重要的整个团队都要参与进来，建议将sprint的速度稍微降低一些，这样工程师们就可以留出时间来参加研究，而不会觉得他们必须在此期间进行多任务处理才能实现sprint的目标。
我们也建议你治疗参与者招募作为估计工作量的重要组成部分。编写筛选程序和招募用户通常需要很长时间，因此，当你需要可用性数据时，你越有系统地进行招募，就越容易进行研究。招聘需要计划，你希望避免它成为招聘过程中的瓶颈。维护潜在用户列表，尽可能添加到其中。试着挖掘你当前的客户群，投放广告，与市场研究公司合作，或者在表格或调查中加入额外的问题，以建立你的研究参与者库。
在sprint计划结束时，团队应该有他们的工作负载，以便进行sprint。但是，请记住在sprint计划中讨论的用户故事是为了与您的工程师进行进一步的对话和协作。不要只是将设计添加到用户故事中，然后把它们扔到墙外，然后期待最好的结果;在当前的冲刺阶段，与你的团队保持联系，并随时接受问题或讨论。
Sprint回顾（演示）
Sprint回顾（通常称为演示）通常发生在Sprint的第二天到最后一天。在许多情况下，如果团队在sprint结束时启动，这个仪式将在代码发布的前一天举行。在这次会议上，产品负责人将向涉众和其他可能受到团队在sprint中完成的工作影响的人展示工作代码。对于用户体验来说，sprint评审是一个很好的机会，可以支持产品负责人展示已完成的工作。这也是一个很好的论坛检查测试结果和插入以用户为中心的见解要么通知了当前版本，要么将对产品的下一个迭代产生积极的影响。
有时候，用户体验可能会因为新特性请求的数量或收到的不太理想的反馈而让sprint演示感到不知所措。当这种情况发生时，用一种有组织的方式记录反馈，比如用诸如待办事项，澄清,和说服．与你的产品负责人和scrum负责人合作，帮助引导反馈，并对演示产生的新需求进行优先级排序。在sprint期间，你的团队可能需要与特定的跨职能合作伙伴尽早、频繁地开会，以避免意外或令人不快的期望。
回顾
Post-sprint回顾通常发生在冲刺的最后一天，旨在让团队回顾事情的进展。理想情况下，一个中立的代表，例如来自另一个团队的Scrum主管，或者来自组织另一部分的项目经理，将进行回顾，以保持对话流畅、公正。每个团队成员将讨论在sprint中哪些进展顺利，哪些存在问题，以及可以采取哪些不同的措施来提高Scrum团队的效率。
回顾是UX讨论过程变更的好时机;因为会议的主题是反映团队的过程，人们会更容易接受建议。在以开发人员为中心的环境中，很难提倡将改进交付良好UX工作的能力的过程更改，所以请考虑将您的想法定位为试验，以便在下一个sprint期间进行测试。
回顾也是讨论的好时机:
- 当你没有足够的背景信息或研究时间去设计某样东西时
- 实现错误或沟通错误，即开发人员没有按照您的预期实现您的设计
- 关于你的工作的问题可交付成果和完成的定义你为设计提供了
- 您传达设计规格说明的方式:如果它们有问题、令人困惑或不够具体
- 让产品、工程和业务涉众观察可用性测试会议
除了分享为什么过去的sprint可以做得更好之外，还可以倾听改进与团队其他成员沟通的方法。你的设计说明是否容易理解?你是否用与当前sprint无关的用户数据压倒了你的团队?您的设计解决方案是否难以用现有的体系结构或框架实现?关注你是否在帮助团队的其他成员解决他们自己的特殊问题，因为这就是为什么用户体验可以被视为真正的资产，而不是瓶颈。
回顾也是提出用户观点的好时机。通常情况下，团队必须权衡在sprint期间，用户体验可能不那么重要，而有利于工作的发布，因此，如果最近完成的用户故事中包含什么内容，请与您的团队进行讨论用户体验的债务或者从用户体验的角度进行妥协。
如果您的团队没有进行回顾，那么您的过程就不是敏捷的。每个团队都需要找到自己的方法，但是只有当团队发现哪些方法有效，哪些方法无效时，方法的真正价值才会实现。因为在敏捷团队的生活中有太多的回顾，最终可能会听取一些ux相关的建议。一个很好的经验法则是，团队执行的速度不能快于学习的速度。
结论
UX专业人士很容易质疑他们是否应该参加Scrum仪式，有时候，UX甚至认为这些会议是生产力的障碍。然而，用户体验应该参与到Scrum仪式中，以保持参与并了解团队正在发生的事情。想了解更多关于在Scrum仪式中平衡UX工作量和责任的信息，请花一整天的时间精益UX和敏捷课程。
分享这篇文章：