我们应该如何处理Scrum冲刺中的其他外观特征？

我正在阅读Scrum文档，它说Sprint中的任务应该是“潜在的”。

我对这意味着什么感到困惑。假设在Sprint 1中，目标是“用户注册表”。

我需要添加多少细节才能准备好发货？例如：

1. 我可以使用没有任何花哨样式的字段来显示简单表单并将其标记为完成
2. 我可以将客户端验证标记为已完成，但是服务器端也可以选择这两者
3. 我还可以为表单添加一些jQuery花式工具提示，鼠标悬停，验证码，颜色，标签
4. 然后有很多关于如何在屏幕上显示错误消息的样式

我可以在一个主题上无休止地做。因此，我们如何进行划分以及何时可以将其视为已准备好发货。

还是我需要写一些最小的东西，例如将错误，弹出窗口或灯箱文本显示为子任务，然后将它们作为sprint。这将导致整个项目执行数千个任务。

我的意思是再说一次，如果Internet Explorer和Firefox都可以使用，那么我也需要将其划分为任务。必须花时间在上面，当经理问我您当时的工作时，我没有任何要说的任务，但实际上，它们都是用户注册的一部分

与产品负责人和Scrum团队（而非互联网）达成协议。这应该在您的“完成的定义”中确定，并且在很大程度上取决于团队的工作方式。

尽管该功能应该是“可运输的”（我讨厌在Scrum中使用该术语），但可以说该功能在没有UI的情况下是可运输的。许多人在Scrum中遭受这种误解-冲刺的目的是获得尽可能多（理想情况下）“完成”的故事，但绝对不需要将其构建为可以发布的内容。

尽早解决此类问题很重要，因此团队中的每个人都为实现一个共同的目标而努力。Scrum的精神是沟通，因此请Scrum团队并得出一个合乎逻辑的结论。

您可能会在通常由单独的团队处理UI的团队中工作，例如，由不同的团队或由UI专家决定表单的外观等。或者，在一个小型项目/团队中，可能期望UI可以像您一样构建走。

只要团队都知道答案，答案是无关紧要的。

如果装饰性特征是特征的一部分，则可能应将其作为故事的一部分。关键是，一旦您说完一个故事，就不必对特定功能进行更多编码。虽然，最终这是由产品所有者决定的-他们可能想要装饰性的外观，也可能不需要。这应该在验收标准中阐明。

那并不一定意味着它已经准备好供最终用户使用，只是意味着它已经为某人准备好了。有人可能是测试人员，也可能是另一个团队，例如后端团队。

如果您以开发人员的身份提出要求，答案将是“您知道，因为产品负责人会告诉您他们是否需要装饰性特征”。

如果您以产品负责人的身份询问，则只需确定是否要将功能分解为多个故事即可。除了满足您的要求之外，没有其他要求可以满足您的客户。

请记住：目标不是严格遵守Scrum。目标是向最终用户提供高质量的软件。遇到此类问题时，请以此为指导。在与纯功能零件相同的故事中添加化妆品是否可以帮助您向客户提供质量代码？或者，将其分为两个故事会有所帮助吗？答案很明确，或者没关系，您可以为团队做任何可行的事情。

“潜在可运输”是指不一定可运输的东西。例如：

在某些情况下（例如学校项目），看起来很糟糕且未经现场验证的网络注册表格可能还可以，但在一项价值数百万美元的业务中，该商标可能会损坏该品牌以向最终用户展示。该代码可能是可移植的，而不是您想要发布的东西，或者营销或法律允许您发布的东西。

即使是由于某种原因，它永远不会像这样被释放，程序员（和目前处于开发过程中的其他人，例如设计师）也很乐意按现在的状态发布。必须先翻译成其他语言，然后才能运送给任何人-加拿大对政府购买软件的规定严格，该软件应同时考虑法语和英语。

这是一个质量检查点，您看着每个人的眼神，问他们是否愿意按现在的样子运送它，而无需进行额外的工作，也无需检查他们是否做了最后一件事。我听说这叫飞机工程师检查站。您看起来像工程师，问他们是否愿意陪您参加试飞。

这个想法是尽可能地敏捷。您可以更快地将信息发布给真实用户；无论是选择个人代码的Beta版还是您网站上的A / B测试，效果都更好。如果您向用户显示的代码过于粗糙，如他们对产品的期望所定义的那样粗糙，那么他们将给您无用的反馈。他们会谈论您不需要查找的信息，例如：他们不喜欢按钮为黄色或文本框未与标签对齐。如果足够好，那么您可以获得有用的反馈。越快获得此反馈越好！您可以验证产品/市场适合度，以及对尝试构建的功能所做的假设。

交付功能是最不重要的部分。移动开发团队并完成用户故事很重要。达到可以要求完成某件事的地步是一个很大的动力。

以我的理解，每个故事都应该是“可完成的”和“可交付的”，以使其可以被某人（不一定是最终用户）消费。因此，您的故事可以提供一些功能，然后可以将其提供给产品所有者，他们可以选择将其发布给最终用户，或者再次迭代该功能。

就是说，您不排除将样式包含在“作为最终用户，我将能够注册”的故事中。在我们的团队中，我们试图使每个故事尽可能小，以保持较高的可预测性并更好地确保我们能够兑现我们的承诺。如果我们已经预先准备好设计并且认为应用起来很简单，那么它就包含在故事中。如果我们认为设计上可能会有一些迭代，那是一个单独的故事-可能是多个故事。

除了此问题的其他出色答案之外，您还可以将外观特征视为scope-resources-time三角形的变量scope部分。确保您满足该故事的基本要求，如果有时间，请添加漂亮的内容。

Scrum不能保证在给定时间内交付某些功能。它应该为您提供在给定时间内可能的最大有用工作。如果“可选”美容功能没有得到这样的冲刺过程中完成，它应该是因为他们是不可能的。

它取决于设置需求的人，即“产品所有者”。作为一名程序员，我可能会对无样式的“注册表单”页面感到满意，该页面仅证明了Web服务中的业务逻辑可以正常工作，并且注册使您可以针对系统中的其他资源进行身份验证。实际上，“潜在地可移植”（不一定暗示我们实际上是将其运送给客户）可能使它成为该主题的第一个用户故事的结果，尤其是在技术团队和设计团队是拥有单独积压的独立资源。

在更成熟的项目中，您可以将具有最小样式的“开发人员设计”版本的功能发布给试验或Beta客户端，但要重新访问该功能以进行功能修改（基于反馈）和设计完成。

敏捷方法论的目的是让您的需求驱动软件开发过程，而不是相反。不要陷入认为方法论的一种描述是“真正且唯一的正统要求”的陷阱。当然，说起来容易做起来难，特别是在您所在的大型组织中，Scrum已成为在开发团队中施加混乱的借口。