UE设计中将UX工作整合到您的敏捷积压中

关于敏捷积压，没有明确的规则手册-每个团队可能会以不同的方式构造其积压。在其核心，这是一个很好的事情：每支球队都有自己的工作，所以一个尺寸适合所有的过程是不实际的方式。但是，由于这种灵活性和缺乏官方规则，因此有时会忽略UX。

定义：一个积压是要完成项目的有序列表-包括功能，更新现有功能，bug修复，UX债务，或其他活动-该团队计划提供完成一个项目。

敏捷积压

在大多数敏捷团队中，功能规划以用户案例的形式记录在案。为每个用户故事提供了接受标准和完成它们所需的估计工作量，然后根据利益相关者，业务和开发团队的需求对故事列表进行优先排序。

优先级是任何敏捷团队的重要任务，因为它确定了将在给定的sprint中完成哪些用户故事。根据您的利益相关者对UX的价值的信任程度，可以优先考虑代表UX工作的用户故事，而优先考虑以开发为中心的用户故事。

积压结构

敏捷团队经常面临困境：他们应该使用一个包含UX工作的积压还是使用与开发用户故事分开的专用UX积压？

遵循一个统一的待办事项或维护多个待办事项，这两种方法都可以成功，具体取决于实现方式的细微差别。关键是要了解您的团队如何合作以及您的利益相关者对积压的影响。让我们看一下这些不同积压模型的优缺点。

统一积压：同一积压中的显式UX和开发项目

统一的待办事项存储产品的所有工作，包括开发任务，UX活动和QA任务。 

统一积压中的sprint示例：项目可以与UX相关或与开发相关

在此积压示例中，冲刺由4个积压项目组成，每个项目都有其相应的故事点估计。突出显示的项目“ 原型：过滤增强 ”是特定于UX的项目，涉及构建和测试原型。

吉拉积压

Jira Software：积压的项目可以标记为UX，以帮助团队区分多种类型的工作。

统一积压中包含明确的UX特定项，UX工作的优先级和估算与积压中的其他任何事物一样。使用标签，特定任务名称（例如，以字符串UX作为前缀）或使用产品管理软件中的专用功能（例如，标签或类别），将UX待办事项与开发项目区分开。

优点

这种方法使UX工作对团队及其利益相关者可见。每个人都可以查看待办事项，知道需要完成哪些UX工作。在产品管理软件中使用标签将使UX项目易于过滤。

与UX相关的积压项目通常是大型的常规任务，而不是小型的特定任务 -对于试图设想整个工作流程或交互作用而不仅仅是一小部分的设计人员而言，这是一件好事。敏捷积压中的用户案例通常是特定的，并且设置为在单个冲刺中完成。但是，我们经常必须考虑更高级别的UX工作，以确保我们在整个应用程序中保持一致性，并且我们的设计适应应用程序的更大视野。使用明确的特定于UX的待办事项不会限制UX工作的范围。

缺点

利益相关者可以优先考虑UX项目，而倾向于使用新功能-尤其是如果他们在UX研究中看不到价值的话。如果发现您的利益相关者一直在优先考虑与UX相关的积压项目，则可以尝试本文稍后介绍的其他两种积压方法之一。

跟踪依赖关系可能会更加困难。某些特定于UX的项目可能会影响其他积压项目，这意味着您需要确定首先需要完成的工作。如果您在产品管理软件中使用标签或类别，可能很容易避免这种情况。但是，在可以对积压项目进行适当的UX工作之前，请特别注意其依赖性，以避免开发工作在积压项目上。

基于任务的统一待办事项：在待办事项项中表示为任务的基于角色的工作

组织积压工作的第二种方法是让每个项目分解为针对不同团队能力的一组子任务（例如UX任务，开发任务）。

统一积压的示例，其中每个项目都分为分配给不同角色的多个组件

在此示例中，待办事项“ 筛选增强”项细分为4个子任务-一些用于UX，一些用于开发以及一些用于质量测试。当所有这些子任务完成时，积压项目被视为已完成。

在这种方法中，UX任务被添加到任何需要 UX工作的积压项目中。UX任务的示例包括研究，设计和可用性测试。

优点

当可以在单个sprint中完成设计和开发时，此方法最有效。当团队正在处理一个易于理解的领域以及较小或集中的设计问题时，通常就是这种情况。由于团队的所有成员都同时完成工作，因此团队需要确保UX工作不会妨碍团队的其他成员取得进展。

很容易看到每个积压项目需要完成的检查清单。团队中的每个角色都有与待办事项相关的任务；因此，与混合项目统一积压相比，跨不同类型工作的依存关系将更容易识别。还可以更好地跟踪尚未完成的内容。

缺点

团队需要熟练地估计积压项目。由于您将在同一个积压项目上拥有多个角色，因此估算可能会造成混淆。一些团队喜欢将Planning Poker或Fibonacci序列用于开发项目，而将T恤尺寸用于UX工作。

T恤尺寸估算

估算T恤尺寸时，较小的项目可以快速完成，而无需进行大量测试，而较大的项目将花费更多时间，并且可能是冲刺中唯一完成的项目。

根据任务的进度，您有可能会在sprint到sprint之间携带积压的项目。例如，如果合并用户反馈是直到sprint结束才发生的UX任务，则相应的开发任务可能会过渡到下一个sprint，这也将携带整个待办事项。

多个积压

最后一个积压模型是维护多个积压，每个能力一个积压—例如，UX积压和主要开发积压。通常，仅在您尝试了其他两个模型后，我才建议使用此模型，因为维护大量积压工作需要大量的纪律和沟通。对于孤立的UX团队或具有多个UX专业的团队，此方法也是理想的选择。

UX待办事项示例，其中仅列出与UX相关的任务

在此示例中，产品积压和UX积压是独立的。UX待办事项由与UX相关的任务组成，这些任务基于产品待办事项中的待办事项项目创建。

仍然会有一个主要的产品待办事项列表，其中包含您的所有新功能，反馈，错误等。您单独的UX待办事项将包含所有不同的UX活动。您和您的产品所有者将有责任确保您在正确的时间进行正确的事情。有时，UX可能需要在团队其他成员之前完成一项工作，以使开发能够继续进行完善的解决方案。回到上面的示例，如果您在sprint 3的产品积压中看到新客户警报，则需要确保在开始开发之前就已完成Design Sprint：新客户警报。

优点

UX完全负责自己的积压工作。UX团队正在决定需要做什么以及何时完成，并且可以为即将到来的积压项目进行计划。同样，由于UX在开发之前就可以工作，因此将开发人员拖入冲刺的风险也较小。

单独的UX待办事项可以扩展到多个工程团队和UX专业领域。如果您的组织有一个拥有多个专业的大型UX团队，则每个人都可以从事与其专业相关的任务。此外，如果您的组织有多个工程团队从事同一产品（例如iOS，Android和Web团队），则所有UX任务都可以保存在一个积压中，以帮助维护所有团队的一致性。

缺点

衡量团队整体速度很困难。由于UX是通过单独的积压工作的，因此它的速度不会与开发团队的速度结合在一起。（有些团队不将UX作为他们团队速度的一部分，因此这方面可能对您不利。）

有可能工作太遥远。当您为产品待办事项进行提前计划时，建议您将大部分精力集中在当前和下一个冲刺中的项目上。如果您的团队除了进行初步研究以外还需要进一步的工作，那么在项目被取消优先级的情况下，很可能会失去工作。

结论

您的积压结构可能因团队而异，因项目而异。关于积压的伟大之处在于您有能力并且需要保持灵活性。在找到适合您团队的东西之前，不要害怕混合使用不同的方法。