在您看来,谁应该修复错误？一个程序员,对吗？好的,但是真的,谁...让我解释一下.
我是一个跨越Scrum项目的Scrum Master.Scrum说'在可能的情况下围绕你的资源',这种情绪我全心全意地同意.
一般来说,我们将每个冲刺的某个%年龄整合到以前的冲刺中进行错误修复 - 一切都很好.
在每个Sprint之后,我们为客户演示和回顾,并将我们的开发代码推广到UAT环境(我们的客户通常不希望他的一小部分项目上线,但这取决于他们 - 我们保留我们的通过确保我们部署工作和可测试代码来讨价还价.
一旦所有冲刺完成,我们就有一个UAT阶段,客户端对完成的软件进行全面测试,以找出最后一分钟的错误.现在理想情况下这些已经被捕获,但实际上有一些只在UAT期间被发现.
在这个UAT阶段,并非100%的时间都不需要项目中的所有开发人员,因此我们希望将它们重新分配给其他项目.然而,Scrum说'尽可能围绕你的资源'.
我的问题是,我正在将开发人员分配到一个项目的UAT阶段,同时在其他地方启动一个单独的Scrum项目.不理想 - 但是,这是目前的商业现实.
我可以:
1)使用它并让开发人员修复自己的代码 - 并将开发人员的一些时间(比方说,20%)分配给之前项目的UAT.
2)确保切换到位,并且有1或2个开发人员100%的时间致力于修复代码.
我喜欢1),但它使资源在屁股上真正的痛苦.
2)让我害怕,我觉得开发人员不会对自己代码的质量负责.我觉得要确保开发人员拥有自己的代码并要求他们修复自己的错误是确保质量的好方法.没有人喜欢修复bug,所以我发现开发人员通常会先尝试做得更好,因为他们知道他们必须解决任何问题.但是,2)更容易规划和资源.但是2)将需要更长的时间,因为修复某人的错误代码在时间和资源方面是昂贵的.如果它是一个复杂的修复程序,它可能需要原始开发人员的帮助,并且由不熟悉代码库的那一部分的人修复肯定需要更长的时间.
人们怎么想？
tva*_*son 14
人们应该修复自己的代码.充分利用这样一个事实:当他们写新东西时,没有人喜欢回去修理旧东西.如果可以识别负责该bug的开发人员,请确保他们负责解决问题.这将鼓励开发人员在第一次编写清洁代码时更加勤奋,因为没有人希望被视为必须继续修复他们已经破坏的东西的人.在开发期间以及当有人打破当前构建时也是如此.
更新:话虽如此,我不一定会说教它.首先是客户的需求,如果创建错误的人无法重新分配以进行修复,则可能必须将修复程序分配给其他人.
ScrumMaster不分配开发人员资源.ScrumMaster是团队成员完成的角色.
除此之外,产品负责人是"团队项目经理",应该努力确保将产品稳定生产所需的资源.
必须改进工程实践,以便团队接近零错误.在Sprint结束时存在的"错误"必须在Product Backlog上进行,以便由产品负责人确定优先级.
这是一个非常有趣的主题,项目管理至关重要,适当的资源分配至关重要.
我要提出的一点是,拥有专用的bug修复程序可能会提高代码的质量.如果我正在开发具有我的名字的代码,我知道其他人负责我会尽我所能来确保它是好的代码.
也许需要一种组合方法.你可以在任何项目中使用几个开发人员 - 每个项目上都有一对不同 - 并使他们能够预先确定错误的错误修复阶段.这样他们就可以确保他们在项目进行过程中达到最快速度,并在最后进行交接.您的资源分配更容易,客户获得一流的支持.
只是略微不同的看待它的方式.
干杯内森