（顺便说一句，这很好地说明了为什么使用错误跟踪器作为 Scrum 工具是一个坏主意。这些是不同的工具，应该针对不同的事情进行优化 - 即使通过某些 API 链接在一起。）
Done is done - it has to be all those things you defined, however treating them as steps explicitly with a bug tracker can have the undesired side effect of encouraging divisions within then team and throwing stuff over the wall. So coders would claim they are done once ticket is marked "coded" and "unit tested", testers when marked tested etc.
This is exactly the opposite of what Scrum intends to do - the whole team commits to doing the stories so that they meet the definition of done in the end. So even though some of the elements of achieving done are indeed steps one should be very careful with solidifying these steps in any kind of defined workflow.
(This btw shows nicely why using a bug tracker as a scrum tool is a bad idea. Those are different tools that should be optimized for different things - even if linked together through some APIs.)
I certainly wouldn't nest them, since they are steps common to each task. Making them subtasks would just increase the complexity and boilerplate of the system. These seem like perfect workflow stages to me.
Something like Submitted->Assigned->Coding->Review->Testing->Finished.
Where Coding requires "coded", "unit tested", and "integration tested" before moving to Review, Review requires Peer Review before moving to Testing, Testing requires QA Testing before moving to Finished.
The only reason this would be tricky is if you're allowing Peer Review and Testing to be done in parallel. I see problems with allowing that, since if the code fails peer review and is subsequently changed it invalidates the testing work done by QA.
IMHO these belong together, as both should be handled by the same person (preferably TDD, which really makes it impossible to separate these).
integration tested
In our team, this is usually done by the same developer, so we typically do it as part of the above task. Other teams may do it differently.
commented
Do you mean code comments? Then, to me, this does not deserve a separate task. Otherwise, please clarify.
peer reviewed
A separate task for a separate developer (or more).
qa tested
A separate task for testers / QA personnel.
I would add documentation - it may not always be needed, but often is. Again, it should be a separate task, typically for the same guy who did the implementation (but not always).
One prime concern to practically all the Scrum teams I have been working with so far is to make sure that nothing important is forgotten from the above. Partitioning into distinct tasks may help this. Then you can clearly see in your backlog what's left to do. Lumping all of these into one task makes it easy to forget about this or that little detail. For us, it was most typical to forget about code review and documentation, that was the main reason why we turned these into independent tasks.
Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the definition of “done” does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration.
Reference: Scrum Guide - Written by Ken Schwaber and Jeff Sutherland (Inventors of Scrum)
You state that you are following "Scrum Practices". It sounds to me like you are just using a few parts of the Scrum Framework and not others, is that true? First of all, Scrum is not necessarily a practice, it is a Framework, you either use the framework or you don't. It works on the basis of inspect and adapt, so apart from the basic Scrum framework rules, nothing is set in stone, so you won't get an exact answer to your question. The best way to know the answer is hire experienced Scrum Professionals, and Experienced Developers and Testers and try the above done plan in your Scrum Team.
Remember always Inspect and Adapt. There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.
Do not spend loads of time documenting or looking for a solution to a given Process problem because most of the time the problems change faster than you would realize, it is just better to inspect and adapt provided you have at least the basic knowledge of scrum and you are using the Scrum framework and not just a few Scrum like practices.
We use a pretty similar system in JIRA and I have an open question here and on the Atlassian boards asking a very similar question. We have a similar definition of done. We create the main story in descriptive form i.e. "The legend text on the profit and loss graph overlaps". We then define sub-tasks which are either of type 'technical' or 'process'. Technical tasks are the actual work of implementing the story "Research possible causes on vendor site", "Implement fix in the infographic class". Process items include 'Peer Review', 'Make Build', 'QA Testing', 'Merge'. As one comment noted you may have QA going on before/during Peer Review. As a part of the Scrum process we have QA going on nearly all of the time (they are part of the team) sometimes they sit with the developer, sometimes they get 'bootleg builds' to run in a test environment. This is exploratory testing and is considered part of the coding process to us. The sub-task for 'QA Testing' is for integration and regression testing and is a final validation of the whole story after Peer Review is completed. By that time the QA team already has a complete test plan they worked up during exploratory testing and it's typically just a matter of running through the plan and 'checking it off'.
We've gotten to this point after running sprints for a year and making changes during the retrospective. I'm open to suggestions as I think one of the downsides to the retrospective is that you can group-think yourself in one direction with little hope of ever backing all the way out and considering a different path.
We use two boards for this purpose. We have one board for the Development Sprint where "Done" is Ready for Testing. You can't enter a sprint unless you're well and truly ready to start development (all analysis done, estimates done, people know what they are supposed to be doing - all the conversations have been had, shall we say, though our conversations tend to take place in JIRA Comments given the distributed team) ... and you exit when you finish development. That's the best way to track whether our development team is meeting their own goals without being impacted by QA. Meanwhile, QA uses a Kanban style board and they go from "Ready for Testing" (this is their "to-do"), through In Testing to Ready for Release.
We switched to this because we previously had all these steps in a single board, and we weren't "meeting our commitments" within any sprints because there was no way to both develop & test all in a single sprint, where we have to do a code migration to the QA environment for final testing to occur, although testing is happening all along the way. We are still trying to figure out how to do things correctly, so this may not be the right answer, and yet it sounds like it's not something you've thought of, so maybe it would work for you.
and it'll be hard to make tasks that are under 16 hours that include all of those things.
This is your real issue; ability to break down stories into small useful vertical slices of functionality. Working on this will make your team more agile and give the PO more flexibility.
To the contrary, breaking down the work by process/mechanical step will only make you less agile and really serves no useful purpose. Either you are done or you aren't; no one cares if you are dev complete and not tested so don't bother tracking it by the hour....its waste.
Given that the story is a shared item (the whole scrum team works on it), we use the subtasks as 'the post-it notes' allowing to track tasks which individuals need to tackle.
We don't require that every little piece of task is represented as a subtask.
We are not bookkeepers, but developers.
The team agreement is that if you can't take up a task immediately, just jot it down as a subtask to the story. (Using the agile plugin, it is really easy). ie. we will never have systematically a subtask 'create unit test', but in some occassions, when someone is struggling to get that dynamock up and running, you will see this subtask popup in the story. Having it there allows the team to discuss it during the scrum.
BTW - JIRA is more than a bug tracker. We are using it in a wide variety of applications, including the management of our sprint activity. (as an Atlassian partner, I'm biased :-).
Important thing is that you use sub-task as real task; not as activity of main task. Issue tracker is primarily meant for what you are doing; not how you are doing and in what order.
发布评论
评论（9）
完成了——它必须是您定义的所有这些事情，但是使用错误跟踪器将它们明确地视为步骤可能会产生不良的副作用，即鼓励团队内部分裂并将东西扔到墙上。因此，一旦票证被标记为“已编码”和“单元测试”，编码人员就会声称他们已经完成，而测试人员则在被标记为“已测试”时声称他们已经完成。
这与 Scrum 的意图恰恰相反——整个团队承诺编写故事，使它们最终符合“完成”的定义。因此，即使实现完成的某些要素确实是步骤，但在任何一种已定义的工作流程中巩固这些步骤时也应该非常小心。
（顺便说一句，这很好地说明了为什么使用错误跟踪器作为 Scrum 工具是一个坏主意。这些是不同的工具，应该针对不同的事情进行优化 - 即使通过某些 API 链接在一起。）
Done is done - it has to be all those things you defined, however treating them as steps explicitly with a bug tracker can have the undesired side effect of encouraging divisions within then team and throwing stuff over the wall. So coders would claim they are done once ticket is marked "coded" and "unit tested", testers when marked tested etc.
This is exactly the opposite of what Scrum intends to do - the whole team commits to doing the stories so that they meet the definition of done in the end. So even though some of the elements of achieving done are indeed steps one should be very careful with solidifying these steps in any kind of defined workflow.
(This btw shows nicely why using a bug tracker as a scrum tool is a bad idea. Those are different tools that should be optimized for different things - even if linked together through some APIs.)
我当然不会嵌套它们，因为它们是每个任务的通用步骤。让它们成为子任务只会增加系统的复杂性和样板。对我来说，这些似乎是完美的工作流程阶段。
类似于“已提交”->“已分配”->“编码”->“审核”->“测试”->“已完成”。
在进入评审之前，编码需要“编码”、“单元测试”和“集成测试”，评审需要在进入测试之前进行同行评审，测试需要在进入完成之前进行 QA 测试。
这会很棘手的唯一原因是如果您允许同行评审和测试并行进行。我发现允许这样做存在问题，因为如果代码未通过同行评审并随后进行更改，那么 QA 所做的测试工作就会失效。
I certainly wouldn't nest them, since they are steps common to each task. Making them subtasks would just increase the complexity and boilerplate of the system. These seem like perfect workflow stages to me.
Something like Submitted->Assigned->Coding->Review->Testing->Finished.
Where Coding requires "coded", "unit tested", and "integration tested" before moving to Review, Review requires Peer Review before moving to Testing, Testing requires QA Testing before moving to Finished.
The only reason this would be tricky is if you're allowing Peer Review and Testing to be done in parallel. I see problems with allowing that, since if the code fails peer review and is subsequently changed it invalidates the testing work done by QA.
恕我直言，它们属于在一起，因为两者应该由同一个人处理（最好是 TDD，这实际上使得不可能将它们分开）。
在我们的团队中，这通常是由同一开发人员完成的，因此我们通常将其作为上述任务的一部分来完成。其他团队可能会采取不同的做法。
你的意思是代码注释吗？那么，对我来说，这不值得一个单独的任务。否则请澄清。
单独的开发人员（或多个）的单独任务。
测试人员/QA 人员的单独任务。
我会添加文档 - 它可能并不总是需要，但通常是需要的。同样，这应该是一项单独的任务，通常由负责实施的同一个人完成（但并非总是如此）。
迄今为止与我合作过的几乎所有 Scrum 团队最关心的一个主要问题是确保上述内容没有被遗忘。划分为不同的任务可能会有所帮助。然后您可以在积压工作中清楚地看到还需要做什么。将所有这些集中到一项任务中很容易忘记这个或那个小细节。对于我们来说，最典型的是忘记代码审查和文档，这是我们将它们转变为独立任务的主要原因。
IMHO these belong together, as both should be handled by the same person (preferably TDD, which really makes it impossible to separate these).
In our team, this is usually done by the same developer, so we typically do it as part of the above task. Other teams may do it differently.
Do you mean code comments? Then, to me, this does not deserve a separate task. Otherwise, please clarify.
A separate task for a separate developer (or more).
A separate task for testers / QA personnel.
I would add documentation - it may not always be needed, but often is. Again, it should be a separate task, typically for the same guy who did the implementation (but not always).
One prime concern to practically all the Scrum teams I have been working with so far is to make sure that nothing important is forgotten from the above. Partitioning into distinct tasks may help this. Then you can clearly see in your backlog what's left to do. Lumping all of these into one task makes it easy to forget about this or that little detail. For us, it was most typical to forget about code review and documentation, that was the main reason why we turned these into independent tasks.
完成定义了团队在 Sprint 中承诺“完成”产品待办事项列表项时的含义。有些产品不包含文档，因此“完成”的定义不包含文档。完全“完成”的增量包括增量的所有分析、设计、重构、编程、文档和测试以及增量中的所有产品待办事项列表项。测试包括单元测试、系统测试、用户测试和回归测试，以及性能、稳定性、安全性和集成等非功能测试。
参考：Scrum 指南 - 由 Ken Schwaber 和 Jeff Sutherland（Scrum 发明者）撰写
您声明您正在遵循“Scrum 实践”。在我看来，您只是使用了 Scrum 框架的几个部分，而不是其他部分，是这样吗？首先，Scrum不一定是一种实践，它是一个框架，你要么使用框架，要么不使用。它的工作原理是检查和调整，所以除了基本的 Scrum 框架规则之外，没有什么是一成不变的，所以你不会得到问题的确切答案。了解答案的最佳方法是聘请经验丰富的 Scrum 专业人员、经验丰富的开发人员和测试人员，并在您的 Scrum 团队中尝试上述完成的计划。
请记住始终检查和调整。 Scrum中有三点需要检查和适应。每日 Scrum 会议用于检查 Sprint 目标的进展情况，并做出调整以优化下一个工作日的价值。此外，Sprint 审查和规划会议用于检查发布目标的进度，并进行调整以优化下一个 Sprint 的价值。最后，Sprint 回顾用于回顾过去的 Sprint，并确定哪些调整将使下一个 Sprint 更加高效、充实和愉快。
不要花费大量时间记录或寻找给定流程问题的解决方案，因为大多数时候问题的变化速度比您想象的要快，如果您至少具备 Scrum 和 Scrum 的基本知识，那么检查和适应会更好。您正在使用 Scrum 框架，而不仅仅是一些类似 Scrum 的实践。
Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the definition of “done” does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration.
Reference: Scrum Guide - Written by Ken Schwaber and Jeff Sutherland (Inventors of Scrum)
You state that you are following "Scrum Practices". It sounds to me like you are just using a few parts of the Scrum Framework and not others, is that true? First of all, Scrum is not necessarily a practice, it is a Framework, you either use the framework or you don't. It works on the basis of inspect and adapt, so apart from the basic Scrum framework rules, nothing is set in stone, so you won't get an exact answer to your question. The best way to know the answer is hire experienced Scrum Professionals, and Experienced Developers and Testers and try the above done plan in your Scrum Team.
Remember always Inspect and Adapt. There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.
Do not spend loads of time documenting or looking for a solution to a given Process problem because most of the time the problems change faster than you would realize, it is just better to inspect and adapt provided you have at least the basic knowledge of scrum and you are using the Scrum framework and not just a few Scrum like practices.
我们在 JIRA 中使用了一个非常相似的系统，我在这里和 Atlassian 板上有一个悬而未决的问题，提出了一个非常相似的问题。我们对“完成”有类似的定义。我们以描述性形式创建主要故事，即“损益图上的图例文本重叠”。然后，我们定义“技术”或“流程”类型的子任务。技术任务是实现故事“在供应商站点上研究可能的原因”、“在信息图表类中实施修复”的实际工作。流程项目包括“同行评审”、“构建”、“QA 测试”、“合并”。正如一条评论指出，您可能会在同行评审之前/期间进行质量检查。作为 Scrum 流程的一部分，我们几乎一直在进行 QA（他们是团队的一部分），有时他们与开发人员坐在一起，有时他们会在测试环境中运行“盗版版本”。这是探索性测试，对我们来说被视为编码过程的一部分。 “QA 测试”的子任务用于集成和回归测试，是同行评审完成后对整个故事的最终验证。到那时，质量保证团队已经有了他们在探索性测试期间制定的完整测试计划，通常只需运行该计划并“检查它”即可。
经过一年的冲刺并在回顾期间做出改变，我们已经达到了这一点。我愿意接受建议，因为我认为回顾的缺点之一是你可以在一个方向上进行集体思考，而几乎没有希望完全退出并考虑不同的道路。
We use a pretty similar system in JIRA and I have an open question here and on the Atlassian boards asking a very similar question. We have a similar definition of done. We create the main story in descriptive form i.e. "The legend text on the profit and loss graph overlaps". We then define sub-tasks which are either of type 'technical' or 'process'. Technical tasks are the actual work of implementing the story "Research possible causes on vendor site", "Implement fix in the infographic class". Process items include 'Peer Review', 'Make Build', 'QA Testing', 'Merge'. As one comment noted you may have QA going on before/during Peer Review. As a part of the Scrum process we have QA going on nearly all of the time (they are part of the team) sometimes they sit with the developer, sometimes they get 'bootleg builds' to run in a test environment. This is exploratory testing and is considered part of the coding process to us. The sub-task for 'QA Testing' is for integration and regression testing and is a final validation of the whole story after Peer Review is completed. By that time the QA team already has a complete test plan they worked up during exploratory testing and it's typically just a matter of running through the plan and 'checking it off'.
We've gotten to this point after running sprints for a year and making changes during the retrospective. I'm open to suggestions as I think one of the downsides to the retrospective is that you can group-think yourself in one direction with little hope of ever backing all the way out and considering a different path.
为此，我们使用两块板。我们有一个开发冲刺板，其中“完成”已准备好进行测试。除非你真正准备好开始开发，否则你不能进入冲刺（所有分析完成，估计完成，人们知道他们应该做什么 - 所有的对话都已经进行了，容我们说，尽管我们的对话考虑到分布式团队，往往发生在 JIRA Comments 中）...并且在完成开发后退出。这是跟踪我们的开发团队是否在不受 QA 影响的情况下实现自己的目标的最佳方式。同时，QA 使用看板样式板，他们从“准备测试”（这是他们的“待办事项”），通过测试中到准备发布。
我们之所以改用这种方法，是因为我们之前将所有这些步骤都放在一个板上，并且我们在任何冲刺中都没有“履行我们的承诺”，因为没有办法既开发又开发。在一个冲刺中测试所有内容，我们必须将代码迁移到 QA 环境才能进行最终测试，尽管测试一直在进行。我们仍在尝试找出如何正确地做事，所以这可能不是正确的答案，但听起来这不是您想到的，所以也许它对您有用。
We use two boards for this purpose. We have one board for the Development Sprint where "Done" is Ready for Testing. You can't enter a sprint unless you're well and truly ready to start development (all analysis done, estimates done, people know what they are supposed to be doing - all the conversations have been had, shall we say, though our conversations tend to take place in JIRA Comments given the distributed team) ... and you exit when you finish development. That's the best way to track whether our development team is meeting their own goals without being impacted by QA. Meanwhile, QA uses a Kanban style board and they go from "Ready for Testing" (this is their "to-do"), through In Testing to Ready for Release.
We switched to this because we previously had all these steps in a single board, and we weren't "meeting our commitments" within any sprints because there was no way to both develop & test all in a single sprint, where we have to do a code migration to the QA environment for final testing to occur, although testing is happening all along the way. We are still trying to figure out how to do things correctly, so this may not be the right answer, and yet it sounds like it's not something you've thought of, so maybe it would work for you.
这是你真正的问题；能够将故事分解为小的有用的垂直功能片段。致力于此将使您的团队更加敏捷，并为 PO 提供更大的灵活性。
相反，按流程/机械步骤分解工作只会让你变得不那么敏捷，而且实际上没有任何用处。要么你完成了，要么你还没有；没有人关心你是否完成了开发并且没有经过测试，所以不要费心按小时跟踪它......这是浪费。
重新关注你的故事，而不是任务。
This is your real issue; ability to break down stories into small useful vertical slices of functionality. Working on this will make your team more agile and give the PO more flexibility.
To the contrary, breaking down the work by process/mechanical step will only make you less agile and really serves no useful purpose. Either you are done or you aren't; no one cares if you are dev complete and not tested so don't bother tracking it by the hour....its waste.
Refocus on your stories, not on tasks.
我们使用子任务。
鉴于故事是一个共享项目（整个 Scrum 团队都在处理它），我们将子任务用作“便利贴”，以便跟踪个人需要处理的任务。
我们不要求每一个小任务都表示为子任务。
我们不是簿记员，而是开发商。
团队达成的协议是，如果你不能立即接受某项任务，就把它记下来作为故事的子任务。 （使用敏捷插件，非常简单）。 IE。我们永远不会系统地有一个子任务“创建单元测试”，但在某些情况下，当有人努力启动并运行该动态时，您会在故事中看到这个子任务弹出。有了它，团队就可以在 Scrum 期间对其进行讨论。
如果您想自动生成清单，请查看过渡插件上的创建子任务。
https://studio.plugins.atlassian。 com/wiki/display/CSOT/Jira+Create+Subtask+for+transition
它允许您在提交故事后自动添加子任务。
顺便说一句 - JIRA 不仅仅是一个错误跟踪器。我们在各种各样的应用中使用它，
包括我们冲刺活动的管理。 （作为 Atlassian 合作伙伴，我有偏见:-)。
弗朗西斯
We use subtasks.
Given that the story is a shared item (the whole scrum team works on it), we use the subtasks as 'the post-it notes' allowing to track tasks which individuals need to tackle.
We don't require that every little piece of task is represented as a subtask.
We are not bookkeepers, but developers.
The team agreement is that if you can't take up a task immediately, just jot it down as a subtask to the story. (Using the agile plugin, it is really easy). ie. we will never have systematically a subtask 'create unit test', but in some occassions, when someone is struggling to get that dynamock up and running, you will see this subtask popup in the story. Having it there allows the team to discuss it during the scrum.
If you want to generate the checklist automatically, look at the create subtask on transition plugin.
https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition
It allows you to automatically add the subtasks when the story has been committed.
BTW - JIRA is more than a bug tracker. We are using it in a wide variety of applications,
including the management of our sprint activity. (as an Atlassian partner, I'm biased :-).
Francis
重要的是你将子任务用作真正的任务；不作为主要任务的活动。问题跟踪器主要针对您正在做的事情；不是你正在做什么以及按什么顺序。
Important thing is that you use sub-task as real task; not as activity of main task. Issue tracker is primarily meant for what you are doing; not how you are doing and in what order.