我第一次使用Scrum和一个小团队，我已经通过许多演示文稿和文档解释了这种敏捷方法，但我仍然不知道应该是什么要求以及应该做什么！< / p>
假设我想开发一个实时跟踪我的动作的移动应用程序，我的第一个想法就是组织我的要求和任务：
要求1： 作为用户，我可以在地图上实时查看我的位置。
属于要求1的任务：
或者，我们应该以这种方式组织任务：
现在我们应该有以下要求：
或者：
最后是否有一个高于Scrum要求的级别？我看到有些人将费用和要求分开，但我看不出有什么好处？如果Scrum中存在特征，它们究竟代表什么？
谢谢！
答案 0 :(得分：3)
我仍然不确切知道应该是什么要求以及任务应该是什么！
小心点。
如有疑问，请重新阅读敏捷宣言。 http://agilemanifesto.org/
关键不在于Scrum对需求或任务有正式的，官方的，有利可图的定义。
Scrum为您提供了一种构建工作的方法。关键是要定义您（和您的团队）可以在合理的时间内创建的可交付成果。一个规模更大，经验更丰富的团队可能会有相当“粗略”的要求。
规模较小且经验不足的团队可能需要具备相当“精细”的要求。
任务是你需要做的事情。任务的顺序不是Scrum的一部分。这是您和您的团队选择工作的一部分。
这是Scrum（和Agile）的复杂部分：您有权按照您定义的计划完成构建高质量软件所需的工作。
您必须思考关于您将承诺的内容以及您希望如何实现目标。
或者，我们应该以这种方式组织任务：
这是您必须与您的团队决定的事情。您必须在可预测的时间范围内构建高质量的软件。您可以执行任何您希望与按时交付软件一致的随机任务。必须首先发现测试用例（a / k / a TDD）确实有帮助。
现在我们应该有以下要求：
这是您必须与您的团队，您的产品所有者（以及可能）您的用户决定的事情。你必须承诺准时交货。如果您了解问题域，您可以撰写高级故事并做出承诺。如果存在疑问，不确定或疑问，您可能希望撰写较低级别的用户故事，以确保您做出承诺。
是否有高于Scrum要求的级别？
如果它对你有帮助，是的，可以。
我看到有些人将费用和要求分开，但我看不出有什么好处？
然后不要担心。重读敏捷宣言。如果功能可以帮助您和您的团队以及产品所有者，那么您需要更清楚地定义它们。如果他们不帮助对话，那么你可以忽略它们。
如果Scrum中存在功能，它们究竟代表什么？
功能是故事的一部分。它们是特定的GUI元素或处理步骤，可以帮助演员完成故事。
答案 1 :(得分：2)
如果Scrum中存在功能，它们究竟代表什么？
答案取决于你学习scrum的地方。我将一个功能视为史诗用户故事。这是你想要达到的目标，但它是一个太大的工作。您可以拆分史诗般的用户故事，例如将蛋糕切成[较小的] 用户故事。
您可以在 Mike Cohn 的用户故事应用：敏捷软件开发一书中阅读有关此练习的内容。如果你刚开始做Scrum，这本书真的会帮助你。
无关紧要的事情。我注意到你有单独的单元测试任务。我不建议这样做，因为这个任务通常是团队实施的最后一件事，他们会发现错误太晚了。最后的任务通常非常接近演示，你没有时间修复这些错误。
将任务视为非常小的用户故事，它们没有单独的客户价值，但它们共同价值很多 - 实际上与用户故事一样多。为任务创建完成协议的定义，其中包含单元测试作为完成标准的一部分。
或者您可以使用XP的TDD。
HTH，
泽索特
答案 2 :(得分：1)
要求是从客户的角度来看他们对应用程序的期望 - 大多数都没有技术术语
要求分为用户故事（任务 - 可以是技术性的）。
例如，
作为用户，我可以看到我的位置 实时在地图上
这可以称为用户故事，但可能有点高，因为它仍然可以分解为较小的用户故事。像，
等
修改：
但是对你而言，用户故事也可以有子任务，因此你可以将原始需求作为用户故事，并可以将我提到的作为子任务添加到其中。它通常有助于使用户故事尽可能小，以便更好地估计时间和资源。