介绍

敏捷已经接管了软件开发世界。近年来，它已经成为最流行的软件开发方法．敏捷开发有很多好处:增量的方法，基于客户和涉众反馈改变方向的能力，让团队集中精力的短时间框架。

然而，敏捷方法关注的是开发人员。它们源于程序员试图解决大型软件开发项目中常见的痛点。众所周知,敏捷宣言(仍然是描述敏捷原则的主要文档)没有包括用户体验人员，也没有考虑用户体验专业人员创建优秀设计所需的时间、资源和研究。

在敏捷范式下，整个团队同时致力于同一个项目的相同元素，以避免“把它扔出墙外”(即把它从一个团队传递给另一个团队，瀑布式)。工作是在“sprint”中完成的——通常是两周的时间，团队专注于某些特性，然后继续前进。因此，设计师们承受着巨大的压力，要以不切实际的速度创建、测试、改进和交付他们的产品，而很少有适合一致的、以用户为中心的设计的背景和大局思考。

如果你是个好人，那你就没什么问题用户体验人员在组织中难以实现敏捷．这是困难的。在大型组织中，敏捷通常以严格的方式实现(通常是使用Scrum或类似的方法)，这使得事情变得更具挑战性。两周的冲刺可以迫使设计团队形成隧道式的视野，他们可能过于专注于特定的功能或手边的用户故事，而忽略了大规模的产品和设计含义，比如集成，omnichannel一致性，或用户界面架构。

然而，并不是一切都完了!这些年来，我们与许多在敏捷环境中工作的UX专业人士交谈过，他们中的许多人不仅幸存下来，而且茁壮成长。在与那些愉快且成功地接受了敏捷工作流的人的交谈中，出现了一些共同的主题。这里没有剧本——大多数都是大规模的、战略性的和组织性的因素，用户体验贡献者充其量只能适度地控制这些因素。

当敏捷对UX人员起作用时，是因为组织中的几个关键因素:

1.管理者和领导理解用户体验的价值

许多成功的敏捷用户体验专家说，他们组织中的经理和领导“明白”——他们理解用户体验到底是什么，为什么它对产品开发过程有价值以及它如何提供关键的竞争优势。这是另一种描述方式用户体验的成熟度这是一个我们长期争论的概念，它是UX成功的关键(因此也是业务成功的关键)。这些组织中的决策者知道用户体验不仅仅是一层额外的油漆;而是在产品策略、功能、结构、交互、内容等方面以谨慎和用户为中心的方法，和美学。这些经理和领导不仅要求用户体验设计师采用团队其他成员已经决定的功能和用户工作流，并使它们看起来不错;相反，他们从一开始就让UX人员来决定这些东西应该怎么做工作．

在这些团队中，管理人员也理解构建真正以用户为中心的产品需要和用户一起研究这种类型的研究必须超越简单A / B测试(它没有提供必要的行为洞察力，以理解为什么一个或另一个设计是可行的)。

这些组织中的管理者和领导者接受不确定性，并理解“精益”方法意味着总是假设，测试,迭代对产品的想法。用户体验设计师的工作需要丰富的洞察力，这需要定性的用户研究方法。然而，将敏捷和用户体验整合得很差的组织往往倾向于将定量数据作为决策中最重要或最具说服力的证据，在用户体验蓬勃发展的敏捷组织中，管理者和领导理解这一点定性的见解和定量的见解一样有价值，团队从这些不同类型的数据中学习不同的东西。

2.UX人员展现领导力

虽然拥有理解和支持用户体验的管理者和涉众是非常重要的，但反过来也是正确的:在敏捷环境中取得成功的用户体验人员表现出了领导才能。他们指出关于用户行为的假设如果这是错误的，结果可能是灾难性的。他们会抽出时间向同事寻求帮助解释用户体验的过程和原则以及他们为什么能生产出更好的产品。他们让他们的同事参加可用性测试建立同理心，观察用户的挣扎。他们努力争取时间做用户研究，并设计出正确的东西。在敏捷中茁壮成长的UX专业人士将团队推向更大的图景，以及人们将实际使用这些正在构建的产品的环境。

3.敏捷过程是灵活的

敏捷最初并不是作为一系列规则和仪式来构思的，它是作为一组指导团队实现目标的原则而被发明的敏捷性或者是对周围变化做出优雅反应的能力。撰写《敏捷宣言》的开发人员团队意识到，他们花了大量的时间和精力来管理变更:变更涉众的期望、变更市场环境、变更需求，等等。如果变化是永恒的，为什么要与之抗争呢?构建一个将变更考虑在内的流程，并将其视为预期的输入而不是混乱。

敏捷是一种关于彻底透明和承认团队在项目开始时并不知道所有答案的心态。在实践中，许多组织使用Scrum来实现它，Scrum是一种众所周知的、被广泛使用的敏捷方法。组织通常采用Scrum并不是因为它适合他们，而是因为有丰富的资源可以帮助他们快速进行“敏捷转换”。最终的结果往往是一套新的不灵活的流程标准、不断的会议和令人困惑的行话。

不幸的是，传统的Scrum过程并不适用于用户体验，因为用户体验最初并没有被纳入Scrum定义中。这是一个以技术为中心的过程，专注于小的、独立的工作单元(通常以用户故事的形式)，从计算机科学的角度来看是有意义的，但从以用户为中心的角度来看是棘手的。用户不会孤立地与我们的设计中的一小部分进行交互，他们使用我们的产品来实现更大的目标，我们的所有设计必须和谐地协同工作，以提供良好的用户体验。(事实上，在全渠道的世界里，用户期望公司的整体用户体验执行无缝跨多个产品，即使是由不同的团队开发。)

当敏捷过程没有被完全监管和严格时，UX工作得很好。例如，如果一个组织中有一些坚持敏捷过程的人，他们会揭发用户体验是否比开发人员早一步完成设计，那么用户体验人员就很难超越像素推手。在敏捷中取得成功的UX专业人士所处的环境更关心如何优雅地响应变化，而不是一个站立式会议能持续多久。用户体验整合良好的团队将会弄清楚如何管理任务和用户故事，这样用户体验就有时间提前生产并创建经过验证、研究和深思熟虑的设计。

4.UX专业人员和开发人员是同一个团队的一部分

有效的敏捷团队必须进行良好的沟通，并对项目的目标(无论是大的还是小的)有共同的理解。只有用户体验专业人士是团队的关键成员，他们才能超越像素推送和装饰。当用户体验被组织为一个独立的部门，为不同的产品团队“咨询”时，用户体验专业人员可能感觉不到对项目的相同程度的所有权，并且可能难以与核心团队成员建立信任和共同点。

关于用户体验敏捷的一个关键问题是，在成功的团队中，开发人员尊重用户体验人员和他们的过程，并且愿意听取他们的见解和想法。但是这种情况只有在紧密合作之后才会出现:UX专业人员必须通过严格验证设计理念，改进它们，并以诚实和平易近人的方式与团队其他成员交流这种严格性来赢得开发人员的信任。

结论

让用户体验和敏捷一起工作是很困难的，如果你是一个在敏捷中挣扎的用户体验人士，你不是一个人。典型的敏捷过程没有考虑到用户体验人员交付以用户为中心的产品所需的时间、资源和范围。尽管如此,用户体验和敏捷可以共存,只要(1)组织的管理理解和支持用户体验工作,(2)用户体验人员展示领导能力和花时间在拓展他们的同事,(3)敏捷工作流是足够的灵活性,可以满足用户体验的需求,和(4)用户体验人产品团队的一部分,在那里他们可以与开发人员建立尊重和融洽的关系。

在我们的网站上了解更多关于如何在敏捷环境中作为UX专业人员茁壮成长的信息精益UX和敏捷研讨会，并从我们的报告有效的敏捷用户体验产品开发．