今年早些时候，我们问了敏捷从业者用户体验会议分享有助于他们敏捷项目成功的技巧或技术。

我们收到了125年响应来自美国和新加坡的专业人士。受访者在各种规模的公司工作并持有不同的工作职责，从UX设计师和开发人员到产品所有者和项目经理。(Obviously, there is some potential bias in this respondent pool which does not include the many companies that don’t invest anything in user experience. However, it is fair to say that the survey responses do reflect practices in organizations who care enough about UX to send their staff to user-experience training.)

成功敏捷项目的10个关键建议

以下是敏捷专家报告的最流行的技术:

小提示# 1。为发布计划和故事映射留出时间。

受访者表示，在项目开始时花时间适当计划发行内容是值得的:

“在规划、设计和规范方面投入更多的精力。”

“尽早参与。”

“在计划阶段花更多时间，然后专注于优化和调整。在开始项目之前，先获得支持。”

“提前安排好工作时间，做好一切准备。”

“在Sprint开头进行适当和广泛的规划。允许足够的时间处理不可避免的阻滞剂。“

与利益相关方合作从一开始就允许团队为他们的项目开发共同的理解和共同愿景。这个共同愿景引导整个项目团队成员，帮助他们优先考虑用户故事并沿途做出正确的权衡。

有些团队在发布计划期间使用故事映射，以帮助涉众与其他团队成员协作创建产品待定项。这种活动通常会发现新的机会，并帮助团队对用户故事进行分组和优先级划分。

UX参与释放计划将重点放在更广泛的背景下，识别需要未来研究的知识差距，并收集信息（例如，通过运行适当的用户学习）来告知项目在项目开始之前的决策。当团队分配了发现工作和研究时的时间，他们稍后会减少浪费的努力。

“在敏捷开始特许、角色开发和故事映射之前，包括发现过程。”

小提示# 2。在sprint之前进行UX活动。

许多人报告说，在一个sprint中同时进行相同功能的设计和开发是很困难的。两周的时间通常不足以进行研究、创建线框和设计，以及为选定的用户故事进行开发工作。

克服这一挑战的最常见建议是错开UX/UI和开发工作流程，以便在sprint开始之前完成研究和设计。例如，UX在sprint 1中创建了屏幕。然后开发人员将完成的设计在sprint 2中进行编码。

“我将一个Sprint一向UX / UI领先工作。我将使用Scrum Master和产品所有者在积压中的项目优先顺序，并在生产之前满足UX / UI要求。我的时间必须朝着冲刺的不同程度地计算，省略速度，但非常有效。“

“研究和设计应该至少领先一步。给自己时间进行彻底的用户研究并测试你的设计。”

“确保尽早进行设计，这样你就可以在开发开始前创建原型并测试概念。”

“在冲刺阶段花些调查时间，预测即将到来的冲刺阶段的需求。”

“有模仿准备冲刺规划。”

在开发流程之前工作可以让设计师有时间思考并与真实用户一起测试假设。保持领先可以让整个团队在该特性的设计为sprint做好准备之前检查模型并识别潜在的问题。

项目的规模和复杂性会影响开发用户体验设计师的工作进度。大多数实践者报告提前1到2个sprint进行设计。

这是一个协调的工作，需要团队成员之间的沟通。仅仅因为设计在开发sprint之前就完成了(或大部分完成了)，并不意味着UX设计师就可以简单地把设计交给开发人员，然后继续前进。虽然用户体验设计师应该不断地提前计划，但他们也必须支持当前的sprint，建议团队，并在必要时做出调整。

此外，所有团队成员，包括项目经理、产品负责人和工程师，应该在整个过程中与UX设计师密切合作，这样当设计“准备好”时，每个人都是同步的。后端和前端开发人员需要理解并支持设计、交互和用户流程。

小提示# 3。培养合作文化。

软技能可以将密钥保持在敏捷项目中的成功。受访者将健康的合作确定为成功的主要因素。这一发现并不奇怪;毕竟，在敏捷的宣言中，个人和互动在流程和工具上受到重视。无论其过程方法如何，良好的沟通都是必不可少的。但是，协作在敏捷设置中更为重要，其中交货时间短且时间盒。

