我们的Scrum团队由通常的Scrum角色组成。我们没有UI / UX设计器，开发人员与产品所有者一起使用UI / UX。这是一个问题。每次我们要创建积压订单时，我们都没有在sprint开始之前定义确切的UI / UX设计，我们最终在sprint中花费太多时间试图确定UI / UX设计。

对于功能的分析和架构，这是完全正确的。您是否认为应该在sprint开始之前将有关功能的所有可能的细节都提供给开发人员，或者这应该是功能内的任务？我们已经对此进行了体验，它导致了一些没有任何标准的未定义功能。

首先：看看这个不错的演讲，弗洛里安·哈斯（Florian Haas）在FROSCON（GER）上发表了讲话。这完全是关于进行Scrum的实际不可能。

的好消息：由于Scrum是不可能实现的，你可以自由地做你想做的。

在坏消息：不要叫那个争球。

这使您摆脱了以下问题：“我在做Scrum权利吗？”（答案：不，您不这样做），您可以继续解决生活中的实际问题。

我们没有UI / UX设计器，开发人员与产品所有者一起使用UI / UX

这是一种常见的情况。但是AFAIR的竞争是反对专业化的：每个人都应该具有相同的技能，并且可以互换工作。

每次我们将要创建积压订单时，我们都没有在春季开始之前定义确切的UI / UX设计，因此最终在sprint中花费太多时间试图确定UI / UX设计。

是的，我现在的情况太好了。我曾在一个团队中工作过，在那里我们不得不处理非常广泛的待办事项，例如»作为用户，我想查看信息x «，仅此而已。然后，该项目落在冲刺板上。一个开发者接手了。解决了。实施后，进行了第一次同行评审，并在此开始了关于UI外观的讨论。

然后进入“质量检查阶段”，讨论重新开始。

冲刺之后，我们按照Scrum的要求进行了审查，在该审查中，设计被PO撕裂了。不幸的是我们的客户没有进入评论，因此他当时没有看到该软件。

但是随后循环又重新开始，直到满足PO。

然后是客户...

从这个战争故事中您可以看到，这种（特殊类型的）过程非常无效。

最终，对我们有用的是将混乱抛诸脑后。

但这不是您问题的解决方案;）

您是否认为应该在sprint开始之前将有关功能的所有可能的细节都提供给开发人员，或者这应该是功能内的任务？

解决此难题的方法将涉及a）客户本身与PO之间的紧密反馈环，因此制定的标准相对严格。b）Scrum团队和PO之间紧密的反馈回路，以最大程度地减少上路的机会。

我会打破一些（更多）混乱规则来定义一个backlogitem：一个“正在工作的假人”。PO和客户可以对其进行快速审查，以最大程度地减少在简单项目上花费的开发时间。

tl; dr

Scrum团队应该输入什么？

在尽可能短的时间内提供足够的信息来满足规格要求。

无关：

我们不再做混乱了。我们不做估计。我们保留了冲刺板。我们不做冲刺。我们开发功能/修复错误并尽快发布。实施新功能后，它们会尽快进入公共服务器，在该服务器上我们可以与客户尽可能紧密地讨论进一步的设计。

规范的答案是“做对您有用的事情”。

Scrum是敏捷方法之一。它经过明确设计，旨在更改并适应您的团队和项目。您的重点应该是：

通过流程和工具进行个人和交互通过
综合文档工作的软件通过
合同谈判的客户协作
响应计划变更（敏捷宣言）

这不是您的团队应该从故事开始什么的问题，而是有关您的特定团队可以使用什么输入来解决特定业务需求的问题。

以我的个人经验，这取决于业务目标。UI / UX研究和完整设计已经附带了一些故事，这没关系。有些故事带有模糊的要求，因为业务只需要解决一个问题。也可以

当然，还有其他因素。就像您的设计师是开发团队的一员，还是市场，产品开发等。诸多因素。只需做些满足业务需求，灵活的事情，并确保在回顾过程中讨论这些事情，并根据需要调整流程即可。

我也曾受到开发商的类似推动。从他们的角度来看，问题在于他们对UX部分可能要花多长时间保持警惕。如果他们同意尝试在一个sprint中交付N个故事，但是由于在UX上来回操作，某些故事花费的时间比预期的要长得多，那么他们会觉得它对他们的反映很差。

对我们有用的是：

1. 有人与产品负责人一起创建要开发的屏幕的模型。这些内容会在通常的故事提炼过程中进行审核，然后再将故事拉入冲刺，这将使每个人都有机会进行诚实的讨论。
2. 不要在编码之前尝试定型设计，而要把它拿出来，然后就需要更改的内容进行讨论。这样，更改的成本就更加清晰了，这有助于产品所有者/客户确定是否值得。
3. 产品所有者/客户与开发人员之间的信任。最后，每个人都在努力向客户交付东西。PO不允许抱怨团队没有从冲刺中交付一切。开发人员不能故意阻挠，因为他们担心无法交付。
4. 实践。我们只是更好地估计了故事的大小，并能够发现可能的问题。

Tl; DR：在编码之前不要完全定义UX。等到用户看到它并玩它。

您是否认为应该在sprint开始之前将有关功能的所有可能的细节都提供给开发人员，或者这应该是功能内的任务？

