我成为一个新成立的团队的Scrum Master,负责创建软件和维护其他已部署的应用程序。因此,基本上每个团队成员都有开发和运营任务。
在过去的几周中,我一直在观察他们的工作方式,我注意到团队在协调这些任务时遇到了麻烦。当开发人员专注于编码时,他会被打扰以解决生产中出现的问题,这使他很难再次专注于先前的任务。
我尝试分配%的开发人员时间用于操作工作,但是显然,这不能解决问题。我很想听听曾经遇到过这种情况的Scrum管理员的来信,您如何处理这种情况以及您有什么建议?
我成为一个新成立的团队的Scrum Master,负责创建软件和维护其他已部署的应用程序。因此,基本上每个团队成员都有开发和运营任务。
在过去的几周中,我一直在观察他们的工作方式,我注意到团队在协调这些任务时遇到了麻烦。当开发人员专注于编码时,他会被打扰以解决生产中出现的问题,这使他很难再次专注于先前的任务。
我尝试分配%的开发人员时间用于操作工作,但是显然,这不能解决问题。我很想听听曾经遇到过这种情况的Scrum管理员的来信,您如何处理这种情况以及您有什么建议?
Answers:
这个问题与scrum一样古老。有一个解决方案,但是您不喜欢它。
将您的开发人员置于一个以上的Scrum中,有两个单独的待办事项,或仅将其时间的一部分分配给sprint,这一切都与Scrum试图实现的目标(即一致的已完成任务流)相反。
如果您尝试这些类型的事情,则基本上会回到“混乱”或“ JFDI”开发方法论,并遇到所有附带的问题,例如
当然,对此建议的通常回答是“但是我不能这样做!企业需要尽快修复那些生产错误!”
但这不是真的。
如果您确实有许多实际的错误会在一定程度上影响业务,那么您需要变得专业并改善测试。只需修复错误和自动测试,直到将它们全部修复即可。雇用QA团队并测试所有新版本中的地狱。
但是,更有可能是以下之一:
这些错误是操作问题,磁盘空间不足,没有灾难恢复,没有备份,没有故障转移等。请建立一个OPS团队。
这些错误是用户不了解系统应该如何工作的“发生了!这是一个错误吗?”。获取服务台并培训您的用户,编写文档。
担心回滚。您启动了一项新功能,但它损坏了某些内容,请勿尝试匆忙修复。回滚到以前的版本,并将这些错误放入待办事项列表中。
只是想在这里跳出框框思考。
由于可能无法让产品负责人以自己的方式看待事物。仍然可能存在一些严重的错误,这些错误根本无法等待,在需要开发人员帮助的情况下与客户会面,等等。在这种情况下,您需要暂时让一名开发人员脱离冲刺。
为什么不尝试预见并利用它来为您谋取利益呢?
您可能需要5人以上的团队才能现实。
但是,为什么不从每个冲刺中抽出一名开发人员呢(在开发人员之间轮换,每个轮到他们了)。
由于很可能没有足够的错误来使用完整的开发人员来进行更正,因此还有其他问题或可以完成的任务。
团队速度可能会上升,压力可能会下降,与管理层的冲突可能会下降,您实际上有时间改善知识。
一种有效的解决方案,用于管理开发人员为解决我已经使用过的真正重要的生产问题而付出的努力。
开发新功能时,生产支持责任的昂贵方面是上下文切换,因此您应该限制这一点。
加入团队后,创建团队成员列表并进行循环浏览,以便每天在站立会议上将一个新人员声明为“蝙蝠侠”,并将在当天回答重要的生产问题。团队的其余成员可以继续专注于开发,而不必进行上下文切换,每个人都有相当大的支持痛苦。在一个5人的团队中,这意味着每周可能有一天开发人员被打扰,而连续4天的开发时间是可预测的。
这具有在团队之间共享知识/经验的好处,因此您没有人负责解决特定问题并成为单点故障和支持问题的公平分配。