我第一次使用Scrum和一个小团队,我已经通过许多演示文稿和文档解释了这种敏捷方法,但我仍然不知道应该是什么要求以及应该是什么样的任务!
假设我想开发一个实时跟踪我的动作的移动应用程序,我首先想到的是组织我的要求和这样的任务:
要求1: 作为用户,我可以在地图上实时查看我的位置.
属于要求1的任务:
或者,我们应该以这种方式组织任务:
现在我们应该有以下要求:
要么:
最后是否有一个高于Scrum要求的级别？我看到有些人将费用和要求分开,但我看不出有什么好处？如果Scrum中存在功能,它们究竟代表什么？
谢谢!
我仍然不知道到底什么是需求，什么是任务！
当心。
如有疑问，请重新阅读敏捷宣言。 http://agilemanifesto.org/
重点不在于 Scrum 对需求或任务有一个正式的、官方的、永远适用的定义。
Scrum 为您提供了一种构建工作的方法。重点是定义您（和您的团队）可以在合理的时间内创建的可交付成果。规模更大、经验更丰富的团队可能有相当“粗略”的要求。
规模较小且经验较少的团队可能需要相当“精细”的要求。
任务是您需要做的事情。任务的顺序不是 Scrum 的一部分。这是您和您的团队选择工作方式的一部分。
这是 Scrum（和敏捷）的复杂部分：您有权按照您定义的时间表完成构建高质量软件所需的工作。
你必须真正考虑你将承诺什么以及你想如何实现这一目标。
或者，我们应该这样组织任务：
这是您必须与您的团队一起决定的事情。您必须在可预测的时间内构建高质量的软件。您可以执行任何您想要的随机任务，以确保按时交付软件。人们必须首先发现测试用例（又名 TDD）确实有帮助。
现在对于要求我们应该有：
这是你必须与你的团队、你的产品所有者（也许还有你的用户）一起决定的事情。您必须承诺按时交货。如果您了解问题领域，您就可以编写高水平的故事并做出承诺。如果存在疑问、不确定性或疑问，您可能需要编写较低级别的用户故事以确保做出承诺。
Scrum 中是否有高于要求的级别？
如果它对你有帮助，是的，可以有。
我看到有些人将功能和要求分开，但我看不到好处？
那么就不用担心了。重读敏捷宣言。如果功能对您、您的团队和产品负责人有帮助，那么您需要更清楚地定义它们。如果它们对谈话没有帮助，那么你可以忽略它们。
如果 Scrum 中存在特性，它们到底代表什么？
特征是故事的一部分。它们是帮助演员完成故事的特定 GUI 元素或处理步骤。