UX设计师提前完成一个Sprint

我们的用户体验设计师通常在Sprint X中有一个故事，开发人员将在Sprint X + 1中实现（用户体验设计师和开发人员/测试人员在一个团队中）。我认为这是有道理的，因为如果您没有屏幕模型和清晰的规格，则无法在Sprint计划期间真正估算工作。

但是，在Scrum中，您只能拥有能够为用户带来价值的用户故事。在我们的案例中，UX设计故事没有提供这样的价值（它们更像是积压的整理活动）。同样，Scrum教练通常不建议在Sprint开始之前具有完整的规格，这是我很难理解的建议。

那么您认为我们的方法有什么缺点吗？它似乎对我们有用，但是有点违背Scrum原则。

但是，在Scrum中，您只能拥有能够为用户提供价值的用户案例。

价值不是仅以可交付的代码行来衡量的。

您似乎在暗示拥有精心设计的UI不会提供任何价值。当然可以。显然，最终用户具有价值，但对于您的开发团队来说，它也具有价值，这是一个非常有效的利益相关者。如果您没有工具和材料来完成工作，则无法为最终用户提供价值。

不要迷信Scrum教条。Scrum可以帮助您提高效率。如果执行UX故事，则在实现UI之前先进行一次冲刺可以帮助您交付更好的软件，请这样做。

主要缺点是：

1. 您正在流水线：如果您的设计师迟到了，您的开发人员将无所事事；如果您的开发人员迟到了，您的设计师最终将提前进行多次迭代。这不是一个稳定的局面-这是不可持续的。

2. 您的设计师需要提前工作，您需要为可能未开发的故事付费。即使这种情况很少发生，您仍然会浪费金钱。

3. 您的UX设计人员会在不涉及开发人员的情况下提前做出决定。您会丢失有用的见解，并增加设计完全错误或不切实际的风险。这是很常见的，因为UX设计不是“抽象”的练习-必须根据应用程序的特性（包括在技术上可行/建议做的或不建议做的事情）制作出来。

4. 排除或剥夺开发人员的权力不是运行项目的可持续方法。

5. 设计师没有交付价值：这意味着，即使不是不可能，也很难正确地确定其工作的优先级。通常，使用不同的关注点，价值，在下一个sprint中的可行性，工作量来对开发人员的工作进行优先级排序。为了使它们“适合”或进行了有益的讨论，对很多时间故事进行了协商和更改：如果其中任何一个更改了UI（并且您可以假设它只是一个实现细节，就可以做到），您会怎么做有故事吗？你不能再玩了。

6. 您假设一个对于设计师而言可以一次迭代的故事就对开发人员而言就像一次迭代：您如何拆分这些故事，以便这种假设是正确的？

我喜欢它有两个原因：

1. 它似乎为您工作；很难与成功争论！
2. UX团队接受故事并尽早开始对话 -对话是故事的重点

Scrum的基本要求是Scrum团队具有创建潜在可发布产品所需的所有技能。在您描述的情况下，这没有发生。

UX团队不会生产可能发布的产品，Scrum团队无法生产垂直的功能，因为它们没有所有必需的技能。这些是功能障碍。

Sklivvz就上述功能障碍可能导致的问题写了一篇出色的文章。总而言之，我不认为您正在练习Scrum。

但是，这绝对没有错。如果您发现了一种为所有人创造价值的工作方式，并且对此感到满意，请继续努力。我唯一的建议是经常检查和适应。

但是请注意，如果您的目标是使用Scrum交付软件，则需要解决所确定的功能障碍。

这里有两个问题，一个是关于以用户为中心的设计，另一个是关于sprint对齐。

第一：用户故事应与用户需求保持一致，而不仅仅是积压。UX故事需要对用户具有明确的价值。这不需要完整的规范，也不需要简短的说明，例如，

“用户将更容易在单个页面上访问帐户活动，而不是在多个页面之间进行访问”

适用于各种实现，并且仍然清楚用户的价值（更轻松地访问帐户活动）。

第二：冲刺对齐。UX设计了sprint X中的功能，开发人员在春季X + 1中实现了这些功能。实际上，这在许多商店中都会发生，有时可能更像是在Sprint X + 2或X + 3中实现。在紧密而经验丰富的团队中，此设置可以正常工作。如果您有一个不熟悉该团队其他成员的技能，偏好，习惯，工作风格和倾向的新团队或新成员，这将变得充满挑战。如果您在一起工作不到6个月，则可能会遇到问题。

退后一步，然后重新评估。从积极的方面来说，UX设计人员和开发人员可以并肩工作，这是一个福音。首先，请确保您的故事对用户具有明确的价值。

我看到的一个可能的问题是，在Scrum中，sprint N + 1的范围通常在开始之前就已确定。因此，在知道哪些故事属于范围之前，如何在sprint N中为sprint N + 1故事执行UX。如果您决定在Sprint N的开头修复Sprint N + 1的范围，则会失去一些灵活性。

但是，在Scrum中，您只能拥有能够为用户提供价值的用户案例。在我们的案例中，UX设计故事没有提供这种价值（它们更像是积压的整理活动）。

从我的角度来看，他们为用户提供了很多价值。问题是：他们的用户不是公司的最终用户，他们的用户是将在sprint X + 1上实现该功能的开发团队。

您一直陷于流程的束缚之中，并且一路走来，我发现Scrum /敏捷被滥用和用户贴错标签。Scrum不是通用工具，而是达到目的的手段。

我认为您的小组误贴了您的用户身份，并正在为错误的受众群体做计划。

UX小组以经典方式使用Scrum，用户价值和对某些不可思议的最终用户输入的敏捷适应。他们是有用户的。您的团队滥用scrum的原因是，您只是在填写机制以进行现有的设计工作，不需要任何敏捷，并且scrum扮演着管理跟踪的角色。

这就是为什么对您来说这是错误的，您实际上并不需要任何Scrum或从中受益，因为您属于服务组，并且您的工作从已经做过敏捷/ Scrum部分的UX人员进行。

那里没有什么不好的，只是有一个不同于您所告知的过程。