一些组织选择的思维创意和头脑风暴等技术鼓励讨论，打破阻碍有效沟通和团队合作的藩篱。

“合作至关重要。”

“与团队中的其他角色密切合作[帮助我们]在此过程中暂时到达协议。”

“与所有团队成员持续不断地合作。我们使用草图和白板会议;旅行体验地图有助于捕捉omnichannel经验．”

在跨职能团队中共享信息。多与开发者和设计师交流。”

“在早期阶段，不要轻视和拒绝任何想法。”

“涉及团队中的每个人，欢迎每个人的建议和想法。”

“保持业务分析师、设计师和工程师之间的密切关系。”

“每周定期会面一次，更新并了解进展情况。把注意力集中在能帮助彼此完成工作的事情上。”

“每天的站立会议、迭代演示、每两周的脉冲会议，以及与管理层的互动。”

在现代软件开发环境中，UX大量参与定义在线产品和服务的开发方式。像这样，用户体验的作用已经扩展到包括交流．通过让团队成员参与可用性测试和实地研究等活动，用户体验可以成为良好协作的催化剂，而且还可以进行团队设计构思和头脑风暴。

提示＃4.思考迭代，而不是完美。

在我们的研究中，许多人赞成迭代设计过程．从低保真原型（草图，线框）开始，并根据用户和客户反馈迭代。换句话说，失败快速，经常失败。

“尽可能长时间地低保真度地工作，以避开美感。”

“采用快速而肮脏的线框方法。”

“用很多选择快速迅速迭代。”

“不要试图完美。”

“迭代工作。”

“经常迭代和测试。”

线框图很适合敏捷过程，因为它允许团队成员在投入太多精力和时间之前快速测试他们的设计想法。早期发现的设计缺陷比在编写功能代码后发现的设计缺陷更容易纠正。

冰山# 5。参加scrum会议。

在四种scrum仪式中，每天的站立会议(scrum会议)从我们的受访者中得到的主动点头最多。Scrum会议通常每天在同一时间举行，每次15分钟。scrum会议的主要目的是让团队中的每个人更新进度，并认识到需要消除的障碍。

“每天召开简短的scrum会议。”

“我们与开发者的日常合作让我们能够轻松地确保我们在正轨上。”

“每天的scrum会议是关键。”

“限制每个人只在2分钟内完成任务，并设置计时器。否则他们会一直说下去。”

“每天召开快速状态会议，让每个人都有任务。”

“参加短暂的立场。”

人们有时会反对每天的scrum会议，因为它们和其他所有的梳理和计划、演示和回顾的会议一起，消耗了宝贵的工作时间。然而，我们的调查结果显示，这种习惯有助于保持团队的更新和同步，以便在必要时对变化做出反应。

基于本研究的结果，如果您从您的过程中删除了每天的立场，也许值得换取另一种外观并给予它一个机会。密切关注可能影响人们参与意愿的其他因素：这些会议进行了程度，以及讨论是否涉及UX相关的活动。

提示＃6：将用户研究转为团队驱动的事件。

人们认为可用性测试是团队建设和影响决策的积极因素。即使是压缩的时间表，敏捷团队也能够做到结合用户研究到他们的过程。这一发现打破了用户测试太耗时或太昂贵的神话。团队正在努力:每周用户测试(星期二测试)是一种可能的方法。

受访者鼓励将可用性测试转变为团队活动，成员(和利益相关者)观察会议并参与汇报讨论。

“确保所有利益相关者都出席研究会议。”

“呈现硬性(用户)数据影响了决策。”

“让开发者和产品所有者参与或观察可用性会议。”

“在足够的时间内进行研究和测试。尽可能提前计划。”

“在测试结束后，尽可能多地见面，以确保大家意见一致。”

“从前一周开始为现在的会议提供一周的会议。”

共同制定设计决策基于用户数据，而不是意见或未经测试的假设，推动团队更快地前进。

