A very important aspect of Scrum is getting things "done" during the Sprint, and the definition of done. If a feature is finished during the sprint, but not tested it still isn't done.
What you should not do to solve this is to increment the length of your Sprints. Short sprints would still mostly be prefered. I'd suggest two things.
The first one is really important, but not necessarily easy to achieve. Integrate QA into your teams. Having a separate QA department that validates your product after you're "done" with it is really waterfall. You may still want the QA verification before your product is shipped, but what is produced in the sprint should be finished and tested during the sprint. To do so you need qualified QA people to be part of your team - or you need to train the developers to do QA as best as they can. In my company our QA department is too small, so we were unable to get some for our team. Instead we learned about QA and added a column to our task board with the heading "Ready for verification". Whenever a feature was finished it was moved to "ready for verification", and some other developer would look at this. Even though we might not have been as skilled as the dedicated QA guys we discovered problems all the time this way, moving them back for fixing, and then to Verification again. This process gave us much more confidence in the features we classified as done during the sprint, and a dramatic drop in bugs found later on.
The other things is to start defining smaller tasks, or do a better job in breaking features down into smaller parts. You don't want to work on a feature that accoring to your esimations might take the whole sprint. If your "almost done" you really haven't finished anything during the sprint. Instead; break the features down into smaller parts and solve them one by one. While someone is working on part2 part1 is being verified by one of the other team members, making the whole process of development and QA more integrated - giving a better chance of calling your new features "done" at the end of the sprint.
Unfortunately, but you just aren't doing scrum. You are doing waterfall in sprints; aka scrum-fall.
1) Integrate QA into the team. They shouldn't be a separate group that you "pass" the code to. They should be working with the devs every day to test their work.
2) Make your stories much, much, much smaller. A story should take 1-2 days to complete (a week is absolute max and only occasionally unless you're building rockets). You need the team to work on getting better at slicing functionality vertically to create small testable, usable, value added stories.
3) Scrum doesn't have job titles. If a dev is done doing all coding then he/she tests someone else's code. Or works to create automated scripts that you say you are missing.
4) Its OK to have a "hardening" sprint right before a major release, but certainly testing HAS TO BE done during the same sprint as development. Pretty much every time code is checked in, testing gets done.
5) Fix your definition of "done". Done means the code is written, tested, deployable, and documented as needed.
6) You need a lot of work on "team" and commitment. Your comment that devs are "happy" as long as their coding is done is quite contrary to scrum and its principals.
Based on your comments I think the team needs to invest in training if you are serious about becoming agile.
You may need to change the length of your sprint, and define done as gone to QA, or ready for Production.
This is hard to do, but that also means making certain you have tasks on the board for testing.
Also, this will mean scaling back, so during the mid-point check be honest and remove the tasks that won't be finished, in order to achieve the definition of done.
Or, and this is less ideal, basically have two sprints/feature. The first should be to get it working, with unit tests, and the second is to get it through QA. So, the second sprint may be shorter, but, if you are going to do that then just combine them into a longer sprint.
Your tasks are too big. You need to have smaller tasks (a few days max) that bring value to the customer (so that they can be tested). When a task is done, from a development perspective, QA can start validating it.
Perhaps you need also to plan less for a Sprint, so that increment gets validated at the end of the Sprint.
It's not uncommon for team transitioning to Agile to have QA validating what was developped in the previous iteration. But they have to catch up.
What should developers do during the QA procedure?
There is no phase with Scrum, developers code while testers are validating, and testers are testing while developers are cranking code. When the development of the planned tasks is complete, they can write documentation, fix problems reported by QA, support QA, estimate tasks for the next Sprints ...
We do QA on individual features during the Sprint in which they are developed. At the end of that Sprint we make sure our Main source code branch is up-to-date and then developers carry on with the Dev branch. This frees up QA to do Release Testing and doesn't time-box them. Any bug-fixes can be easily applied to the Main branch without having to 'undo' any new stuff in the Dev branch.
Your bigger problem may be lack of automated / Unit testing. This cuts down the amount of work your QA guys have to do and will, therefore, make it more likely that they finish their work quicker.
I also don't think that increasing the length of your sprint will help. This will force you to either add more developer tasks or have your dev guys sat on their hands whilst QA catches up.
Define done as developed and tested (no bugs,or any other acceptance criteria). Integrate testers into your team. As feature is being planned for sprint divide it into small tasks and make testing one of those tasks (or even more than one testing task). So You will have feature A consisting DB changes, UI Changes, App changes, Testing - all tasks adding up to one feature. Additionally engage testers as early as possible, don't wait till end of development. And when Testers are still testing, and developers have finished their tasks (there always will be some time gap between development and testing) move developers to work on other feature.
发布评论
评论（6）
Scrum 的一个非常重要的方面是在 Sprint 期间“完成”事情以及完成的定义。如果某个功能在冲刺期间完成，但未经测试，那么它仍然没有完成。
为了解决这个问题，您不应该做的就是增加 Sprint 的长度。短冲刺仍然是大多数人的首选。我建议两件事。
第一个确实很重要，但不一定容易实现。将 QA 整合到您的团队中。拥有一个独立的 QA 部门在您“完成”产品后验证您的产品确实是瀑布式的。您可能仍然希望在产品发货之前进行 QA 验证，但是冲刺中生产的内容应该在冲刺期间完成并进行测试。为此，您需要合格的 QA 人员成为您团队的一部分，或者您需要培训开发人员尽可能地做好 QA。在我的公司，我们的 QA 部门太小，所以我们无法为我们的团队找到一些人。相反，我们了解了 QA，并在任务板上添加了一个标题为“准备验证”的列。每当一个功能完成时，它就会被转移到“准备验证”状态，其他一些开发人员会查看这一点。尽管我们可能不如专门的 QA 人员那么熟练，但我们总是通过这种方式发现问题，将它们移回修复，然后再次进行验证。这个过程让我们对冲刺期间完成的功能更有信心，并且后来发现的错误大幅减少。
另一件事是开始定义更小的任务，或者更好地将功能分解为更小的部分。您不想开发一个根据您的估计可能需要整个冲刺的功能。如果你“几乎完成”，那么你在冲刺期间实际上还没有完成任何事情。反而;将功能分解为更小的部分并一一解决。当有人正在处理第 2 部分时，第 1 部分正在由其他团队成员之一进行验证，从而使整个开发和 QA 过程更加集成 - 更有机会在冲刺结束时称您的新功能“完成”。
祝你好运！
A very important aspect of Scrum is getting things "done" during the Sprint, and the definition of done. If a feature is finished during the sprint, but not tested it still isn't done.
What you should not do to solve this is to increment the length of your Sprints. Short sprints would still mostly be prefered. I'd suggest two things.
The first one is really important, but not necessarily easy to achieve. Integrate QA into your teams. Having a separate QA department that validates your product after you're "done" with it is really waterfall. You may still want the QA verification before your product is shipped, but what is produced in the sprint should be finished and tested during the sprint. To do so you need qualified QA people to be part of your team - or you need to train the developers to do QA as best as they can. In my company our QA department is too small, so we were unable to get some for our team. Instead we learned about QA and added a column to our task board with the heading "Ready for verification". Whenever a feature was finished it was moved to "ready for verification", and some other developer would look at this. Even though we might not have been as skilled as the dedicated QA guys we discovered problems all the time this way, moving them back for fixing, and then to Verification again. This process gave us much more confidence in the features we classified as done during the sprint, and a dramatic drop in bugs found later on.
The other things is to start defining smaller tasks, or do a better job in breaking features down into smaller parts. You don't want to work on a feature that accoring to your esimations might take the whole sprint. If your "almost done" you really haven't finished anything during the sprint. Instead; break the features down into smaller parts and solve them one by one. While someone is working on part2 part1 is being verified by one of the other team members, making the whole process of development and QA more integrated - giving a better chance of calling your new features "done" at the end of the sprint.
Good luck!
不幸的是，你只是没有进行 Scrum。你正在冲刺中进行瀑布式的冲刺；又名 scrum-fall。
1) 将 QA 融入团队。它们不应该是您将代码“传递”到的单独组。他们应该每天与开发人员合作来测试他们的工作。
2）让你的故事变得非常非常小。一个故事应该需要 1-2 天才能完成（绝对最多一周，除非您正在建造火箭，否则只是偶尔）。您需要团队致力于更好地垂直分割功能，以创建小型的可测试、可用、增值的故事。
3）Scrum 没有职位头衔。如果开发人员完成了所有编码，那么他/她会测试其他人的代码。或者致力于创建您说缺少的自动化脚本。
4）在主要版本发布之前进行“强化”冲刺是可以的，但测试必须在与开发相同的冲刺期间完成。几乎每次签入代码时，测试就完成了。
5）修正你对“完成”的定义。完成意味着代码已根据需要编写、测试、部署和记录。
6）你需要在“团队”和承诺上做很多工作。您认为只要编码完成，开发人员就会“高兴”，这与 Scrum 及其原则完全相反。
根据您的评论，我认为如果您真的想变得敏捷，团队需要投资于培训。
Unfortunately, but you just aren't doing scrum. You are doing waterfall in sprints; aka scrum-fall.
1) Integrate QA into the team. They shouldn't be a separate group that you "pass" the code to. They should be working with the devs every day to test their work.
2) Make your stories much, much, much smaller. A story should take 1-2 days to complete (a week is absolute max and only occasionally unless you're building rockets). You need the team to work on getting better at slicing functionality vertically to create small testable, usable, value added stories.
3) Scrum doesn't have job titles. If a dev is done doing all coding then he/she tests someone else's code. Or works to create automated scripts that you say you are missing.
4) Its OK to have a "hardening" sprint right before a major release, but certainly testing HAS TO BE done during the same sprint as development. Pretty much every time code is checked in, testing gets done.
5) Fix your definition of "done". Done means the code is written, tested, deployable, and documented as needed.
6) You need a lot of work on "team" and commitment. Your comment that devs are "happy" as long as their coding is done is quite contrary to scrum and its principals.
Based on your comments I think the team needs to invest in training if you are serious about becoming agile.
您可能需要更改冲刺的长度，并将完成定义为进入质量检查或准备生产。
这很难做到，但这也意味着确保板上有用于测试的任务。
此外，这将意味着缩减规模，因此在中点检查期间要诚实并删除不会完成的任务，以实现完成的定义。
或者，这不太理想，基本上有两个冲刺/功能。第一个应该是通过单元测试让它工作，第二个是通过质量检查让它工作。因此，第二次冲刺可能会更短，但是，如果您打算这样做，那么只需将它们合并为更长的冲刺即可。
You may need to change the length of your sprint, and define done as gone to QA, or ready for Production.
This is hard to do, but that also means making certain you have tasks on the board for testing.
Also, this will mean scaling back, so during the mid-point check be honest and remove the tasks that won't be finished, in order to achieve the definition of done.
Or, and this is less ideal, basically have two sprints/feature. The first should be to get it working, with unit tests, and the second is to get it through QA. So, the second sprint may be shorter, but, if you are going to do that then just combine them into a longer sprint.
你的任务太大了。您需要有较小的任务（最多几天），为客户带来价值（以便可以测试它们）。当任务完成后，从开发的角度来看，QA 可以开始验证它。
也许您还需要减少 Sprint 的计划，以便增量在 Sprint 结束时得到验证。
对于过渡到敏捷的团队来说，让 QA 验证上一次迭代中开发的内容并不罕见。但他们必须迎头赶上。
Scrum 没有阶段性，开发人员编码，测试人员验证，测试人员测试，开发人员编写代码。当计划任务的开发完成后，他们可以编写文档、修复 QA 报告的问题、支持 QA、估计下一个 Sprint 的任务……
Your tasks are too big. You need to have smaller tasks (a few days max) that bring value to the customer (so that they can be tested). When a task is done, from a development perspective, QA can start validating it.
Perhaps you need also to plan less for a Sprint, so that increment gets validated at the end of the Sprint.
It's not uncommon for team transitioning to Agile to have QA validating what was developped in the previous iteration. But they have to catch up.
There is no phase with Scrum, developers code while testers are validating, and testers are testing while developers are cranking code. When the development of the planned tasks is complete, they can write documentation, fix problems reported by QA, support QA, estimate tasks for the next Sprints ...
我们在开发各个功能的 Sprint 期间对它们进行 QA。在 Sprint 结束时，我们确保主源代码分支是最新的，然后开发人员继续开发分支。这可以让 QA 腾出时间来进行发布测试，并且不会对它们进行时间限制。任何错误修复都可以轻松应用于主分支，而无需“撤消”开发分支中的任何新内容。
您更大的问题可能是缺乏自动化/单元测试。这减少了 QA 人员必须完成的工作量，因此，他们更有可能更快地完成工作。
我也不认为增加冲刺的长度会有帮助。这将迫使你要么添加更多的开发人员任务，要么让你的开发人员在 QA 赶上时袖手旁观。
We do QA on individual features during the Sprint in which they are developed. At the end of that Sprint we make sure our Main source code branch is up-to-date and then developers carry on with the Dev branch. This frees up QA to do Release Testing and doesn't time-box them. Any bug-fixes can be easily applied to the Main branch without having to 'undo' any new stuff in the Dev branch.
Your bigger problem may be lack of automated / Unit testing. This cuts down the amount of work your QA guys have to do and will, therefore, make it more likely that they finish their work quicker.
I also don't think that increasing the length of your sprint will help. This will force you to either add more developer tasks or have your dev guys sat on their hands whilst QA catches up.
将完成定义为开发和测试（没有错误或任何其他验收标准）。将测试人员整合到您的团队中。当为冲刺计划功能时，将其划分为小任务，并将测试作为这些任务之一（甚至多个测试任务）。因此，您将拥有功能 A，其中包括数据库更改、UI 更改、应用程序更改、测试 - 所有任务加起来就是一项功能。此外，尽早让测试人员参与进来，不要等到开发结束。当测试人员仍在测试，而开发人员已经完成他们的任务时（开发和测试之间总会有一些时间间隔），那么开发人员就会去开发其他功能。
Define done as developed and tested (no bugs,or any other acceptance criteria). Integrate testers into your team. As feature is being planned for sprint divide it into small tasks and make testing one of those tasks (or even more than one testing task). So You will have feature A consisting DB changes, UI Changes, App changes, Testing - all tasks adding up to one feature. Additionally engage testers as early as possible, don't wait till end of development. And when Testers are still testing, and developers have finished their tasks (there always will be some time gap between development and testing) move developers to work on other feature.