The point is not that Scrum has a formal, official, good-for-all-time definition of requirement or task.
Scrum provides you a way to structure your work. The point is to define a deliverable that you (and your team) can create in a reasonable amount of time. A larger and more experienced team may have fairly "coarse" requirements.
A smaller and less experienced team may need to have fairly "fine" requirements.
The tasks are the things you need to do. The order of the tasks isn't part of Scrum. It's part of how you and your team choose to work.
Here's the complex part of Scrum (and Agile): you're empowered to do what needs to be done to build high-quality software on the schedule you defined.
You have to actually think about what you will commit to and how you want to get there.
Or, should we organize the tasks this way:
This is something you must decide with your team. You must build high-quality software in a predictable time-frame. You can do any random tasks you want consistent with delivering software on time. Must folks find that test case first (a/k/a TDD) really helps.
Now for the requirements should we have:
This is something you must decide with your team, your product owner (and perhaps) your users. You have to commit to on-time delivery. If you understand the problem domain, you can write high-level stories and make your commitments. If there is question, uncertainty or doubt, you might want to write lower-level user stories to be sure you make your commitments.
is there a level above the requirements in Scrum?
If it helps you, yes, there can be.
I have seen that some people separate the feeatures and the requirements but I can't see the benefit?
Then don't worry about it. Reread the Agile Manifesto. If features help you and your team and your product owner, then you'll need to define them more clearly. If they don't help the conversation, then you can ignore them.
If features exist in Scrum, what do they represent exactly?
Features are part of a story. They're specific GUI elements or processing steps that help the actor get through the story.
If features exist in Scrum, what do they represent exactly?
The answer depends on where you learnt scrum. I see a feature as an epic user story. It is a goal you want to reach, but it is a too big chunk of work. You can split epic user stories like slicing a cake into [smaller] user stories.
You can read about this practice in Mike Cohn's User Stories Applied: For Agile Software Development book. If you just started doing Scrum, this book will really help you.
An unrelated thing. I noticed that you have separate tasks for unit testing. I don't recommend to do that, because this task will be usually the last thing what the team will implement, and they will find bugs too late. The last tasks are usually implemented quite close to the demo, and you won't have time to fix those bugs.
Consider tasks as very small user stories, which don't have customer value separately, but together they value a lot - exactly as much as their user story, actually. Have a definition of done agreement for tasks, which contains the unit testing as part of the done criteria.
Requirements are from client's perspective of what they expect from the application -- mostly no tech jargon
Requirements are broken down into user stories (tasks -- can be technical).
For example,
As a user I can see my position in real time on a map
This can be called a user story, but may be a little high level since it can still be broken down to smaller user stories. Like,
As an application, I have Google Map API integrated.
As an application, I have the functionality to set icons to represent user
etc.
Edit:
But its upto you, user stories can have sub tasks as well, so you can have your original requirement as an user story and can add the things that I mentioned as sub tasks to it. It generally helps to make user stories as small as possible for better estimations on time and resources.
发布评论
评论（3）
当心。
如有疑问，请重新阅读敏捷宣言。 http://agilemanifesto.org/
重点不在于 Scrum 有一个正式的、官方的、适合所有人的-要求或任务的时间定义。
Scrum 为您提供了一种构建工作的方法。重点是定义您（和您的团队）可以在合理的时间内创建的可交付成果。规模更大、经验更丰富的团队可能有相当“粗略”的要求。
规模较小且经验较少的团队可能需要相当“精细”的要求。
任务是您需要做的事情。任务的顺序不是 Scrum 的一部分。这是您和您的团队选择工作方式的一部分。
这是 Scrum（和敏捷）的复杂部分：您有权按照您定义的时间表完成构建高质量软件所需的工作。
您必须真正思考您将致力于什么以及您希望如何实现这一目标。
这是您必须与您的团队一起决定的事情。您必须在可预测的时间内构建高质量的软件。您可以执行任何您想要的随机任务，以确保按时交付软件。人们必须首先发现测试用例（又名 TDD）确实有帮助。
这是您必须与您的团队、您的产品负责人（或许还包括您的用户）共同决定的事情。您必须承诺按时交货。如果您理解问题领域，您就可以编写高水平的故事并做出承诺。如果存在疑问、不确定性或疑问，您可能需要编写较低级别的用户故事以确保做出承诺。
如果它对你有帮助，是的，可以有。
那么就不用担心了。重读敏捷宣言。如果功能对您、您的团队和产品负责人有帮助，那么您需要更清楚地定义它们。如果它们对谈话没有帮助，那么你可以忽略它们。
特征是故事的一部分。它们是帮助演员完成故事的特定 GUI 元素或处理步骤。
Be careful.
When in doubt, please re-read the Agile Manifesto. http://agilemanifesto.org/
The point is not that Scrum has a formal, official, good-for-all-time definition of requirement or task.
Scrum provides you a way to structure your work. The point is to define a deliverable that you (and your team) can create in a reasonable amount of time. A larger and more experienced team may have fairly "coarse" requirements.
A smaller and less experienced team may need to have fairly "fine" requirements.
The tasks are the things you need to do. The order of the tasks isn't part of Scrum. It's part of how you and your team choose to work.
Here's the complex part of Scrum (and Agile): you're empowered to do what needs to be done to build high-quality software on the schedule you defined.
You have to actually think about what you will commit to and how you want to get there.
This is something you must decide with your team. You must build high-quality software in a predictable time-frame. You can do any random tasks you want consistent with delivering software on time. Must folks find that test case first (a/k/a TDD) really helps.
This is something you must decide with your team, your product owner (and perhaps) your users. You have to commit to on-time delivery. If you understand the problem domain, you can write high-level stories and make your commitments. If there is question, uncertainty or doubt, you might want to write lower-level user stories to be sure you make your commitments.
If it helps you, yes, there can be.
Then don't worry about it. Reread the Agile Manifesto. If features help you and your team and your product owner, then you'll need to define them more clearly. If they don't help the conversation, then you can ignore them.
Features are part of a story. They're specific GUI elements or processing steps that help the actor get through the story.
答案取决于您在哪里学习 Scrum。我将一项功能视为史诗般的用户故事。这是一个你想要达到的目标，但这是一个太大的工作量。您可以将史诗般的用户故事拆分为[较小的]用户故事，例如将蛋糕切成[更小的]。
您可以在 Mike Cohn 的应用用户故事：敏捷软件开发一书中了解此实践。如果你刚刚开始做 Scrum，这本书会对你很有帮助。
一件不相干的事。我注意到您有单独的单元测试任务。我不建议这样做，因为这项任务通常是团队实施的最后一件事，而且他们发现错误时为时已晚。最后的任务通常是在非常接近演示的情况下实现的，您将没有时间修复这些错误。
将任务视为非常小的用户故事，它们单独没有客户价值，但它们组合在一起就很有价值 - 实际上与它们的用户故事一样重要。对任务有一个“完成”协议的定义，其中包含作为“完成”标准一部分的单元测试。
或者你可以使用XP的TDD。
HTH，
兹索尔特
The answer depends on where you learnt scrum. I see a feature as an epic user story. It is a goal you want to reach, but it is a too big chunk of work. You can split epic user stories like slicing a cake into [smaller] user stories.
You can read about this practice in Mike Cohn's User Stories Applied: For Agile Software Development book. If you just started doing Scrum, this book will really help you.
An unrelated thing. I noticed that you have separate tasks for unit testing. I don't recommend to do that, because this task will be usually the last thing what the team will implement, and they will find bugs too late. The last tasks are usually implemented quite close to the demo, and you won't have time to fix those bugs.
Consider tasks as very small user stories, which don't have customer value separately, but together they value a lot - exactly as much as their user story, actually. Have a definition of done agreement for tasks, which contains the unit testing as part of the done criteria.
Or you can use XP's TDD.
HTH,
Zsolt
需求是从客户的角度出发，了解他们对应用程序的期望——大多没有技术术语
。需求被分解为用户故事（任务——可以是技术性的）。
例如，
这可以称为用户故事，但可能级别有点高，因为它仍然可以分解为更小的用户故事。就像，
集成API。
具有设置图标的功能
代表用户
等。
编辑：
但这取决于你，用户故事也可以有子任务，因此你可以将原始需求作为用户故事，并可以添加我提到的子任务到它。它通常有助于使用户故事尽可能小，以便更好地估计时间和资源。
Requirements are from client's perspective of what they expect from the application -- mostly no tech jargon
Requirements are broken down into user stories (tasks -- can be technical).
For example,
This can be called a user story, but may be a little high level since it can still be broken down to smaller user stories. Like,
API integrated.
have the functionality to set icons
to represent user
etc.
Edit:
But its upto you, user stories can have sub tasks as well, so you can have your original requirement as an user story and can add the things that I mentioned as sub tasks to it. It generally helps to make user stories as small as possible for better estimations on time and resources.