技巧7:确保强大的利益相关者参与。

我们的受访者强调了利益相关者在关键时刻参与的重要性。这个概念与敏捷原则是一致的:重视客户合作胜过合同谈判。合同是重要和有用的，但当它们妨碍有效合作时，就会阻碍进展。

组织应用不同的策略与涉众合作。使用的技术包括及早组建核心领导团队，让关键用户体验成员与客户合作，邀请客户参加用户测试会议，以及经常进行高水平的演示。

“与利益相关者和工程师进行持续的对话。”

“通过大场景演示(5-10分钟)让领导力参与项目的每个主要步骤。”

“首先组建一个领导团队。”

“让关键利益相关者看到你的障碍。”

“让用户体验嵌入到商业利益相关者中。”

技巧#8:设置明确的角色和职责。

许多受访者强调团队成员需要了解自己的个人角色和同事的角色。为了让敏捷有效地工作，成员需要知道什么是预期的，什么属于他们的影响范围之内。

“职位的绝对分离是必不可少的。”

“与产品负责人、客户和用户举行关于敏捷过程和对他们的期望的分享会议。”

“要有一个独立的scrum管理员和产品负责人。”

“你需要一个强大的scrum大师。”

“注意你的开发团队是如何工作的。”

在传统的敏捷方法中，团队组成和角色都是公平定义的，除了用户体验实践者。事实上，传统的Scrum团队并不包括用户体验。因为用户体验角色和过程对其他团队成员来说可能是新的或不熟悉的，所以设定期望并帮助人们在敏捷环境中思考用户体验是特别重要的。

明确每个人的角色和职责，以及在各种情况下谁拥有权力，可以减少误解，并在地盘争夺战上浪费精力，从而提高合作。

提示＃9：主机培训和船上会话。

敏捷团队成员强调了让客户、新团队成员和外部团队了解敏捷用户体验过程的重要性。

“举办‘午餐学习’活动，帮助他人理解这个过程。”

“掌握方法并继续解释它。”

“进行训练，灌输。”

“进行跨职能培训。”

“火车跨团队。”

“跟着仪式。对客户进行相关教育。”

“提供面向所有人的培训，独立于他们所从事的项目。提供小块的指导方针或最佳实践，并解释为什么会这样。”

在敏捷环境中，团队成员从一个团队转移到另一个团队是相当普遍的。虽然这种做法并不理想，但对于资源有限的许多组织来说，这往往是现实。

培训为员工提供了一个培训用户体验和敏捷实践的机会。敏捷提供了一个交付产品的框架，但是用户体验在这个框架中的集成方式因组织或团队的不同而不同。

除了教育你的直接团队，接触外部团队和业务单位。设定适当的期望会让沟通和转换更顺畅。

提示10:修改你的方法直到它生效。

随着敏捷团队的成熟，他们会更多地尝试不同的敏捷和用户体验技术，并根据自己的环境进行调整。将迭代设计不仅应用于用户界面，还应用于你的项目方法论。

“我们不断地审查敏捷的每个方面，如果它不起作用，我们就进行修改。回顾和项目事后分析是非常有帮助的。”

“对团队进行大多数敏捷方法的教育。让他们决定从每个元素中使用哪些元素。由于团队是自组织的，他们应该决定什么对他们的过程是最好的。他们拥有它。”

“我们更喜欢不需要固定迭代的较长时间的过程。”

敏捷为构建工作提供了一个框架，但不决定如何运行项目。它鼓励团队自我组织，反映出更有效地工作的方式，并根据需要进行适应，以削减不需要的复杂性。

高级软件开发团队正变得比以往任何时候都更加多学科和灵活。成功的团队通常会采取混合的方法。敏捷和用户体验方法是为了应对传统方法的缺陷而发明的。如果我们少强调规则，多关注结果，那么敏捷方法和用户体验方法都有各自的优点，可以协同工作。

更多的发现从我们对集成敏捷开发和良好用户体验设计的项目的研究中得到的精益和敏捷UX．