Scrum：用户故事的设计/ UX是否可以在与实现相同的冲刺中发生？

我目前处于冲刺阶段（两个星期），设计师负责定义特定用户故事的需求和用户体验。

在同一个Sprint中，我要实现此设计。在sprint计划期间，我不得不对这个不确定的用户故事需要花费多长时间进行大胆猜测。

今天，我终于收到了设计。不幸的是，设计是不完整/模糊的，比设计更类似于客户的要求。但是，从这一点上，我仍然可以看出，我的估计还不够。

更糟的是，这不是第一次。在最后的冲刺中，发生了完全相同的事情。我在回顾中标记了它，Scrum主管没有解决该问题的答案，而是说“这只是您的发展”。具有讽刺意味的是，如果烧毁没有达到目标，他会感到恼火。

现在，我将不得不咨询/与设计师合作才能完成工作。当我完成所有其他任务时，这将使我受挫。

所以我的问题是

您如何处理Sprint计划中的依存关系？

理想情况下，非开发依赖项是在冲刺计划之前处理的，这样您就可以很好地定义积压项目以估算工作量。

但是，如果那是最后一次冲刺“只是为您开发”，那么这可能只是该冲刺对您的开发，因此您确实应该在那里增加估算，然后处理处于类似状态的即将到来的任务。这并不算是报仇，而让它照搬过来将是一个错误。

它所做的是显示估计的不确定性，而无需进行相对可靠的设计。也许，这将鼓励您的经理确保正确定义产品待办事项。但最糟糕的是它会遮住您的背部。当预算不足时，没人会抱怨。

但是，您没有这样做，现在的问题是...

我现在应该如何处理冲刺？

Scrum作为项目管理工具的全部目的是尽早发现问题，这已经完成。将其标记给您的管理层，让他们决定如何处理sprint。如果他们试图责备您，请谦虚并问他们将来如何建议您应对类似情况，以免发生相同的问题，即使您并不真正相信这是公平的。

归根结底，这些都是项目管理问题，如果您试图在自己的泡泡中解决它们，那么您将自己设置为失败。而且，当您这样做时，您会很生气，因为它会落在您身上，而不是落在您将问题举报给他们时未能解决问题的经理身上。

首先，故事/任务之间的依赖性与故事/任务的范围/努力的不确定性之间存在很大差异。

相关性是通过给从属任务/故事的优先级比任务/故事这取决于和可能的注释，其他任务/故事完成之前不能开始处理。

在计划会议中，应通过澄清故事中需要完成的工作来解决不确定性。如果无法消除足够的不确定性，则该故事很可能不符合您的“就绪定义”，因此不应将其纳入冲刺。
如果出于某种原因，故事确实需要进入冲刺阶段，那么剩下的唯一选择就是为估计添加风险缓冲。

对于当前的Sprint，如果您无法处理故事，则只需在下一次日常会议中报告，并尽一切可能实现团队的总体Sprint目标即可。您还可以将故事注释为受阻或受阻。
冲刺开始后，原则上不可能向冲刺添加新任务。
同样，如果一项任务的工作量超出预期，那么您无需更改估算值，但可以如实报告工作进度和剩余工作量。

最后，在Scrum中，承诺提供某些东西的是团队。如果不能兑现承诺，那就是整个团队的失败，而不是团队中个人的失败。

在sprint计划期间，我不得不对这个不确定的用户故事要花多长时间进行大胆的猜测。

那是你犯的错误。没有人可以强迫团队在sprint中接受任务，而您的工作是声明除非至少存在线框，否则无法在sprint中估算和接受任务。您的Scrum管理员似乎实际上是项目经理，这只会使事情变得更糟。

如果有必要在sprint中完成任务（出于有效的商业原因），该如何处理？好吧，首先您必须设置设计的截止日期，在那之后您将无法实现它。例如：故事已被接受，但设计应在第一周内交付，并在第二周内实施。接下来，您必须与设计人员紧密合作，以确保可以在sprint中实现。Scrum承担跨职能团队，由您决定与设计师一起组织工作。话虽如此，如果您接受sprint中的任务-由团队决定，则取决于团队在sprint中完成工作的方式来管理工作并管理相关的风险。您不应该等待另一个人完成他/她的工作来完成工作。您可能会暴露出组织中更大的功能障碍。

设计任务是否表达为故事，您团队的定义是什么

• 故事准备好了
• 一个故事完成了

每个故事都应该有自己的接受条件和接受条件，但是我认为最好有一套适用于所有故事的规则。例如，如果（且仅当！）一个故事已准备就绪：端到端体系结构研究完成，设计可用，团队已对故事进行了评估。接受的最小条件可能是：完成自动测试，确定并且已经集成到测试套件中，完成了代码审查。

如果故事还没有准备好，请不要将其嵌入到您的冲刺中。如果不满足接受条件，那就还没有完成。

在您的情况下，团队可以决定要准备就绪，开发故事需要具有完整的设计（至少是线框，请根据您的实际情况进行调整）。如果是这样，您将无法在同一个Sprint中处理设计和开发。团队还可以决定，UX /设计故事至少应能完成线框设计。如果不是这种情况，那么该故事将不被接受，因此无法启动取决于该故事的故事。

您应该轻松地使您的经理相信，有强有力的准备规则是一件好事：在sprint期间重新评估复杂性是一个坏习惯。这意味着团队的速度是不确定的，然后他们作为经理对团队的工作和未来抱有不好的眼光。

通常在故事清楚的时候开始冲刺-在此阶段，建立产品待办事项列表并确定优先级。如果您没有设计就开始设计，那么应该很清楚没有设计就可以做什么，没有什么可以做...

如果您需要在客户和PO之间“颠簸”设计时即兴进行，则您的PO必须在出现任何新功能时立即通知团队：这是Scrum中“灵活性”的含义-适应进行中的情况。开发团队，Scrum负责人和产品负责人需要永久沟通，否则对更改没有实时反应。

接受更多培训不会有害……也许与设计师合作将是您获得一些新UX技能的机会？...观察到玻璃杯已装满，而不是半空:)）