如何协调Scrum中两个不同项目之间的开发人员时间?


40

我成为一个新成立的团队的Scrum Master,负责创建软件和维护其他已部署的应用程序。因此,基本上每个团队成员都有开发和运营任务。

在过去的几周中,我一直在观察他们的工作方式,我注意到团队在协调这些任务时遇到了麻烦。当开发人员专注于编码时,他会被打扰以解决生产中出现的问题,这使他很难再次专注于先前的任务。

我尝试分配%的开发人员时间用于操作工作,但是显然,这不能解决问题。我很想听听曾经遇到过这种情况的Scrum管理员的来信,您如何处理这种情况以及您有什么建议?


1
首先确定优先级并解决关键的生产错误,然后恢复正常开发。两者同时要求犯下错误。
Mark Rogers

Answers:


60

这个问题与scrum一样古老。有一个解决方案,但是您不喜欢它。

  • 将新任务放在待办事项上。
  • 不要打扰开发人员。
  • 等待下一个冲刺。

将您的开发人员置于一个以上的Scrum中,有两个单独的待办事项,或仅将其时间的一部分分配给sprint,这一切都与Scrum试图实现的目标(即一致的已完成任务流)相反。

如果您尝试这些类型的事情,则基本上会回到“混乱”或“ JFDI”开发方法论,并遇到所有附带的问题,例如

  • 开发人员可以随时执行十项任务。没有人知道他们在做什么或何时完成。
  • 未知的项目完成时间,因为这取决于同时进行的其他项目。
  • 没有一致的项目优先级视图。其他经理将开发人员转移到他们的宠物项目。

当然,对此建议的通常回答是“但是我不能这样做!企业需要尽快修复那些生产错误!”

但这不是真的。

如果您确实有许多实际的错误会在一定程度上影响业务,那么您需要变得专业并改善测试。只需修复错误和自动测试,直到将它们全部修复即可。雇用QA团队并测试所有新版本中的地狱。

但是,更有可能是以下之一:

  • 这些错误是操作问题,磁盘空间不足,没有灾难恢复,没有备份,没有故障转移等。请建立一个OPS团队。

  • 这些错误是用户不了解系统应该如何工作的“发生了!这是一个错误吗?”。获取服务台并培训您的用户,编写文档。

  • 担心回滚。您启动了一项新功能,但它损坏了某些内容,请勿尝试匆忙修复。回滚到以前的版本,并将这些错误放入待办事项列表中。


5
你的冲刺多长时间了?我会花一个星期的时间
Ewan,2016年

3
您可以不做任何评论而怀旧,也许每个月做一次。我认为将设计(UI设计?)作为独立的团队/冲刺是一个好主意。希望大多数时候设计是在开发者开始之前完成的,并且不会有太大变化
Ewan

3
产品负责人希望开发人员放下一切并处理生产错误,停止当前的sprint,修复错误并在完成后再开始另一个sprint。这些决定会带来后果,这将使产品所有者意识到对立即修复错误的影响。在紧急情况下,他们将不得不运用更多的判断力。或者,您可以等待下一次站起来时解决这些问题。这样,您可以看到谁拥有任何额外的带宽,并且不会中断开发人员的流程。
JeffO '16

5
如果您跳过审阅和回顾,并在单独的冲刺中进行设计,那么实际上并没有剩下任何Scrum……
Erik

6
您的解决方案是“获得公司的最高权限,然后通过创建三个全新的团队来花很多钱”?
与莫妮卡(Monica)进行的轻度比赛

25

只是想在这里跳出框框思考。

由于可能无法让产品负责人以自己的方式看待事物。仍然可能存在一些严重的错误,这些错误根本无法等待,在需要开发人员帮助的情况下与客户会面,等等。在这种情况下,您需要暂时让一名开发人员脱离冲刺。

为什么不尝试预见并利用它来为您谋取利益呢?

您可能需要5人以上的团队才能现实。

但是,为什么不从每个冲刺中抽出一名开发人员呢(在开发人员之间轮换,每个轮到他们了)。

由于很可能没有足够的错误来使用完整的开发人员来进行更正,因此还有其他问题或可以完成的任务。

  • 运行测试以识别性能瓶颈或可伸缩性问题
  • 维护构建系统
  • 与客户会面
  • 研究新的框架/库
  • 探索您想使用的语言功能
  • 阅读安全性问题
  • 数据库维护
  • 服务器维护

团队速度可能会上升,压力可能会下降,与管理层的冲突可能会下降,您实际上有时间改善知识。


3
我当时的想法是一样的-轮换一名开发人员来做“琐事”(生产问题),并且由于他不会完成很多实际工作,所以也让他进行研究/探索/其他不规则的事情。并对每个生产问题进行良好的根本原因分析,以使数量减少。
RemcoGerlich '16

1
这实际上是一个好主意!我将需要再雇用一两个开发人员,但我认为这是值得的。非常感谢!
Shadin

1
在我们的项目中,我们已在某种程度上正式确定了该职位。我们在每个团队中都有一位资深开发人员,并被指定为Scrum团队的技术负责人。TL会做很多事情(指导初级开发人员,在生产之前执行“ 4 + 1计划”,解决其他开发人员遇到的问题,等等),但是TL所要做的一件事就是处理热土豆生产问题,高优先级缺陷。显然,很多取决于您的生产系统/理念,但是TL可以进行干预以“屏蔽”团队的其余成员,并让他们专注于用户故事。
JBiggs '16

14

一种有效的解决方案,用于管理开发人员为解决我已经使用过的真正重要的生产问题而付出的努力。

开发新功能时,生产支持责任的昂贵方面是上下文切换,因此您应该限制这一点。

加入团队后,创建团队成员列表并进行循环浏览,以便每天在站立会议上将一个新人员声明为“蝙蝠侠”,并将在当天回答重要的生产问题。团队的其余成员可以继续专注于开发,而不必进行上下文切换,每个人都有相当大的支持痛苦。在一个5人的团队中,这意味着每周可能有一天开发人员被打扰,而连续4天的开发时间是可预测的。

这具有在团队之间共享知识/经验的好处,因此您没有人负责解决特定问题并成为单点故障和支持问题的公平分配。


一个非常有趣的方法,我相信它现在适用于我们的情况!非常感谢!
沙丁
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.