简而言之，如果产品所有者不能在冲刺之前交付ui / ux设计，则ui / ux的开发应该是故事，而不是任务。

您的sprint可交付成果不一定总是要具有工作代码，团队本身可以成为故事中的“谁”。您可以遇到一个故事，例如“作为开发团队的成员，我们需要UI原型才能实现UI”。然后，您估计团队将花多长时间交付模型，这成为您研究的第一个故事之一。

您不必拼出UI，只需要接受功能请求（故事）并在知道必须考虑UI的情况下对其打分即可。让客户端指定UI会带来麻烦。

现在您已经知道UI会花费您一些时间，您应该可以更好地计划，下一次执行包含UI工作的任务时，将为其分配一些额外的故事点。

如果您是Scrum，那么任何人都可以成为UI / UX设计师。

UI / UX不应该是事后的想法。它应该是可交付的。它应该由您的产品所有者批准。交付时，即使仅作为gif，也应显示。

这并不意味着它不能改变。这会经常改变。您也希望早日得到反馈。不要让代码驱动UI设计。让客户来驱动它。仅在客户要求魔术时才回推。否则，只需让他们知道他们要求的工作量以及这将花费多少。

唯一最终确定的UI / UX是在已失效的软件上。

根据您的评论：

“它应该由您的产品所有者批准。” 这正是出现问题的地方。在此批准流程上花费了大量时间，我们最终花费了几天而不是最初估计的几个小时。- 拉希德

消除一切不必要的会使您慢下来的事物。

你有个主意 告诉产品负责人。他们应该坐在你旁边。

他们讨厌吗？继续。爱它？做吧 不懂吗 让他们看。

短期频繁的不定期会议。谈论。在白板或纸上涂鸦。使用屏幕快照模拟绘画程序。快速交流，批准，实施和审查想法。

如果产品负责人不在身边，请找一个方便的人问他们。开始迭代所需的一切。请尽快与产品所有者联系。

不要花一秒钟使它变得漂亮。讲到重点。保持您的想法小巧和渐进，您可以在任何人甚至要求做出估计之前就完成工作。

在我的经验中：

• 太少的前期分析会导致效率低下的从头开始开发
• 过多的前期分析导致分析瘫痪（Sprint从未启动）

我们所做的：

• 定义一些“ 准备开发 ”标准
• 对于UX故事，这可能是“我们的线框已为团队所熟知”

在Sprint计划期间：

• 所有未准备就绪的故事都将被丢弃（它们会对团队造成破坏性影响，请返回进行更多分析）
• 任何边界故事都被宣布为“高风险”，并在冲刺开始时进行
• 众所周知的故事已被估计并允许进入Sprint

该系统使我们能够将每个Sprint的大部分献给执行，即我们的工作效率更高。

Scrum中的任何任务都必须对所涉及的全部工作进行估算，并且要有可验证的结果。

如果我将一项任务放到您的Scrum中，“带有产品经理满意的用户界面的实现功能X”，那将得到可验证的结果，但是显然无法估计所涉及的工作量。因此，无法合理地完成这项任务。

现在，我将一个任务放入“为功能X设计用户界面”中。可以估计，结果是可验证的。在Scrum中这是一项确定的任务。任务完成后，就完成了。

现在，一旦任务完成，您的产品经理可以说他不喜欢结果。没关系。Scrum中有一个任务，您已经完成了，那就是您的工作已完成。他可以将另一个任务放到下一个混乱中。也许还有一点指导，他实际上想要什么样的用户界面。那是他的工作。设置可以产生有用结果的任务。有时很难，工作完成了，结果证明是无用的。这就是为什么他们称其为“敏捷”。完成的任务原来是无用的，然后您转向了更好的方向。

此外，UX设计（尤其是优秀的UX设计）对于实践UX设计的人来说是一项全职工作。许多优秀的软件开发人员可以在创建UX上做得不错，但是他们做起来却不如优秀的UX设计人员那样好，而且成本效益也不高（如果可以的话，他们会创建UX设计而不开发软件）。因此，没有UX设计器是无效的-这又是产品所有者的问题。

我不确定您是否遵循敏捷原则，但是这是应该如何处理的。

在开始冲刺之前，我们没有定义确切的UI / UX设计

目前的目标不是完美。获得尽可能多的需求输入，以便开发人员可以构建一些与要求尽可能接近的内容。不要进行大量调整或尝试设计未要求的东西。您会浪费时间。

我们最终在冲刺过程中花费太多时间试图完成UI / UX设计。

确定何时完成工作的方法。我有一种感觉，有人正在继续对UI / UX进行很多来回评估。太多的人对UX / UI有意见，而客户端没有提供任何证据来支持他们的假设。

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

这种事情可以永远持续下去。这不是Scrum的缺陷。在冲刺期间有人在干预需求。重新确定客户的需求，确定需要多长时间，并与他们一起确定优先顺序。如果他们认为这会花费太长时间，请问他们要摆脱什么。

有一家公司设计徽标需要支付一定的费用。他们限制更改请求的数量，因为他们知道某些客户将因所有更改一千次削减而将他们杀死。停止它或充电更多。这就是所谓的生意。