125个从业者分享了他们在Agile（敏捷）项目中提升用户体验的经验和成功故事。
今年早些时候，我们让UX Conference上的敏捷从业者分享了他们在敏捷项目中运用到的的成功秘诀和技巧。
我们收到了美国和新加坡125位专业人员的回应。这些人在各类规模的公司工作，并且担任不同的工作职责，从UX设计师，开发者，项目负责人到项目经理。显然，这里存在着一些潜在的受访人偏差，因为他们不包含很多完全不关注用户体验的公司。不过我们可以说这些答复确实反应了那些对UX足够关注并愿意送员工来参加用户体验培训的机构的情况。
成功敏捷项目的10大关键技巧
1、留时间用以release规划和故事导图(story mapping)
受访者汇报说在项目开始花时间好好做release规划是一项值得的投资：
“在规划，设计和细化阶段投入更多的精力。”
“在最开始就参加进去。”
“在规划阶段花更多的时间，然后专注于改进和调整。在项目开始前获得认可。”
“尽早计划好营业时间，签好所有东西。”
“在sprint开始做好适当且广泛的规划。留出足够的时间来处理不可避免的阻碍。”
在开始阶段就跟利益相关者展开合作，能够让团队产生对项目共同的理解和愿景。这个共同的愿景会在整个项目过程中指导团队，为他们给用户故事（user stories）做优先级排序和正确取舍上提供帮助。
有些团队在release规划阶段采用了故事导图（story mapping）来帮助利益相关者与其他团队成员一同创建产品储备(product backlog)。这项活动经常揭示新的机遇，并帮助团队给用户故事分组和排序。
UX在release规划阶段的参与可以使得团队专注于更广阔的背景，找到需要进一步钻研的知识缺口，并且在项目开始之前收集团队决策所需的信息（例如通过一些适当的用户研究）。如果团队分配时间来做项目起步阶段的发掘和研究工作，他们可以减少将来的无用功。
“在敏捷开始之前加入探索过程，用以项目策划，人物角色构建和故事导图。”
2、在sprint开始之前开展UX活动
很多人汇报说在单个sprint期间尝试同时开展设计和开发工作很难。两周的时间往往不够完成研究、线框图和设计，并且同时完成所选用户故事的开发工作。
克服这项挑战最常见的建议就是交错UX/UI和开发的工作流，这样在sprint开始之前就可以完成研究和设计。例如，UX在sprint1制作界面，接着开发在sprint2中为完成好的设计编写代码。
“作为UX/UI负责人，我提前一个sprint完成我的工作。我会和scrum master及产品负责人一起对backlog中的项目进行优先级排序，并且在提前一个sprint完成UX/UI的需求。我在sprint中的工作时间计算方式有些不同，要从团队速率中扣除，但是这种做法很高效。”
“研究和设计工作应该保持一个sprint的提前量。给自己留时间来进行深入的用户研究和设计测试。”
“确保尽早完成设计，这样你可以在开发开始之前制作原型并且测试你的概念。”
“在sprint期间花时间调查，来满足下个sprint的预期需求。”
“在sprint规划会议前准备好原型。”
在进入开发之前完成工作，可以留时间给设计师进行充分的思考，并且与真实用户验证假设。保持提前量可以让整个团队在功能设计进入sprint之前对审查原型并发现潜在的问题。
项目的规模和复杂度会影响UX设计师需要在开发之前多久开始工作。大多数从业者建议提前1到2个sprint进行设计工作。
这是一个协调性的工作，对团队沟通有一定要求。仅仅因为设计在开发sprint之前完成了（或者完成了大部分）并不意味着UX设计师只需把设计交给开发者就可以继续后面的工作了。尽管UX设计师应该保持未雨绸缪，他们仍然必须支持当下的sprint，给团队提供建议，并且在必要的时候做出调整。
此外，所有的团队成员包括项目经理，产品负责人和工程师，应该在过程中和UX设计师紧密合作，这样当设计“就位”的时候，所有人是保持同步的。后端和前端开发者需要理解并支持设计，交互和用户流（user flows）的工作。
3、培养协作文化
软技能是敏捷项目成功的关键。受访者们认为健康的合作关系是成功的主要因素。这一发现并不令人惊讶；毕竟，在敏捷宣言里，个体和交互的价值高于流程和工具。良好的沟通在任何软件开发组织中都是必不可少的，无论其流程方法如何。但是在敏捷环境中，合作尤为重要，因为它的交付时间短，并且有固定的时间限制。
一些机构选择采用设计思维的技巧，例如用构思和头脑风暴来鼓励团队讨论，并且打破那些阻碍有效沟通和团队合作的隔阂。
“合作是至关重要的。”
“与团队其他角色的紧密合作帮助我们在过程中更早地达成一致。”
“与所有团队成员持续合作。我们用速写和白板会议，以及体验地图来获得全方位的体验。”
“在跨职能团队中分享信息。更多地和开发者及设计师进行沟通。”
“在初始阶段不贬低或放弃想法。”
“让团队里的每一个人都加入进来，并欢迎任何人的建议和想法。”
“保持业务分析师，设计师和工程师之间的密切关系。”
“每周定期碰头来更新和了解进度。专注于互相帮助以完成工作。”
“每日立会，迭代演示，两周一次脉冲会议（pulse meeting），与管理层互动。”
在现代开发环境中，UX已经积极地参与到制定线上产品服务的开发方式中。因此，UX的职责已经扩大到沟通层次。UX可以通过参与团队成员活动，例如可用性测试，实地调研，设计构思和头脑风暴，成为良好沟通的催化剂。
4、别光想着完美，多想想迭代。
在我们的研究中，很多人赞成迭代的设计流程。从低保真原型（手绘，线框）开始，根据用户和客户的反馈进行迭代。换句话说，快速失败，经常失败。
“尽可能长久地进行低保真工作，先不考虑美观的部分。”
“选择快速粗糙的线框图方式。”
“快速失败，在迭代中尝试多种选项。”
“不要试图做到完美。”
“迭代地进行工作。”
“频繁地迭代和测试。”
线框图对于敏捷流程是天作之合，因为它能让团队成员在投入更多精力和时间之前，快速地测试设计想法。早期发现的设计缺陷比功能编码完成之后要容易修复的多。
5、参与到scrum会议中来
在四项scrum仪式之外，访问者主动点赞最多的就是每日立会(scrum会)了。scrum会通常在每天相同的时间段，在15分钟内召开。scrum会的主要目的是让每个人了解团队最新的进展，并且认识到需要解决的障碍。
“每天有短暂的scrum会议。”
“我们的每日立会更好地让开发者们保持在轨道上(on track)。”
“每日scrum会议是关键。”
“限制每人发言时间在2分钟以内，得有计时员。否则他们永远也讲不完。”
“每天的快速状态更新可以保证每个人都在完成任务。”
“参加短立会。”
有时候人们会反对每日scrum会议，因为加上其他所有会议，梳理会、规划会、演示会还有回顾会，他们已经耗光了宝贵的工作时间。然而，我们的调查显示这样的仪式对于保持团队的状态更新和同步有很大用处，这样大家才可以在必要的时候响应变化。
基于这次研究的结果，假如你已经放弃了每日立会，也许值得考虑再给它一次机会。仔细观察其他可能影响人们参会意愿的因素：这些会以是否能顺利进行，这些讨论是否加入了UX相关的活动。
６、将用研转化为团队驱动的事件
人们反映说可用性测试是团队建设和影响决策的一个积极因素。即便在时间紧张的情况下，敏捷团队也可以将用户研究加入到他们的流程中来。这一结论打破了用户测试过于耗时和昂贵的谣言。团队将它用起来：一周一次（例如周二）进行用户测试是一个可行的方式。
受访者提议将可用性测试转为整个团队的活动，让成员们（包括利益相关者们）观察测试过程并且加入后期讨论。
“确保所有的利益相关者都出席了研究会议。”
“提供明确的硬数据对决策产生了影响。”
“让开发者和产品负责人参与或观察可用性测试。”
“在sprint里给研究和测试充足的时间。尽可能提早规划。”
“测试完成之后，尽可能多碰头，以确保大家的一致认识。”
“每周安排会议来展示上周的研究结果。”
大家一起根据用户数据做设计决策，而非根据意见或者未经检验的假设，可以让团队更快地前进。
7、确保重要利益相关者的参与
我们的受访者强调了利益相关者在关键点参与的重要性。这个概念和敏捷原则相一致：比起合同谈判，更重视客户协作。合同是重要和有益的，但是当它们对有效合作有影响的时候，会阻碍前行。
一些机构采用的不同的策略与利益相关者协作。这些方法包括早期组建核心领导团队，让关键UX成员与客户合作，邀请客户参与用户测试，以及频繁地进行高层级的演讲。
“与利益相关者和工程师不断对话。”
“通过大场景演讲（5-10分钟），让领导者参与项目的每个主要步骤。”
“先组建一个领导团队。”
“让利益相关者们看得见障碍。”
“在业务利益相关者中嵌入UX。”
８、设定明确的角色和责任
很多受访者强调需要让团队成员了解各自和同伴的角色。为了让敏捷工作能够有效开展，成员们需要知道预期是什么，以及什么在影响范围之内。
“绝对的职位分隔是必不可少的。”
“与产品负责人，客户及用户举办分享会，告诉他们什敏捷流程是什么，对他们的期望是什么。”
“有一个单独的scrum master和一个单独的产品负责人。”
“你需要一个强大的scrum master”
“要知道你的开发团队是如何工作的。”
在传统敏捷方法中，团队的定义和角色分工是相对明确的，用户体验从业者除外。事实上，传统的scrum团队不包含UX。由于UX的角色和流程对于其他团队成员可比较新，他们不熟悉这一领域，因此让大家设置正确的期望，并且帮助人们在敏捷背景下考虑用户体验尤为重要。
明确指示每个人的角色和责任，并说明在不同情况下各自的职权，可以加强协作，减少误解和在地盘争夺中浪费精力。
９、组织培训和入职会议。
敏捷团队成员强调了对客户、新成员和外部团队进行敏捷UX流程教育的重要性。
“举办’午餐学习’来帮助他人了解流程。”
“努力把方法用到最好，并且持续地进行解释。”
“开展培训和灌输。”
“拥有跨职能培训。”
“跨团队培训。”
“遵从仪式并且教育客户。”
“在他们所做的项目之外，提供开放式的培训。提供小份的准则和最佳实践，并且对它们进行解释。”
在敏捷环境中，团队成员的换组现象很常见。虽然这种做法并不理想，但是对于人手有限的机构而言是常见现象。
培训提供了良好的机会来教育员工正确的UX和敏捷实践方式。敏捷提供了交付产品所用的框架，但是不同的组织和团队在这个框架里融入UX的方式各不相同。
为了教育你目前的团队，你需要去接触其他的团队和业务部门。设置适当的预期可以让沟通和交接工作更加流畅。
10、改进你的方法直到它发挥作用。
随着敏捷团队的日渐成熟，他们会尝试不同的敏捷及UX技巧，为匹配他们的环境做特别定制。不光用户界面，也需将迭代设计用于项目方法。
“我们不断检讨敏捷的各个方面，如果效果不好就做出改进。回顾会和反思会很有帮助。”
“告诉团队大部分的敏捷方法，让他们决定用哪些。由于团队是自组织的，他们应该可以决定什么方法对他们的流程最有效，这些决定属于他们自己。”
“我们更倾向于长期采用不固定迭代的流程。”
敏捷为你提供了工作框架，但是不会帮你决定该如何执行项目。它鼓励自组织团队，仔细思考更高效工作的方法，并且只有必要的时候采用，以减少不必要的复杂性。
先进的软件开发团队比以往更加跨学科，流动性更强。成功的团队往往采用混合的方式。敏捷和UX方法都是针对传统方法的缺陷被发明出来的。它们有各自的优点，如果我们能更专注成果而非强调规则，敏捷和UX可以被很好地组合运用。
