谁在S​​crum项目上使用UX？

好。假设您正在从事教科书Scrum项目。您有一个Scrum主管与产品负责人合作。接下来的冲刺是UI重-你的程序员开始构建屏幕的时候，你真的想有一些想法，他们打算什么样子。

谁来做线框图，何时做？产品负责人？有人支持产品负责人吗？Scrum高手？如果您有UX专家，他们是在冲刺开始后与编码人员一起工作，还是他们在故事卡和约束条件旁边预先提供了线框和模型，以指导和告知开发人员正在进行的工作？

我很确定我们需要一些UX帮助，但是我真的不确定在哪里应用它。

编辑：让我改一下这个问题。

您如何在敏捷项目中提供一致的高质量用户体验？

互动设计师

UX！= UI您需要一个经验丰富的交互设计师来提供良好的用户体验，这与非程序员的普遍看法相反。对于所有认为自己可以进行UX的程序员（包括我），让我这样说。精通交互设计至少需要与精通编程一样多的时间。您花了多少时间进行纯交互设计？

在初始阶段，交互设计师的职责是：

1. 从产品负责人那里提取解决方案的实际目标
2. 定义将使用解决方案的角色。
3. 编写有关如何使用该解决方案的故事的方案。
4. 编译设计文档，从UX的角度来看，几乎没有歧义的余地

在项目进行期间，交互设计师的任务是确保遵循这些指南并解决可能出现的其他问题。

我敢肯定，许多程序员都会采用这种方法，因为每个人都认为他们是可以设计“出色”接口的例外，您可能并非如此。另一方面，良好的交互设计者与程序员的关系通常对程序员而言非常好，而且他们不必与“愚蠢的规范”作斗争。不幸的是，在我的经验中很难找到好的交互设计师，但是他们在那里。

一如既往，我强烈推荐有关该主题的Alan Coopers书籍（“关于面孔”和“囚犯正在庇护中”）

我建议以与团队其他成员相同的方式来组织UX人员的工作。应该将他视为团队中的平等成员，参与站立，并与程序员紧密沟通。

理想情况下，应至少提前一个冲刺完成模型，但对于较小的功能，可以考虑将模型作为当前迭代计划的故事的子任务来创建。

与敏捷一样，使用常识，尝试不同的方法，并坚持适合您的特定情况的方法。

我认为这是某种特殊情况，必须以特殊方式处理。Scrum主管绝对不会参与其中-根本不是他的角色。团队通常是一组开发人员，其中大多数没有UX经验，将其浪费在强迫他们上的时间。您将聘请UX专家，而该专家将不会成为团队的一部分-团队应该具有跨职能部门，UX专家可能不会成为开发人员。同样，UX专家在整个项目期间都不会参与。UX专家将与产品负责人一起向前冲刺，以准备用于向上传播用户故事的模型和线框，以便团队知道在下一个冲刺中将要完成的工作-在计划会议期间将提供模型。

编辑：

我做了一些其他的研究，因为我知道我在某个地方读到了有关内容，最后在Mike Cohn撰写的《敏捷：使用Scrum进行软件开发》中找到了它。Mike讨论了UX设计师在团队中的确切角色。他的最初描述与我的相似，当公司将开发方法从瀑布式更改为Scrum时，他认为这是自然的转变，但后来他得出结论，这是不推荐的方式。原因是，如果UX设计师不属于团队，则可以将自己视为独立的团队，而不必共享开发团队的投入。

尽管如此，@ Adam Byrtek的回答看起来还是正确的。将UX专家加入团队，让他与开发人员就当前实施的用户案例进行合作。UX专家不会花所有的时间，因此他还将与产品所有者或客户合作，准备模型和线框以应对一两个冲刺。

我订阅了雅各布·尼尔森（Jakob Nielsen）的警报框（主要是因为他对烦人的Web设计实践的批评），而且我还记得最近我读了一些有关该主题的文章（尽管我对整个敏捷开发过程几乎没有丝毫了解），也许他们会对您有任何用途：

• 敏捷的用户体验项目
• 敏捷开发项目和可用性

对于“教科书Scrum”：

首先，Scrum Masters不会与产品负责人进行合作-绝非任何意义，而是包括SM和PO在内的整个团队都在合作来构建系统。

其次，Scrum团队应该与跨职能的团队成员保持一致。因此，您将不会有“ UX Guy”。

同样，您可能不会在功能代码之前构建UX Sprint。功能在单个Sprint中完全交付。如果与功能相关的UX太复杂而无法在单个Sprint中与功能代码一起交付，那么您可以将整个功能分解为可以完成的事情，包括在单个Sprint中的UX元素。

UX在瀑布项目上由谁负责？谁在XP项目上开发大型机？

项目方法无关紧要。每个技术项目都需要某些专门的角色。有时，没有完整的许可和约束的“交互设计器”（无论意味着什么），一个项目可能就无法实现。有时您确实需要专门的人。但是对于其他角色也可以这样说。

第二个问题是如何使用敏捷来提供高质量的用户体验。在我参与的最后一个Scrum项目中，我们通过尽早并经常让业务分析师和客户参与来管理它。另外，我们有一个特别重视UX的开发人员。他倾向于对开发人员在完成提交后正在处理的UI进行细微调整。

在每次冲刺结束时，我们都没有提供完美的用户体验。从UX的角度来看，这些演示通常会暴露一两个问题。但是我们为下一个冲刺修复了它们（如果它们对客户有价值），并且当我们发布产品时，我们已经有了非常可靠的用户体验。

如果用UX来表示用户界面设计师，那么它们只是团队的另一个角色或资源。像任何设计一样，用户界面设计贯穿整个项目。有大量的体系结构/设计工作应预先完成，并且随着您的前进，可以完成大量的工作。

应该注意的是，UI设计任务通常不适合与开发冲刺相同的范围。在设计UI组件时，该设计可能需要大量的sprint来实现。

在实践中，我倾向于发现UI / UX设计人员需要合理的交货时间来处理在整个解决方案中必须保持一致的方面。我喜欢将其视为软件体系结构。特定的组件设计通常可以在实施之前进行一次冲刺，但是我倾向于发现，一旦设计者开始实施，他们就可以远远超过实施的步伐。随着解决方案开始成形，以后的sprint往往是实现/探索外观和获得可用性反馈的好地方。这些后续练习的结果将反馈到下一个冲刺的计划中。