从传统的产品开发过程（如瀑布式开发）到现代敏捷框架（如Scrum）的转变可能是一个巨大的挑战用户体验的挑战. 我们必须学习一套全新的术语，适应完成研究或设计工作的新时间框架，走出我们的舒适区，与跨职能合作伙伴合作，其中许多人我们以前从未合作过。一旦我们开始做这些改变，我们很快就会意识到敏捷不仅仅是在时间限制的冲刺中工作。
不像瀑布，Scrum有很多重复的会议，通常被称为仪式，包括每日站立（也称为每日Scrum),积压优化（也称为积压整理),短跑计划，演示，及回顾. 作为用户体验人转向敏捷，他们可能会想他们是否需要参加每个仪式，他们应该做什么来充分准备和参与。在这篇文章中，我将概述UX在每个Scrum仪式上应该做些什么，以保持开放的沟通，影响产品的成功，并对团队做出富有成效的贡献。本文的大部分讨论将集中在敏捷的Scrum框架上，但是许多概念也可以应用到其他敏捷方法中。
UX应出席并参与仪式
敏捷团队中的用户体验参与这意味着不仅仅是提前冲刺，快速且持续地向产品所有者、涉众和开发人员传递想法。这也意味着在当前的sprint中，在所有的会议和仪式中，成为一个present和积极的贡献者。简单地说，在敏捷中工作的UX专业人员不应该跳过Scrum仪式或在仪式期间缺席。
当我们决定跳过或不完全参与仪式时，我们可能会忽视：
- 大局、我们的产品愿景和预期结果
- 我们为用户解决的问题
- 与我们的团队有共同的目标和目标
- 实施可行性和实用性与发展
- 开发人员如何在代码中转换我们的设计意图
- 在即将到来的冲刺中优先考虑什么
- 需要发现或其他sprint 0工作的地方
- 以用户为中心的证据揭穿基于意见的设计的机会
- 邀请团队参与的机会观察研究或参与车间
- 用户体验可以改进产品的领域
- 用户故事这需要用户体验提供更具体的细节
- 我们可能需要通过测试支持QA
不参加仪式,，我们还对团队内部关系和沟通施加了不必要的压力．不要强迫你的队友在仪式之后告诉你讨论了什么，这会让他们感到沮丧。许多人不会从他们忙碌的日程中抽出时间来和你联系，所以以积极的态度参加仪式，以避免误解和减少关系。
如果你发现自己过于分散，无法参加仪式，那么你很可能试图在给定的冲刺中做得太多。重新调整工作负载的优先级，以支持当前sprint中需要完成的工作，从而确保开发人员拥有下一个sprint所需的工作。以这种方式改变你的心态应该会让你有时间参加仪式。随着时间的推移，当您练习平衡完成工作的时间和花在会议上的时间时，您将能够将更多的活动重新添加到sprint工作负载中。敏捷就是要对变化做出反应，所以这是很重要的，检查自己，并确保你没有做得太多，以至于你无法参加仪式。
如果在所有这些之后，您仍然无法参加仪式，请与您的经理、产品负责人和Scrum主管讨论您的工作量，以相应地调整您的时间。你的队友应该是你的盟友，并且理解为什么你的出席和参与在这些重要事件中至关重要。如果他们没有，教育他们为什么在Scrum仪式中，用户体验代表用户的声音对团队和产品来说是富有成效的。如果没有这种声音，团队就有可能引入用户体验债务不得不删除、重新设计或重构那些没有考虑到最终用户的特性。
如果你不专注于一个产品团队呢？
当用户体验支持单个产品团队时，参加仪式更容易，但当用户体验必须支持多个开发团队时，相互冲突的日程安排可能会使用户体验难以参加每一个仪式。尽你最大的努力去参加所有的Scrum仪式，尤其是当你的项目从发现到交付的时候。
你在典礼上的表现应该是积极的和参与性的，而不是简单地说你做到了。确保你的出席为谈话增添了一些有价值的东西，无论你是否带来从你的研究中获得的见解或者利用你的发言时间积极与开发人员联系谁在写你设计的故事，看看他们是否需要澄清。如果您有相互冲突的会议或相互竞争的工作负载优先级，请依靠您的产品负责人或Scrum主管让您了解团队在错过的仪式上讨论的内容。
举个例子,如果一个团队每日站立会议发生在早上,但是你sprint规划的同时另一个团队是谁在中间的一个重要的版本,sprint计划会议,但与产品所有者或Scrum master理解其他团队上的任何阻滞剂后,用户体验可以帮助解决。在这些情况下，UX必须分而治之对于用户体验人员来说，依靠队友尽可能地保持知情和参与是完全可以接受的。
在直接冲突和资源限制中确定优先次序
当由于时间冲突或资源限制无法参加所有仪式时，找出哪些会议对用户体验不重要，并偶尔跳过它们。问自己以下5个问题，以帮助优先考虑与Scrum仪式的直接冲突，并管理无法始终参加所有团队的所有会议的现实。
- 我的缺席会阻碍或延迟开发团队实现sprint目标吗？
- 如果是，请参加有关的仪式
- 如果不是，你可以把时间花在别处
- 我是否有重要信息要与团队分享，这些信息可能会对我们的产品和最终用户的体验产生重大影响？
- 如果是，请参加有关的仪式
- 如果不是，你可以把时间花在其他地方
- 仪式中是否有其他人可以代表用户体验并在之后向我提供最新信息？
- 如果是的话，把时间花在别处是可以接受的
- 如果没有，请参加有关的仪式
- 我是否有足够的时间与开发人员合作，以确信他们理解我的设计意图和用户研究的证据？
- 如果是的话，把时间花在别处是可以接受的
- 如果没有，请参加有关的仪式
- 在过去的2个短跑比赛中，我错过了3个以上的比赛吗?
- 如果是，请参加有关的仪式
- 如果不是，你可以把时间花在其他地方
UX在每个Scrum仪式中应该做什么
站立（每日Scrum）
大多数Scrum团队都有一个日常会议，称为站立会议或日常Scrum。（Scrum既是敏捷框架的名称，也是许多敏捷团队日常活动的名称。）会议的时间非常短，通常不超过15分钟，重点是与团队沟通，以确保工作按计划进行，任何障碍都可以共享并迅速解决。团队的每一个成员，包括UX，都站着鼓励大家对以下问题给出简洁的答案:
- 你昨天做了什么？
- 讨论您所从事的设计领域
- 概述与跨职能合作伙伴进行的任何协作
- 讨论您计划、进行或分析的任何研究
- 与团队分享简单的研究结果或用户见解
- 你今天要做什么？
- 让团队知道你当天计划做什么与设计、用户研究、设计评论、研讨会、设计冲刺有关的事情
- 提到你希望从工程或产品方面获得信息的领域
- 提出协作方法，如结构化草图或白板会议
- 邀请团队成员参加当天的可用性测试和其他研究
- 通过向你的团队宣布、承诺和确认你正在做的事情，让自己对完成工作负责
- 是什么阻碍了你?
- 提出任何阻碍你完成工作的内部或外部因素
- 依靠Scrum大师帮助您消除这些进展障碍
- 如果您需要与团队成员进行具体讨论，建议在站立后召开一次快速转身会议
自用户体验通常比工程团队提前一个或多个冲刺阶段，保持团队一致已经是一项挑战。正是因为这个原因，参加每日的站立会议，清晰、简洁地交流用户体验的工作是如此重要。此外，用户体验应在站立时听取其他队友的意见，以了解用户体验能够解决或帮助解决的任何潜在障碍或问题。
积压优化
积压优化（有时也称为积压整理）通常在当前sprint的中途进行。这个仪式的目的是审查积压工作中的项目，以确保它们为即将到来的sprint计划会议（以及最终的sprint）做好准备。
在本次会议中，产品负责人将审查其当前产品中的待办事项优先顺序并调整优先级以满足业务和用户需求。产品负责人将领导与团队的讨论，以了解是否需要其他故事，或者是否需要编辑或删除现有故事。在某些情况下，团队将一起重写或添加故事细节，以确保涵盖所有内容。
让用户体验专业人士参加本次会议，以促进白板草图或其他思维技巧可以帮助团队一起解决问题。对于团队需要在sprint中进行额外的发现工作以获得开放性问题的答案的项目，也可能会将峰值添加到待办事项列表中。
当待办事项达到可接受的详细程度和上下文时，它们还必须符合团队对待办事项的定义，这一点很重要准备好冲刺了吗. 这一要求保护了团队，使其不会因为缺少进行生产性工作所需的信息而获得sprint票证，从而不得不花费本可以是工作时间的时间来理解首先应该做什么。这个定义准备好的对于每个待办事项，项目通常会因团队而异，但如果结果是面向用户的，则应通过以下用户体验标准：
- 用户故事和验收标准在票证中明确阐述
- 提供了可视化和轻量级文档
- 解决方案已经过用户测试，没有出现严重问题
- 设计遵循样式指南、样式库或设计系统
- 该项目已由用户体验、开发和产品负责人审核
UX参与backlog梳理可以让开发团队预见到下一个sprint中要做什么，并为产品所有者提供额外的支持。尽管产品所有者应该像用户体验一样了解用户需求和商业机会，但他们有许多责任需要处理（例如，工程团队的实施现实、业务利益相关者的战略目标、团队的核心绩效指标），因此，有时您的产品负责人可能需要用户体验的额外帮助和责任。用户体验应该有助于确保产品所有者在选择下一个待完成项时为用户和产品做出正确的决策。
Sprint计划
冲刺计划通常发生在冲刺的第一天，或者有时提前一天。sprint计划的目标是再次检查优先待办事项，并估计完成这些待办事项所需的工作量。与细化非常相似，产品负责人领导这场讨论，在审核每一张票的同时，从团队中寻求关键的意见。最终，sprint计划的结果是反映团队速度的sprint backlog——团队在sprint中轻松完成的工作量。Sprint planning也是团队设定一个现实的Sprint目标，这是一个简短的、一句或两句话的描述，描述团队在Sprint期间计划实现的目标。sprint目标是团队未来几周的愿景。
UX参与sprint规划很重要，因为就像开发工作一样，UX工作应该是在积压工作中有所说明，或者使用与工程共享史诗的独立UX票据，或者作为相同票据的一部分，将UX工作组织到父用户故事的子任务中。在评估你的UX工作时，使用t恤的尺寸，而不是故事点。如果你的scrum团队只在工程工作中使用速度，这是很常见的。如果UX工作包含在团队的速度中，那么使用与工程团队相同的方法参与估算故事点。
不管所使用的票证结构如何，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无关的用户数据压倒了您的团队？您的设计解决方案在使用现有体系结构或框架实施时是否具有挑战性？关注你是否在帮助团队其他成员解决他们自己的特殊问题，因为这就是为什么用户体验可以被视为真正的资产，而不是瓶颈。
回顾也是提出用户观点的好时机。通常情况下，团队必须做出权衡在sprint过程中，用户体验可能会被忽略，而倾向于将工作交付，因此，如果最近完成的任何用户故事包含用户体验债务或者从用户体验的角度进行妥协。
如果您的团队没有进行回顾，那么您的流程就不是敏捷的。每个团队都应该找到自己的方法，但只有当团队发现什么有效，什么无效时，方法的真正价值才会实现。因为在敏捷团队的生活中有太多的回顾，有可能最终会听取一些与用户体验相关的建议。一个很好的经验法则是，团队的实施速度不应超过其所能学到的速度。
结论
用户体验专业人士很容易质疑他们是否应该参加Scrum仪式，有时用户体验甚至会将这些会议视为生产力的障碍。然而，用户体验应该参与Scrum仪式，以保持参与并了解团队的进展情况。要了解更多关于平衡用户体验工作负载和Scrum仪式责任的信息，请花一整天时间精益与敏捷课程。
分享这篇文章：