BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

由干扰驱动的开发

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2008年7月14日. 估计阅读时间: 6 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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中完成。”

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT