打破藩篱!增强用户体验的用户中心
我经常看到用户体验(UX)设计师努力地将关注点、工作和方法与Scrum团队协调起来，在30天或更短的时间内构建产品增量。我听到的常见担忧和问题包括:
“开发者并不是真的对用户感兴趣，他们只想进行开发。”
“我试图与团队并肩工作，但我总是走在他们前面，所以我们在每日Scrum中应该讨论什么?”
“我不是在排序循环中工作，也不是在战术上工作。我的工作是战略性的。”
“为什么开发者不使用我的设计工件和决策?为什么他们从来没有回过头去重构好的设计呢?为什么我觉得我从来没有任何影响力?!?!”
这些挑战往往导致双方关系脆弱UX设计师(uxd)和Scrum团队——或者更糟糕的是，不信任、分离和“交错冲刺”(完全独立的团队将工作传递给彼此，他们在完全独立的时间块中执行，他们仍然称之为“冲刺”——即使这些时间块的功能与瀑布阶段完全相同)。
UX和Scrum:更好地结合在一起
但是UX设计师并不需要在远离Scrum团队的孤岛中工作。他们可以是跨团队的设计过程、以用户为中心和假设驱动开发的管理者。事实上，我们可以借鉴自己在将其他专业人员(测试人员、数据分析师和应用程序架构师)集成到Scrum团队中的经验，在使用uxd时提供一些初步的想法。在这篇文章中，我主要关注应用程序架构师的例子，但是意识到对于我提到的其他技能集和专长的团队集成，态度和模式是非常相似的。
早些时候，我从建筑师那里听到这样的事情:
“开发人员通常对好的架构不感兴趣。他们只是想创造出功能。”
“我需要赶在他们之前，在功能整合之前工作，所以我不属于这个团队。”
“我的工作是战略性的。”
“开发者只需要按照我说的去做。可是，他们通常不会……”
Sound familiar? Notice the extensive use of "they/their/them" and "I/my" - just as the list above talking about UX challenges.
随着时间的推移，架构师意识到所有这些挑战都是相互关联的，需要从团队内部全面解决。架构师从命令下达者转变为合作者，在整个团队中建立共识，并在他们的决定背后灌输一种“为什么”的意识。也就是说，开发者是当你在他们前面工作，诋毁他们的工作是“战术上的”，并且除了交付订单之外不与他们合作时，你就不太可能对好的架构感兴趣。或者，更重要的是，当开发人员理解好的体系结构决策背后的“原因”，当架构师将自己嵌入到团队中(如果只是兼职成员)，当架构师将自己的立场从指挥官转变为优秀体系结构的管家和导师时，您将得到一个架构良好的应用程序。这最终是一种向合作和共同目标的心态转变。
架构师做了一些简单但有效的事情(UX设计师也可以做)来促成和展示这种思维方式的转变，包括:
坐下来与编码人员一起收集现有的、已建立的代码和约定，将其转化为可重用的组件和原则
将意识带回更高层次的关注点——架构、产品愿景、用户需求——当人们天真地迷失在细节中时
“午餐和学习”侧重于“为什么”和收集反馈，而不是“我要讲一些东西……”
尽早且经常地共享工作和工件，而不是在以“大爆炸”的方式交付工作之前持有工作
在新的专业的Scrum用户体验(PSU)培训课程通过Scrum.org，我们讨论了这种思维方式的转变，以及在两天沉浸式的体验式学习中实现这种转变的可行策略。PSU培训课程教授学生如何成功地将UX技术和Scrum结合使用，让学生有机会在整个课程中与跨职能团队一起练习这些技术。
用户体验和Scrum:未来!
作为一个对“个人和交互胜过过程和工具”感兴趣的人，我想要开始这个UX和Scrum的对话人类将设计和开发更紧密地结合在一起。本系列的后续文章将讨论更多以人为中心的思想，例如以用户为中心过程和工件实现这里讨论的相同目标的建议:将设计和开发更紧密地结合在一起，以确认共同的目标。
例如，关于过程，用户体验设计师如何实际组织工作——即，它如何适应一个月或更少的Sprint节奏?关于工件，常见的设计系统工件，例如样式指南，如何不仅增量地构建，而且尽可能快地通知实际工作?
我们将在以后的博客文章中讨论这些问题用户体验和Scrum的结合-敬请期待!