应对敏捷项目中的干扰

  • Vikas Hazrati
  • 郑柯

2008 年 6 月 6 日

话题:敏捷文化 & 方法

干扰,正如它名字所显示的,是影响敏捷项目团队速度、减缓其前进的刹车闸。有些干扰是必需的,其他则不是。关键在于:要识别出影响工作进程的干扰,并尽量减少它对项目的负面影响。

 Extreme Programming 讨论组上有一个有趣的讨论,Alistair Cockburn 在其中分享了他认为影响“团队涌流”的一些主要干扰:

(1) 过多会议(程序员必须放下工作去参加一个接一个的会议,以及)

(2) 过多同时进行的项目(程序员必须放下项目 A 的工作,切换到项目 B)。

这些干扰会消耗很多的时间和精力。不过一般总可以找到调整项目、会议和每天工作安排的方式,减少干扰,程序员也可以多花时间,进行不间断的编程。

Alistair 接着说道:团队中,有时必须有一个人完全负责接电话、参加会议、找人、做与客户的接口等工作。而此人的工作也因此而无法达到团队对他的期望。但是 Alistair 说,对这个人工作产出的期望,应该受限于他能够花在项目上的时间。

在他的众多项目管理模式中,Alistair 将此命名为“牺牲一个人”。Alistair 在这个模式里提出,一个项目可能无法像当初规划的运转那么快,这是因为有很重要的干扰占用了整个团队的时间。虽然干扰可能是很重要的次要任务,而且无法放弃;但是,它确实分散了团队在最主要的任务上的注意力。

Alistair 认为解决问题的方式是,分配一个人来专门应对干扰。虽然这个人可能觉得自己是牺牲品,但是团队剩余的成员可以通过处理最主要的任务来取得工作进展。

Gojko Adzic 也提供了类似的意见,他讲述了自己的故事:当时他在一个项目中承担架构师的工作,但却花费了很多时间来充当软件方面的润滑剂。相关的任务包括:解答新人的问题、协调不同的讨论、与客户沟通、参加各种会议。Gojko 补充道,如果他试着花更多时间在编程方面的任务上,很多其他团队成员就必须充当润滑剂,这拖慢了整个团队的速度。因此他决定接过来所有的次要工作,让其他人集中精力处理主要任务。Gojko 提到:

虽然我仍力图编写代码、了解项目的整体进度,但是团队在做计划时,已经不怎么再指望我的参与了——我的时间不会被计算在内。四个月之后回头再看看,考虑到项目的进度以及团队的工作效率,我认为这样解决问题很有效。

对于 Alistair 提出的第二个主要干扰,邮件组的成员们都同意:让人同时参与多个项目没法取得好的效果。对于这样带来的心态问题,Gojko 这样总结。

问题在于,如果你的成员是四、五个只能部分参与项目的人,项目干系人会认为你拥有一个完整的团队;而实际上,他们最多相当于一个全职投入的人,如果不是更少的话。

为了进一步表明支持人们专心投入单个项目,Gojko 说到:团队成员同时在多个项目中工作,沟通和协调工作会占用相当多的时间和精力。他举了下面这个很有趣的例子,来证明他的观点:

10 个投入程度为 20% 的人,他们的产出理论上相当于两个全职人员;但是协调这 10 个人却要比协调两个人花费更多的精力。而且与协调 10 个全职人员的精力花费相当,甚至有可能更多。我想这是因为下面的原因:由于其他工作的要求,这 10 个部分投入的人会经常无法参加站立会议和进度会议,而且不能像 10 个全职人员那样始终坐在一起。两个全职的人,基本上不需要什么协调,也没有多少沟通上的无谓消耗。

讨论组的人都认为:要去除与这些主要的干扰相关的风险,应该从两方面下手:牺牲一个人,让他来处理所有的次要任务;还要注意不要让一个人同时参加多个任务。

查看英文原文: Handling Interruptions on an Agile Project

敏捷文化 & 方法