干扰,正如它名字所显示的,是影响敏捷项目团队速度、减缓其前进的刹车闸。有些干扰是必需的,其他则不是。关键在于:要识别出影响工作进程的干扰,并尽量减少它对项目的负面影响。
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个全职人员那样始终坐在一起。两个全职的人,基本上不需要什么协调,也没有多少沟通上的无谓消耗。
讨论组的人都认为:要去除与这些主要的干扰相关的风险,应该从两方面下手:牺牲一个人,让他来处理所有的次要任务;还要注意不要让一个人同时参加多个任务。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14639675/viewspace-567465/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14639675/viewspace-567465/