由干扰驱动的开发

阅读数:126 2008 年 7 月 12 日

话题:敏捷文化 & 方法

Scrum 要求在 sprint 中的干扰尽量少,这样团队可以高效工作以达成他们的目标。Scrum master 负责去除可能影响团队速度的障碍。然而在实际情况中,团队开发出新功能并供以发布的同时,他们还要面临产品支持方面的问题。对于团队来说,这些干扰也许只是分散注意力的小问题,而对于系统用户和产品负责人来说,它们却是非常重要的问题,必须解决。产品负责人会觉得:在现有系统不能正常运转之前,添加新功能是没有意义的。

Scrum Alliance wiki 中列出了一些干扰的例子,比如:

  • 一线技术支持人员无法完成技术支持工作
  • 系统维护任务
  • 对于调查奇怪的系统行为方面的要求
  • 对于系统数据方面的要求,这些数据难以获得而且需要开发人员参与
  • 客户的定制要求
  • 需要开发人员解决的产品问题(例如系统当机或性能低下)

上面列出的所有场景,都有可能演化成比开发新功能更重要的问题。那么在 sprint 中该如何应对这些干扰呢?

Geoff Watts如何在 Scrum 中应对这些干扰给出了自己的想法。

使用两个 backlog——一个供开发功能使用,另一个供解决产品支持问题使用。产品负责人定义每个 backlog 中要完成工作的比例。

这个方法需要团队使用两个燃尽图,一个供开发用户故事使用,一个供产品支持使用。

将 bug 作为功能请求——干扰可以放置在产品 backlog 中,并带有估算的业务价值和大小。Geoff 建议在使用这种方法时,要排定产品支持的问题与其他功能之间的优先级。他指出:此处的关键是要避免陷入争论,不要争论到底是产品支持的问题重要还是其他更重要。团队要理解、吸收有关优先级排定的讨论,而不是在二者之间划出分界线,这样才能取得更好的效果,同时更有工作效率。

紧急状况——有些干扰必须马上解决。Scrum master 和产品负责人是紧急状况的最好判断者。

如果发生的问题真得很紧急,产品负责人有权力打出“紧急状况”这张牌,只要他能够意识到这样做的代价——无法完成预先规划的功能,而且有可能无法达成 sprint 的目标。

另一个重要的问题是:“谁应该负责解决这些干扰?”产品支持很无聊,团伙成员也都不太愿意去干这个。那使用支持团队这个主意怎么样?Geoff 说:“使用支持团队会造成不必要的隔离,而且会带来混乱。”可以在团队中设定一个支持者的角色,在每个 sprint 或每周的工作中发挥作用。这也可以增加团队的跨职能行为,同时还有益于提升系统的整体知识水平。

对于应对干扰,Alistair Cockburn提出的另外一种解决方法是:使用名为“牺牲一个人”的项目管理模式。他认为:解决问题的方法,是任命一个人专门解决这些干扰。虽然这个人可能觉得自己被牺牲了,团队其他人却可以通过处理主要的问题来取得进展。

总的来说,关于如何应对干扰,可以考虑将它们放到产品 backlog 中,并基于其业务价值排定优先级。这可以保证团队一直在做正确的事情。然而,如果干扰是紧急事件,那就要考虑一下解决成本了。要权衡马上解决对整个项目造成的影响,再做决定。

查看英文原文:Interruption Driven Development


对于这个话题,InfoQ 的读者 Kurt Christensen 给出了自己的解决方案:

对于进行中的维护工作,我使用起到占位符作用的故事(placeholder story),并取得了很好的效果。在 sprint 的开始,团队会根据上个 sprint 中的经验,估算出维护工作可能占用的时间。
对此,Kevin E. Schlabach 指出:
我也让我的团队使用了同样的方法。这样团队就能够解释为什么不能完成预期规划好的工作(当维护工作占用的时间不断变动时),基于此而得到的开发速度也是可以达成的,这对团队来说也是个激励。

这样做的负面效果是产生了不必要的开销(浪费),仅仅能够解释正在发生什么。有时,这样做几乎没有任何价值。因为团队和管理层根据过去的经验,接受了“支持速度”,并继续跟踪记录这个速度,这也变成“为了流程而流程”的一部分。所以我建议,大家要用时间盒来限制其时间,而且要进行回顾,看看如何减少其时间,能够接受多少这样的干扰作为正常的业务,以及如何不再对其进行记录以简化流程。最终,我希望团队可以将开发速度上的目标降低某个点,并接受由于支持工作造成的损失(能够做到自我管理的团队可以产生应对之策)。

对于 Alistair 的建议,我想他也一定支持这应该是个轮换的角色(每个迭代或是迭代中某个时间段)……重要的是,要让团队中最重要的人先来承担这个角色,这样大家都能清楚地知道该角色举足轻重。不要让新人或是能力稍差的人先做该工作。否则就会影响到团队的干劲儿,形成分裂:一些人是专门负责开发新功能的超级明星,另一些人则负责支持工作。

有读者 Dean Wampler 说:

我正在与这样的团队工作,开发人员和项目干系人都花了很多时间来处理类似的工作。我们试图跟踪记录这些努力,看看哪些部分可以通过自动化得到改进,让管理层知道“时间都花在什么上面了”。

对此,InfoQ 资深编辑 Deborah Hartmann 指出:

我曾工作过的某个团队曾经遇到过类似问题。他们决定在任务板上放置浅绿色的任务卡,每一张对应一个干扰。两周之中就累积了 N 多绿色的卡片!仅仅一个 sprint 过后,团队达成一致意见,要先解决掉这些干扰。这样做使得问题的规模暴露在众人面前。他们很快就不用绿卡片了,因为不再需要了。从那时起,干扰就被分类了:支持工作会被放到支持“桶”中,而其他的干扰则会这样应对:“是的,我们会把它放到下个 sprint 中完成。”