• 2010-04-19

    非“敏捷”咨询(四)

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/62388497.html

    非“敏捷”咨询
    非“敏捷”咨询(二)
    非“敏捷”咨询(三)

    这次玩了回大的,同时带着三个团队做持续集成。

    其实,没那么夸张,虽然是三个团队,因为其相似性,要做的事基本上是一样的。本来只做一个团队的,但另外两个团队不干了,也要来点“咨询师”的阳光雨露。于是,组建一个联合团队,三个团队负责持续集成的人都坐到一起。我们的主要精力依然在原来的团队上,其它两个团队根据自己的情况在我们的适当辅导下,自己去实施自己的方案。

    这个联合团队运作了一段时间。我们主要带的团队已经基本上准备好持续集成所需的各种环境,并在一定规模进行了试点,准备大范围推广了。一个合作团队也写好了构建脚本,搭建好了CI的环境,也到了开始试水的阶段。而另一个合作团队,除了一个虚无缥缈的方案,一无所有。

    从情况来看,这个团队是最复杂的:他们依然在用着ClearCase,他们是一个分布式的团队,他们本地甚至没有验证环境……

    我参与过一次他们的例会,他们这边的领导同意把ClearCase切换到SVN上。但他们是分布式团队,而且,另外一边算是总部。于是,他们准备向那边汇报,安排在另外一次例会上。这个团队的持续集成负责人特意跑过来,和我约好,让我去帮忙解释一些情况,我同意了。后来,我又见到这个负责人。

    我:你们的会开了吗?
    负责人:别提了,会是开了,但这个议题被砍了。
    我:难怪没来找我。那你们的持续集成准备怎么办?
    负责人:本来我们还有一个版本不需要两地分布,可以单独来做。我和那个负责人说好从他们的团队做起,结果,人家告诉我最近几天要出差,等回来再说。
    我:你看,别的团队都有所进展。
    负责人:是啊!他们要做点什么都能立刻要来资源。我们的老大就是我往这一扔。

    对我而言,这位负责人语气中的无奈是那么熟悉。

    咨询师的身份让我有机会接触过很多团队负责敏捷推行的人。很多时候,领导们觉得推行敏捷要有个人负责,于是,有了这么个人,然后,以为自己的团队就可以走上敏捷的康庄大道。具体到事情上,一切如旧。初时,这些满怀理想的敏捷推行负责人都准备趁着东风大展拳脚,但要做的事情常常会被一句淡淡的“没有资源”给挡了回来。如是几次,这些负责人的心也冷了,于是,我也就有机会听到这种无奈。

    在大型团队中实施敏捷面临的问题多半与敏捷无关。如果只有几个人,可以手把手带过去,一个一个的进行辅导,但面对几十人甚至上百人的规模,就必须从组织上想办法了。而组织上的事,如果领导成为阻力,那几乎就是不可为的。下面的人偷偷摸摸的敏捷着,领导一句“别搞别的,赶紧把要交付的东西给我做完”,于是,一切如故了。这样的例子,我不止一次听到过。

    还好,我打交道的客户里面,直接喊不敏捷的几乎没有,但是,只是嘴上说说的却大有人在。他们会拍着我的肩膀说,你要好好帮帮我的团队啊!是的,我一个帮助者,但我不是一个主导者。团队敏捷实施,咨询师不能成为主导,也不应该成为主导。团队自身才应该是真正的主导,只有团队真正想改变了,咨询师才会起作用。医生都是等着病人上门,上赶子不是买卖:

    • 在上海的团队,团队的负责人经历过一次非常痛苦的开发,于是喊出“再也不能这么干”。
    • 在西安的团队,合作开始之前,他们已经自己探索了一段时间敏捷。
    • 这次在成都合作的主要团队,在我到来之前,就准备好了很多台计算机用做持续集成。

    那些并非真心想改变的团队,任何的困难都会让他们退缩:

    • 进度压力大,他们会放弃
    • 需要资源,他们会放弃
    • 改变习惯,他们会放弃
    • 开发效率初始的下降,他们会放弃
    • 技能需要提升,他们会放弃
    • ……

    喊出敏捷的口号之前,不妨问一下自己,准备好改变了吗?改变会比想像的影响要大,团队越大,越是如此。

    分享到:
    引用地址:

    评论

  • 现实啊,看起来就那么熟悉,似曾相识。