Scrum:一个很好的方法,只适用于"全程冲刺"开发人员的团队?

Mat*_*ieu 17 scrum

我们是一家软件开发公司.我们已经介绍了Scrum.
问题是开发人员不能像许多其他公司那样花时间在Scrum sprint上.在SCRUM项目任务中,他们必须做很多没有开发的事情!
我读过:Scrum不允许兼职开发人员

那么,您对此有何体验?
Scrum是一个很好的方法,只适用于那些只花时间专注于SCRUM sprint的开发任务的开发人员吗?

谢谢你的时间

Hal*_*ard 11

我正在为一家公司工作,这也是一个问题.我们正在尝试使用Scrum,但是遇到以下问题:

  • 如果存在重要的支持问题,我们必须放弃我们为解决该问题所做的一切,破坏冲刺.
  • 管理直接面向一些开发人员,他们希望完成特定的任务.
  • 一些开发人员偶尔需要执行特定任务(称之为特定旧产品的支持)
  • 有时,其中一个开发人员从sprint中删除以进行重要安装.
  • 基于管理层改进的想法,团队经常发生变化.

对于所有这些问题,本书不可能做Scrum.当团队中的人数一直在变化时,每个冲刺的速度基本上毫无价值.

我仍然发现你得到了一些好处:

  • 人们以团队形式工作,并从中受到启发和授权.
  • 仍然通过sprint的任务比没有使用Scrum/sprinting更好,因为反馈周期比不执行sprint时短得多.现在的共识是两周是个好时机.
  • 随着时间的推移,速度似乎达到平均水平,至少使管理层能够了解在更长的时间内可以完成多少工作.

因此,我的建议是去Scrum.正如在我的公司,当管理层和开发人员开始看到短周期等的一些好处时,他们将开始进行更改,以便更多被认为不是冲刺任务的工作将被制作成冲刺任务.所以我仍然看到尝试做Scrum的好处.无论如何,没有100%正确的方法来做Scrum,不管有些书有多么难以理解.

  • 你至少可以揭露后果,定义一个时间来为每个sprint专门解决问题(让我们说你团队能力的15%).这一次不会影响Sprint的目标,并且可以解决无法解决的问题.管理层会发现,预先减去这笔金额会削弱团队的生产力.预定特遣队的每一小时额外工作,明确表示当它结束时,产品负责人需要在Sprint的价值和问题之间做出决定,支付团队的承诺.透明度是关键! (5认同)

phi*_*ant 10

定义焦点因子,每个开发人员只能处理Sprint内容的时间比率.这个焦点因素可以解释您无法处理Sprint项目的时间(电子邮件,支持,会议......).

在Sprint计划中,只计划根据该重点因素可以实现的目标:如果团队有80小时的600小时,那么您将只计划480小时.

初始值可以任意决定,也可以根据前一次Sprint所取得的成果来决定:计划60天,完成45天,焦点因子为75%.

然后就是时间管理,如果非Scrum任务不是中断,那么最好同时拥有它们(例如,星期五,团队的每个成员都在处理这些其他任务,而不是Sprint任务).

对于团队的每个成员,这个焦点因素不需要相同.这也允许在团队中兼职.