在过去的几年中，敏捷已经成为软件项目管理的主导方法。在最近的一项调查中，我们发现69%的用户体验从业者的项目使用敏捷方法。然而，用户体验实践和敏捷工作流并不总是容易地结合在一起，因为敏捷过程最初并没有考虑到用户体验。因此，UX专业人员必须学会灵活，调整他们的过程和工作流，以适应敏捷开发的规则、仪式和节奏。
对于典型的一到两周的敏捷节奏，在这短暂的时间内安排所有需要的用户体验活动可能是一个挑战，所以用户体验实践者经常这样做提前进行一个或多个冲刺对于开发团队来说，要么做研究以发现用户行为并测试原型，要么准备尽可能早于开发团队的执行优化设计。
用户故事、任务和故事点:典型的敏捷工作跟踪单元
在许多敏捷团队中，特性和功能规划都是以用户故事:从用户的角度出发，将每个特性浓缩为对功能的简要描述，重点关注用户想要做什么，以及该特性将如何帮助用户。用户故事的典型格式是一句话:“作为一种(用户类型)，我想要(目标)，这样才能(受益)。”例如，“作为一个支票账户持有人，我想用我的移动设备存支票，这样我就不用去银行了。”
这些用户描述通常被收集到一个待定项中，在那里它们被划分优先级并分配估计的实现成本，因此团队可以计划下一个要处理哪个用户描述(或特性)。对于每个用户场景，团队分配创建和实现所需工作量的估计，通常以故事点．故事点是相对的而不是绝对的度量:它们捕获了一个任务与另一个任务相比应该涉及多少工作(例如，5点故事是2点故事工作的两倍多)，而不是完成任务所需的小时数。
最后,验收标准对于用户描述，清楚地指出描述必须被认为是“完整的”的属性。
在许多敏捷团队中，用户故事并不是最小的工作单元;在这些情况下，用户描述被分解成分配给团队成员的任务。这种方法在许多常见的敏捷项目管理软件包中很受欢迎。
帐户用户体验活动作为用户故事中的子任务
每个用户故事都应该在一个sprint中完成(尽管团队通常一次处理几个用户故事)。然而，当用户体验至少是开发前的一个冲刺阶段时，这种短时间框架对适当的计划和跟踪工作提出了挑战;对于许多团队来说，用户体验活动在哪里适合用户故事的问题变得棘手。
当用户体验工作在用户故事backlog中没有得到恰当的体现时，用户体验工作在团队中就会变得不那么明显，因此团队成员对它的认同也会降低它的价值。由此产生的糟糕的资源和计划会让用户体验专业人员和用户体验设计师过度工作，没有一个清晰的远景会对团队的直接需求反应过度吗忽视大局。
如果您的团队将用户故事分解为任务，请确保将UX活动添加到任务列表中，以便在用户故事backlog中准确地表示UX工作。这样做可以让UX团队成员随时知道哪些UX活动正在进行。它也使即将到来的用户的课题会议对所有团队成员可见，并且可以鼓励开发人员、产品所有者和业务涉众观察测试会议．
这种方法要求团队有一个良好的用户故事计划安排，并且产品所有者、scrum管理员和开发团队要遵守规则，在接下来的几个sprint中保持故事的准确优先级。
用户体验活动作为看板阶段可见
不将用户故事分解为子任务的团队可以使用看板让用户体验工作可见。(看板是一种说明和跟踪任务完成的各个阶段的方法。)用户体验活动应该代表看板中的任务完成阶段。以下是看板上可能的阶段:
- 定义
- 设计
- 可用性测试
- 准备开发人员
- 实现
- QA /单元测试
- 准备好船
- 运
一个任务(或用户故事)必须经历所有这些阶段才能被认为完成。这种看板表示法使得用户体验工作显式且强制性。
虽然这8个阶段的列表适用于许多团队，但不同的阶段可能更好地满足您的需求。例如，一些团队更喜欢一个单一的UX阶段，而另一些团队可能希望将UX活动分解成更低粒度的阶段(例如，需求、工作流、原型、任务创建、可用性测试、分析、迭代、模型创建)，或者对这些阶段进行不同的排序。
将用户体验活动添加到看板中，可以使每个用户故事的状态对整个团队透明，并使所有团队成员在任何时候都有一个平滑的工作流。这种可见性还帮助团队通过重新安排用户描述的优先级、重新安排活动和重新分配工作来响应未预见的挑战。
在用户故事中包括用户体验验收标准
在典型的敏捷过程中，当团队定义用户故事时，他们为用户分配完成或接受标准(“完成的定义”)。虽然验收标准传统上集中在QA(或单元测试)以确保无bug的实现，但它们也可以而且应该包括成功的UX度量。虽然良好的用户体验验收标准可以简单地解决对UI标准的遵守问题(例如“所有UI元素都将遵循团队中概述的外观、感觉和行为”)前端风格指南，或“产品将在10像素内匹配设计模型”)，考虑添加以可用性为导向的措施，如“用户在完成任务A时不应遇到重大可用性问题”。为组织高层次的用户体验成熟度如果管理层对UX团队有很大的信任，甚至可以添加一些量化的度量(比如“大多数用户可以在两分钟或更少的时间内完成结账过程”)作为验收标准。在完成全部量化基准测试通常在敏捷冲刺阶段很难实现，而且一个小型研究的结果可能在统计上不显著，一个高度熟练的UX专业人员仍然可以获得设计是否在正确的轨道上满足需求的感觉。这些标准建立了高质量的标准，并迫使团队在交付产品之前参与总结性的可用性测试。
评估用户体验故事点
大多数以用户故事格式跟踪工作的团队使用故事点来评估工作。然而，因为UX工作通常是在开发之前完成的，我们采访过的许多UX专业人士更喜欢与开发团队分开评估他们的工作。两个工作量评估(一个用于开发，一个用于UX)允许每个子团队有效地工作，并防止其未充分利用;特别地，UX团队可以计划同时处理多少个故事，以及任何需要超过sprint的故事。
在开发人员中，有许多流行的用于评估工作量的积分系统;例如顺序整数、斐波那契数列、2的幂等等。但是在我们的调查中，UX专业人士更喜欢不那么细粒度的格式，比如t恤的尺寸(S、M、L、XL等)。这个系统允许UX团队成员以粗略的方式指示工作，而不影响整个团队的速度度量。然而，值得注意的是，分开的UX点会对团队凝聚力产生负面影响，因为UX最终可能会被视为一个单独的工作单元，类似于在瀑布开发过程中如何看待它。如果您选择单独评估UX故事点，那么目标是最终将UX团队的评估工作纳入主要团队的评估过程中。
结论
集成用户体验和敏捷是一项复杂的工作，但确保用户体验活动在用户故事中体现支持任务计划和调度，并鼓励团队成员之间的跨功能协作。
查阅更多技术和详细解释关于敏捷用户体验的最佳实践，请下载完整报告有效的敏捷用户体验产品开发或者参加全天的课程精益UX和敏捷在UX大会上(也可以作为公司内部活动)。
分享这篇文章: