People should fix their own code. Take advantage of the fact that no one likes going back and fixing old stuff when they could be writing new stuff. If the developer responsible for the bug can be identified, make sure they are responsible for fixing the problem. This will encourage developers to be more diligent in writing clean code the first time since no one wants to be seen as the person who has to keeping fixing things they've broken. This is true during development as well when someone breaks the current build.
Update: Having said that, I wouldn't necessarily be dogmatic about it. The customer's needs come first and if the person who created the bug can't be reassigned to do the fix, you may have to assign the fix to someone else.
ScrumMasters don't allocate developer resources. ScrumMaster is a role fulfilled by someone on the Team.
That aside, the Product Owner is the "on the Team project manager", and should be fighting to secure the resources that are needed to stablize the product into production.
Engineering practices have to be improved so that the Team(s) are approaching zero bugs. "Bugs" that live past the end of a Sprint have to go on the Product Backlog to be prioritized by the the Product Owner.
This is a very interesting topic, project management is vital and the apprpriate allocation of resources is essential.
One point I would raise is that having dedicated bug fixers may increase the quality of the code. If I was developing code that had my name against it that I knew other people were responsible for I would do everything I coudl to make sure it was good code.
Perhaps a combination approach is required.. You could take a couple of developers on any project - a different pair on each project - and make them resposible for the bug fixing phase outlining that responsibility up front. That way they can ensure they are up to speed as the project goes along as well as a handover at the end. Your resource allocation is easier and the client gets top notch support.
Your team should NOT be starting new project work until the current one ships. I think most scrum practitioners would argue that there is no place in scrum for UAT (as it was done in waterfall). What you are looking for is called a stabilization sprint and is your last sprint right before go-live. The WHOLE team works on it. Stuff that gets done during this time includes last minute bugs, GUI beautification tweaks, roll-out documentation, help guides, operations training, and long lunches. It is also potentially a great time for the team to learn something new on their own without the "pressure" of delivering backlog items or to unwind a little before starting something new. Based on your customer's UAT timeframe expectations; if it tends to be on the longer side; you might also put off non-customer facing tasks to this sprint such as log monitoring, server setup scripting, maintenance screens, or other misc tool building.
Whatever you do, don't do any work outside of the Sprint boundaries. It is a slippery slope into waterfall-esque scheduling oblivion.
I think bugs should be fixed by the original developer. Making developers to fix bugs in code that was written by someone else could take a lot more time and moreover could make them demotivated since fixing bugs is not that very exiting.
I vote for #2. As a developer I hate context switching and that's what you essentially impose with #1. As for the code ownership issue, having developers own pieces of code is an anti-pattern. Strive for shared ownership: introduce pairing, rotation etc.
To second @kevindtimm's comment, UAT is just another sprint. Perhaps w/ less developers.
On the other hand, the core of Agile Software manifesto is to deliver business value incrementally, so ideally you're supposed to push to PROD at the end of each sprint. If so then shouldn't UAT be part of every single sprint. Isn't that what the Demo is for?
I am a lead developer in a Scrum driven team. The way that we tend to work it in my organisation is this:
Before the starts of a sprint each developer will be allocated a percentage of how productive we think they are going to be during the sprint. For example a more skilled more experienced developer will probably be able to be productive 70-80% of his total time during the sprint. This gives time for unexpected meetings, bug fixes. I will come onto the bug fixes in a moment. We will get the estimates for all the tasks signed off and then plan the developers work.
Going into the sprint the developer will carry out his planned work and complete his own testing. If Possible as each block of work is completed another testing phase will take place either by the Scrum leader or the product owner (project manager) just to make sure that there isn’t anything glaringly obvious that needs to be looked at. Anything that comes up in this testing phase goes straight back to the developer that wrote it to complete in the sprint. The way we see it is that the team has effectively committed to completing the tasks given to us at the beginning of a sprint so we needs to complete them one way or another.
If an urgent bug comes into the team and it has to be done right this minute then myself and the scrum leader will take a view on whether or not it it is possible to get it done without effecting the planned work depending on how well we are doing. I.E. if we are half a day ahead of schedule and the estimate on the bug is half a day we will do it without changing the planned work. If that’s not possible we go back to the product owner who decides what it is that has to be pulled out of the sprint.
If a non urgent bug is assigned to the team part way through a sprint then the product owner give it a priority and it will remain in our pot. When the product owner then comes up with our next set of objectives he will prioritise the bugs and the project work together and these will become our planned items for the next sprint.
The thing to note is that it doesn’t matter which project the bug came from. Everything has a priority and that is what needs to be managed. After all you only have a certain development resource. When it comes to which developer does it that depends on several things. you don't always know exactly whose code introduced the bug. Especially if it’s from a very old project. If the same developer can fix it then there is obviously a time benefit there but that exact developer might not be available. The way that we try and work it is that any developer should be able to work on any given task. In the real world this isn't always possible but that that is always our end goal.
I realise that I have been beating around the bush here but in answer to your question about who should do the bug fix in short this is what I would say:
If the bug is identified during the same sprint that the work was being done then send it back to the original developer.
If its urgent then it has to go to the best person to do the task because it needs to done as fast as possible. That might not be the person that originally wrote the code it might be someone with more experience.
If you have prioritised and planned the bug then you should also have time to work out who is the best man to do the job. This would be based on the other work that needed doing, the availability of developers and your general judgment.
With regards to handovers these should be fairly minimal. At the end of the day your developers should be writing code in a way which makes it clear, clean and obvious to any developer that has a task to revisit it. It is part of my job to make sure the developers on the team are doing this basically.
在我看来，如果某些错误比某些卡片更重要，那么这一部分就由产品负责人来确定优先顺序。如果采购订单是“立即修复这些错误”，那么应该将错误修复移至列表顶部。如果存在大量高优先级错误，那么可能值得进行稳定冲刺，修复错误并且不完成新功能。我很想问 PO 他们希望在 bug 上花费多少时间，尽管我不确定这有多实用。
Part of this falls onto the Product Owner to prioritize if some bugs are more important than some cards to my mind. If the PO is, "Fix these bugs NOW," then there should be bug fixes moved up to the top of the list. If there are numerous high priority bugs then it may be worth having a stabilization sprint where bugs are fixed and no new functionality gets done. I'd be tempted to ask the PO how much time they want spent on bugs though I'm not sure how practical that is.
The idea of having maintenance developers is nice but have you considered where there may be some pain in having to merge code changes from what maintenance does and what those developing new functionality do? Yeah, this is merely stepping on toes but I have had some painful merges where a day was spent with 2 developers trying to promote code due to so many changes between a test and dev environment.
May I suggest the idea of another developer fixing the bug so that someone else picks up how something was coded? Having multiple people work on some feature can help promote collective ownership rather than individual ownership of the code. Another part is that sometimes someone else may have an easier time with a bug because they have fixed that kind of bug before though this can also lead to a dependency that should be checked regularly.
Why not capture a backlog item called "bug debt", and have the team estimate it each iteration. That item will be used to hold some developer's time to fix it (as in #1).
I'm also a little concerned about the bugs that appear in UAT. Would it be possible to have some of those testing folks on the teams to catch them earlier? This kind of thing is very common in projects where it's thrown over the fence from group to group. The only way I have seen that works is to integrate those other groups into the teams and rethink the testing strategies. Then, UAT does what you want it to do... capture usability issues and requirements. You're right they won't go away completely, but they will be minimized.
I think people should fix their own code as well. Why waste all the time with handovers?
It might be worth doing UATs as and when each feature is complete; so the "testers" working along side the "developers" testing functionality as they go. The testers should be able to run through the UAT criteria.
If there are more issues within the UAT with the stake holders, then they are change requests or the acceptance criteria is probably ambiguous in the first place!
I've generally followed option 1. Often because resources go to other projects. If you do root cause analysis by discussing how bugs were created, there's a small side effect of public embarrassment. If you've instilled any sense of ownership on a project, your developers should be more than a bit embarrassed if their code is displaying a higher percentage of bugs than others or what is reasonable.
I typically find that in these cases, most developers are actually frustrated if their too busy to fix their old bugs. They don't like it when somebody else has to clean up their mistakes.
Instilling a sense of ownership and pride are critical. If you haven't done that, you are always counting on the threat of punishment to get them to do the right things.
Always try to have the original developer fix their own bugs, IMHO. This part is easy. If you've got a few developers who behave unprofessionally and shirk their duty to produce high quality software, give them the boot. If the problem is cultural, read "Fearless Change" by Linda Rising and get to work in your SM role as change agent. I'm right there with you, so this isn't me just beating you over the head; I'm doing the same thing at my job :).
However, you've got bigger problems.
You're a Scrum Master allocating resources? Yikes. The Scrum guide calls the SM to
...[serve] the Development Team in several ways, including:
Coaching the Development Team in self-organization...
I understand we all don't have the ideal organization within which to practice Scrum; however, this should gnaw at you daily until it is improved. The Scrum gude puts it simply:
Development Teams are structured and empowered by the organization to organize and manage their own work.
**Second, stop saying resources. Just stop it. Resources are coal, wood, and natural gas. People are not resources.**
Third, this UAT is a big impediment to the Scrum team. If I'm understanding you correctly, the client has a giant, red button they can press and completely blow up "Done" work by saying, "You've got to fix this before it's finished." Any Scrum Teams subjected to this no longer have velocity, forecasts etc. These things all measure "Done" and potentially "Done" work; they depend on "Done" software that is potentially shippable. Heres how the Scrum guide describes the Product Increment:
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
You can improve this UAT situation in several ways:
Convert the client's UAT to a simple feedback loop i.e. feature requests come out of the UAT, not notifications of incomplete software.
Get their UAT testers to work alongside the Developers during the Sprint and make sure the work is "Done."
Do not take work into a Sprint unless a UAT person is available to validate the work is fit for purpose.
I realize none of these will seem "commercially" plausable, but you're the SM. If no one else in the whole organization is saying these things, you have always got to be willing to.
I realize this sounds like a kick in the pants, but you need to year it from someone. This is a bit like the old shoe / glass bottle scenario from (wow) 10 years ago now.
Please feel free to reach out to me if you want to explore this further. I'm a fellow Scrum Master, and would be happy to help you work through this tough scenario.
发布评论
评论（13）
人们应该修复自己的代码。利用这样一个事实：当他们可以编写新东西时，没有人喜欢回去修复旧东西。如果可以确定对错误负责的开发人员，请确保他们负责解决问题。这将鼓励开发人员第一次更加勤奋地编写干净的代码，因为没有人希望被视为必须不断修复他们所破坏的东西的人。在开发过程中也是如此，当有人破坏当前构建时也是如此。
更新：话虽如此，我不一定对此持教条态度。客户的需求是第一位的，如果无法重新指派制造错误的人来进行修复，您可能必须将修复指派给其他人。
People should fix their own code. Take advantage of the fact that no one likes going back and fixing old stuff when they could be writing new stuff. If the developer responsible for the bug can be identified, make sure they are responsible for fixing the problem. This will encourage developers to be more diligent in writing clean code the first time since no one wants to be seen as the person who has to keeping fixing things they've broken. This is true during development as well when someone breaks the current build.
Update: Having said that, I wouldn't necessarily be dogmatic about it. The customer's needs come first and if the person who created the bug can't be reassigned to do the fix, you may have to assign the fix to someone else.
ScrumMaster 不分配开发人员资源。 ScrumMaster 是由团队中的某个人担任的角色。
除此之外，产品负责人是“团队项目经理”，应该努力确保产品稳定投入生产所需的资源。
必须改进工程实践，以便团队接近零错误。 Sprint 结束后存在的“Bug”必须列入产品待办事项列表中，以便产品负责人确定优先级。
ScrumMasters don't allocate developer resources. ScrumMaster is a role fulfilled by someone on the Team.
That aside, the Product Owner is the "on the Team project manager", and should be fighting to secure the resources that are needed to stablize the product into production.
Engineering practices have to be improved so that the Team(s) are approaching zero bugs. "Bugs" that live past the end of a Sprint have to go on the Product Backlog to be prioritized by the the Product Owner.
这是一个非常有趣的话题，项目管理至关重要，资源的适当分配也至关重要。
我要提出的一点是，拥有专门的错误修复程序可能会提高代码的质量。如果我正在开发的代码有我的名字反对，并且我知道其他人对此负责，我会尽我所能来确保它是好的代码。
也许需要采用组合方法。您可以在任何项目中安排几名开发人员（每个项目配备不同的开发人员），并让他们负责错误修复阶段，并预先概述该职责。这样他们就可以确保他们跟上项目的进展以及最后的移交。您的资源分配更加容易，客户可以获得一流的支持。
只是看待它的方式略有不同。
干杯
内森
This is a very interesting topic, project management is vital and the apprpriate allocation of resources is essential.
One point I would raise is that having dedicated bug fixers may increase the quality of the code. If I was developing code that had my name against it that I knew other people were responsible for I would do everything I coudl to make sure it was good code.
Perhaps a combination approach is required.. You could take a couple of developers on any project - a different pair on each project - and make them resposible for the bug fixing phase outlining that responsibility up front. That way they can ensure they are up to speed as the project goes along as well as a handover at the end. Your resource allocation is easier and the client gets top notch support.
Just a slightly different way of looking at it.
Cheers
Nathan
在当前项目交付之前，您的团队不应开始新的项目工作。我认为大多数 Scrum 从业者都会认为 Scrum 中没有 UAT 的位置（因为它是在瀑布中完成的）。您正在寻找的称为稳定冲刺，是上线前的最后冲刺。整个团队都在努力。这段时间完成的事情包括最后一刻的错误、GUI 美化调整、推出文档、帮助指南、操作培训和长时间的午餐。对于团队来说，这也可能是一个很好的时机，让他们可以在没有交付积压项目的“压力”的情况下自己学习新东西，或者在开始新事物之前放松一下。基于客户的 UAT 时间范围预期；如果它倾向于较长的一侧；您还可以将非面向客户的任务推迟到此冲刺，例如日志监控、服务器设置脚本、维护屏幕或其他杂项工具构建。
无论你做什么，都不要在 Sprint 边界之外进行任何工作。这是一个滑向瀑布式调度遗忘的斜坡。
Your team should NOT be starting new project work until the current one ships. I think most scrum practitioners would argue that there is no place in scrum for UAT (as it was done in waterfall). What you are looking for is called a stabilization sprint and is your last sprint right before go-live. The WHOLE team works on it. Stuff that gets done during this time includes last minute bugs, GUI beautification tweaks, roll-out documentation, help guides, operations training, and long lunches. It is also potentially a great time for the team to learn something new on their own without the "pressure" of delivering backlog items or to unwind a little before starting something new. Based on your customer's UAT timeframe expectations; if it tends to be on the longer side; you might also put off non-customer facing tasks to this sprint such as log monitoring, server setup scripting, maintenance screens, or other misc tool building.
Whatever you do, don't do any work outside of the Sprint boundaries. It is a slippery slope into waterfall-esque scheduling oblivion.
我认为错误应该由原始开发人员修复。让开发人员修复其他人编写的代码中的错误可能会花费更多时间，而且可能会让他们失去动力，因为修复错误并不是那么令人兴奋。
I think bugs should be fixed by the original developer. Making developers to fix bugs in code that was written by someone else could take a lot more time and moreover could make them demotivated since fixing bugs is not that very exiting.
我投票给#2。作为一名开发人员，我讨厌上下文切换，而这正是您在 #1 中强加的。至于代码所有权问题，让开发人员拥有代码片段是一种反模式。争取共享所有权：引入结对、轮换等。
对于 @kevindtimm 的评论，UAT 只是另一个冲刺。也许开发人员较少。
另一方面，敏捷软件宣言的核心是逐步交付业务价值，因此理想情况下，您应该在每个冲刺结束时推动产品开发。如果是这样，那么 UAT 不应该成为每个冲刺的一部分。这不就是 Demo 的用途吗？
I vote for #2. As a developer I hate context switching and that's what you essentially impose with #1. As for the code ownership issue, having developers own pieces of code is an anti-pattern. Strive for shared ownership: introduce pairing, rotation etc.
To second @kevindtimm's comment, UAT is just another sprint. Perhaps w/ less developers.
On the other hand, the core of Agile Software manifesto is to deliver business value incrementally, so ideally you're supposed to push to PROD at the end of each sprint. If so then shouldn't UAT be part of every single sprint. Isn't that what the Demo is for?
我真的不喜欢选项2），因为：
所以选项 1) 是我的偏好（但请停止谈论资源和资源）。
最后引用一点：
是的，我知道，说起来容易做起来难……但尽管如此，她是对的。
I really don't like option 2) because:
So option 1) has my preference (but please stop talking about resources and resourcing).
Finally, a little quote:
Yes, I know, it's easier to say than to do... but nevertheless, she's damn right.
我是 Scrum 驱动团队的首席开发人员。我们在我的组织中倾向于这样的工作方式：
在冲刺开始之前，每个开发人员将被分配我们认为他们在冲刺期间的生产力百分比。例如，技术更熟练、经验更丰富的开发人员在冲刺期间可能能够在其总时间的 70-80% 中保持高效。这为意外会议和错误修复提供了时间。我稍后会讨论错误修复。我们将获得所有已签署任务的估算，然后规划开发人员的工作。
进入冲刺后，开发人员将执行他计划的工作并完成他自己的测试。如果可能的话，当每个工作块完成时，Scrum 领导者或产品负责人（项目经理）将进行另一个测试阶段，以确保没有任何明显需要查看的内容。此测试阶段出现的任何内容都会直接返回到编写它的开发人员以在冲刺中完成。我们认为，团队已经有效地致力于完成冲刺开始时交给我们的任务，因此我们需要以某种方式完成它们。
如果团队中出现紧急错误并且必须立即完成，那么我和 scrum 领导者将根据我们的表现来考虑是否可以在不影响计划工作的情况下完成它正在做。 IE如果我们比计划提前半天，并且对bug的估计是半天，我们将在不改变计划工作的情况下完成。如果这是不可能的，我们会回到产品负责人那里，由他来决定必须从冲刺中删除什么。
如果在冲刺期间将非紧急错误分配给团队，那么产品负责人会优先考虑它，并且它将保留在我们的锅中。当产品负责人提出我们的下一组目标时，他将优先考虑错误和项目一起工作，这些将成为我们下一个冲刺的计划项目。
需要注意的是，错误来自哪个项目并不重要。一切都有优先级，这就是需要管理的。毕竟你只有一定的开发资源。至于由哪个开发人员来做这取决于几件事。您并不总是确切地知道是谁的代码引入了该错误。特别是如果它来自一个非常古老的项目。如果同一个开发人员可以修复它，那么显然会带来时间优势，但可能无法找到确切的开发人员。我们尝试和工作的方式是任何开发人员都应该能够完成任何给定的任务。在现实世界中，这并不总是可能的，但这始终是我们的最终目标。
我意识到我一直在这里拐弯抹角，但为了回答你关于谁应该修复错误的问题，简而言之，我会说：
至于移交，这些应该是相当少的。归根结底，您的开发人员应该以一种对任何需要重新访问代码的开发人员来说都清晰、干净且明显的方式编写代码。确保团队中的开发人员基本上都在这样做是我工作的一部分。
我希望这有帮助:)
I am a lead developer in a Scrum driven team. The way that we tend to work it in my organisation is this:
Before the starts of a sprint each developer will be allocated a percentage of how productive we think they are going to be during the sprint. For example a more skilled more experienced developer will probably be able to be productive 70-80% of his total time during the sprint. This gives time for unexpected meetings, bug fixes. I will come onto the bug fixes in a moment. We will get the estimates for all the tasks signed off and then plan the developers work.
Going into the sprint the developer will carry out his planned work and complete his own testing. If Possible as each block of work is completed another testing phase will take place either by the Scrum leader or the product owner (project manager) just to make sure that there isn’t anything glaringly obvious that needs to be looked at. Anything that comes up in this testing phase goes straight back to the developer that wrote it to complete in the sprint. The way we see it is that the team has effectively committed to completing the tasks given to us at the beginning of a sprint so we needs to complete them one way or another.
If an urgent bug comes into the team and it has to be done right this minute then myself and the scrum leader will take a view on whether or not it it is possible to get it done without effecting the planned work depending on how well we are doing. I.E. if we are half a day ahead of schedule and the estimate on the bug is half a day we will do it without changing the planned work. If that’s not possible we go back to the product owner who decides what it is that has to be pulled out of the sprint.
If a non urgent bug is assigned to the team part way through a sprint then the product owner give it a priority and it will remain in our pot. When the product owner then comes up with our next set of objectives he will prioritise the bugs and the project work together and these will become our planned items for the next sprint.
The thing to note is that it doesn’t matter which project the bug came from. Everything has a priority and that is what needs to be managed. After all you only have a certain development resource. When it comes to which developer does it that depends on several things. you don't always know exactly whose code introduced the bug. Especially if it’s from a very old project. If the same developer can fix it then there is obviously a time benefit there but that exact developer might not be available. The way that we try and work it is that any developer should be able to work on any given task. In the real world this isn't always possible but that that is always our end goal.
I realise that I have been beating around the bush here but in answer to your question about who should do the bug fix in short this is what I would say:
With regards to handovers these should be fairly minimal. At the end of the day your developers should be writing code in a way which makes it clear, clean and obvious to any developer that has a task to revisit it. It is part of my job to make sure the developers on the team are doing this basically.
I hope that this helps :)
在我看来，如果某些错误比某些卡片更重要，那么这一部分就由产品负责人来确定优先顺序。如果采购订单是“立即修复这些错误”，那么应该将错误修复移至列表顶部。如果存在大量高优先级错误，那么可能值得进行稳定冲刺，修复错误并且不完成新功能。我很想问 PO 他们希望在 bug 上花费多少时间，尽管我不确定这有多实用。
拥有维护开发人员的想法很好，但是您是否考虑过必须合并维护工作和开发新功能的代码更改可能会带来一些痛苦？是的，这只是踩到脚趾，但我经历过一些痛苦的合并，由于测试和开发环境之间发生了如此多的变化，我花了一天的时间与 2 名开发人员一起尝试升级代码。
我可以建议另一位开发人员修复该错误，以便其他人了解某些内容是如何编码的吗？让多人处理某些功能有助于促进代码的集体所有权，而不是个人所有权。另一部分是，有时其他人可能会更容易地处理错误，因为他们之前已经修复了此类错误，尽管这也可能导致应定期检查的依赖关系。
Part of this falls onto the Product Owner to prioritize if some bugs are more important than some cards to my mind. If the PO is, "Fix these bugs NOW," then there should be bug fixes moved up to the top of the list. If there are numerous high priority bugs then it may be worth having a stabilization sprint where bugs are fixed and no new functionality gets done. I'd be tempted to ask the PO how much time they want spent on bugs though I'm not sure how practical that is.
The idea of having maintenance developers is nice but have you considered where there may be some pain in having to merge code changes from what maintenance does and what those developing new functionality do? Yeah, this is merely stepping on toes but I have had some painful merges where a day was spent with 2 developers trying to promote code due to so many changes between a test and dev environment.
May I suggest the idea of another developer fixing the bug so that someone else picks up how something was coded? Having multiple people work on some feature can help promote collective ownership rather than individual ownership of the code. Another part is that sometimes someone else may have an easier time with a bug because they have fixed that kind of bug before though this can also lead to a dependency that should be checked regularly.
为什么不捕获一个称为“错误债务”的积压项目，并让团队在每次迭代中对其进行估计。该项目将用于保留一些开发人员的时间来修复它（如#1 中所示）。
我也有点担心 UAT 中出现的 bug。是否有可能让团队中的一些测试人员更早地发现它们？这种事情在项目中很常见，从一个组到另一个组都被扔到了栅栏之外。我认为有效的唯一方法是将其他小组整合到团队中并重新考虑测试策略。然后，UAT 会执行您希望它执行的操作...捕获可用性问题和需求。你是对的，它们不会完全消失，但它们会被最小化。
Why not capture a backlog item called "bug debt", and have the team estimate it each iteration. That item will be used to hold some developer's time to fix it (as in #1).
I'm also a little concerned about the bugs that appear in UAT. Would it be possible to have some of those testing folks on the teams to catch them earlier? This kind of thing is very common in projects where it's thrown over the fence from group to group. The only way I have seen that works is to integrate those other groups into the teams and rethink the testing strategies. Then, UAT does what you want it to do... capture usability issues and requirements. You're right they won't go away completely, but they will be minimized.
我认为人们也应该修复自己的代码。为什么要把时间浪费在交接上呢？
当每个功能完成后，可能值得进行 UAT；因此，“测试人员”与“开发人员”一起工作，测试功能。测试人员应该能够执行 UAT 标准。
如果 UAT 中与利益相关者存在更多问题，那么这些问题就是变更请求，或者验收标准可能一开始就不明确！
I think people should fix their own code as well. Why waste all the time with handovers?
It might be worth doing UATs as and when each feature is complete; so the "testers" working along side the "developers" testing functionality as they go. The testers should be able to run through the UAT criteria.
If there are more issues within the UAT with the stake holders, then they are change requests or the acceptance criteria is probably ambiguous in the first place!
我通常遵循选项 1。通常是因为资源流向了其他项目。如果您通过讨论错误是如何产生的来进行根本原因分析，那么会产生公众尴尬的小副作用。如果您已经在项目中灌输了任何主人翁意识，那么如果您的开发人员的代码显示出比其他代码更高的错误百分比或合理的错误百分比，那么您的开发人员应该会感到有点尴尬。
我通常发现，在这些情况下，大多数开发人员如果太忙而无法修复旧的错误，实际上会感到沮丧。他们不喜欢别人来纠正他们的错误。
灌输主人翁意识和自豪感至关重要。如果你没有这样做，你总是指望惩罚的威胁来让他们做正确的事情。
I've generally followed option 1. Often because resources go to other projects. If you do root cause analysis by discussing how bugs were created, there's a small side effect of public embarrassment. If you've instilled any sense of ownership on a project, your developers should be more than a bit embarrassed if their code is displaying a higher percentage of bugs than others or what is reasonable.
I typically find that in these cases, most developers are actually frustrated if their too busy to fix their old bugs. They don't like it when somebody else has to clean up their mistakes.
Instilling a sense of ownership and pride are critical. If you haven't done that, you are always counting on the threat of punishment to get them to do the right things.
恕我直言，始终尝试让原始开发人员修复他们自己的错误。这部分很简单。如果你有一些开发人员表现不专业，逃避生产高质量软件的责任，那就开除他们。如果问题是文化问题，请阅读琳达·瑞辛 (Linda Rising) 所著的《无畏变革》，并开始扮演变革推动者的 SM 角色。我就在你身边，所以这不是我在敲你的头；而是我在敲你的头。我在工作中也在做同样的事情:)。
但是，您遇到了更大的问题。
您是分配资源的 Scrum Master？哎呀。 Scrum 指南 要求 SM
我知道我们都没有实践 Scrum 的理想组织；然而，这应该每天都困扰着你，直到它得到改善。 Scrum 指南简单地说：
**第二，停止说资源。就停止吧。资源有煤炭、木材、天然气。人不是资源。**
第三，这个UAT对于Scrum团队来说是一个很大的障碍。如果我没理解错的话，客户有一个巨大的红色按钮，他们可以按下并通过说“你必须在完成之前解决这个问题”来彻底毁掉“已完成”的工作。任何受此影响的 Scrum 团队都不再有速度、预测等。这些东西都衡量“完成”和潜在“完成”的工作；他们依赖于可能可交付的“完成”软件。以下是 Scrum 指南对产品增量的描述：
您可以通过多种方式改善这种 UAT 情况：
我意识到这些在“商业”上似乎都不合理，但你是 SM。如果整个组织中没有其他人说这些话，那么你必须始终愿意这样做。
我意识到这听起来像是一个小动作，但你需要从某人那里得到它。这有点像旧鞋/玻璃瓶 10 年前的场景（哇）。
如果您想进一步探索这一点，请随时与我联系。我是一名 Scrum Master，很乐意帮助您解决这个困难的情况。
Always try to have the original developer fix their own bugs, IMHO. This part is easy. If you've got a few developers who behave unprofessionally and shirk their duty to produce high quality software, give them the boot. If the problem is cultural, read "Fearless Change" by Linda Rising and get to work in your SM role as change agent. I'm right there with you, so this isn't me just beating you over the head; I'm doing the same thing at my job :).
However, you've got bigger problems.
You're a Scrum Master allocating resources? Yikes. The Scrum guide calls the SM to
I understand we all don't have the ideal organization within which to practice Scrum; however, this should gnaw at you daily until it is improved. The Scrum gude puts it simply:
**Second, stop saying resources. Just stop it. Resources are coal, wood, and natural gas. People are not resources.**
Third, this UAT is a big impediment to the Scrum team. If I'm understanding you correctly, the client has a giant, red button they can press and completely blow up "Done" work by saying, "You've got to fix this before it's finished." Any Scrum Teams subjected to this no longer have velocity, forecasts etc. These things all measure "Done" and potentially "Done" work; they depend on "Done" software that is potentially shippable. Heres how the Scrum guide describes the Product Increment:
You can improve this UAT situation in several ways:
I realize none of these will seem "commercially" plausable, but you're the SM. If no one else in the whole organization is saying these things, you have always got to be willing to.
I realize this sounds like a kick in the pants, but you need to year it from someone. This is a bit like the old shoe / glass bottle scenario from (wow) 10 years ago now.
Please feel free to reach out to me if you want to explore this further. I'm a fellow Scrum Master, and would be happy to help you work through this tough scenario.