轻装上阵: 减少团队的启动时间作者 Pat Kua译者 韩锴 发布于 2007年12月4日 下午8时55分 面对现实:团队的变化在 过去的几年里,我和很多团队一起工作过,有的时间很长,有的则很短。我注意到在这些团队中,都面临一个相同的问题,即团队的成员总是在变化。通常,任何项目背后的变动都会引发这样的改变:比如员工生病或者度假,项目需求增加,出现新的项目或者仅仅是员工希望能改变当前的工作。然而像每日站立会议、结对编程等这样的敏捷实践,如果没有足够的上下文场景,就无法提供给新员工以足够有用的信息。这是因为敏捷实践并不能直接提供新团队成员的学习需要。因此我建议使用其他一些实践以便有效减少新成员的"启动时间"。 将排队论(Queuing theory)应用于团队中在制造业中,从订货到交货这段时间基本上都会分为四部分,包括:
由于从订货到交货这段时间的后两部分(移动和等候时间)不会影响一个独立的项目,因此我们的关注点通常都会落到前两部分上(启动和运作时间)。对于团队的新成员来说,启动时间指的就是他能融入团队并充分发挥自己能力所花费的时间。其中,团队需要吸收并培养新人,教会他们各种技巧,直到他们可以发挥自己最大的潜力为止。为这些事情所付出的所有时间和努力,构成了启动时间。运行时间则与成员在项目中工作的效率有关。 大多数过程都致力于促进团队的通力合作,帮助降低项目运营的开销。但是它们都忽略了一件事,减少新人用于熟悉环境所需的时间——比如,新成员多快可以加入到团队中,或者团队处理成员变更的能力有多强。 敏捷实践关注运行时间,而非启动时间"学习"对于每一种敏捷方法论都是不可分割的一部分。其中大多数都关注于短期的反馈环、进行自我反省以及强调持续改进。 但是,每个新进入项目的人在进入项目一段时间后,对学习的需求会变得大相径庭。 对于新的团队成员来说,消化信息的过程通常会带来更多的问题。像在Scrum站立会议上说的“我昨天做了……”这种话,会触发新人更多的问题,比如“他 们在说什么,这与我所了解的又有什么联系呢?”结对编程的效果也会有变化,如果结对的那个新人对整个项目有个大致的了解,效果会好些;但如果只是面对一个 接一个的User Story,效果就会很差,毕竟此时窥一斑而难以见全豹。我曾经见到过,当面对大量琐碎的信息碎片,也没有一条明确的线索将它们串连到一起时,很多团队的新员工都会感到很沮丧。 新人需要学习的主要内容是关于项目的概貌(larger context)。他们要找到应该了解的知识,逐步理解领域相关的词汇表,并融入团队及其文化。项目越复杂,加入的人数越多,这个阶段就需要持续更长的时间。了解了项目的概况之后,就要学习一些更加深入的知识了。有了概况中包含的信息,其他信息就变得更容易被接受了。每日站立会议、结对编程、测试驱动开发等这些 敏捷实践,它们提供的所有信息只有放在一个更大的场景中才会真正有用。前述的这些敏捷实践并不会直接关注团队新成员的不同的学习需求。你应该怎么做?答案 是:应用其他特定的实践来减少新团队成员的“启动时间”。 利用“提携(onboarding)策略”减少使用时间下面简要地列出了一些技术,在我的团队中,新员工们发现这些有助于帮助他们掌握必要的上下文场景,来理解其他敏捷实践提供的信息:
团队成员在不同项目间轮换不再困难敏捷实践强烈推崇“学习”,但是它们只关注减少“运行时间”,而非“启动时间”,因此对于团队的新成员来说,敏捷并不是非常有效。理解了新成员对学习的不同需求后,就可以使用一些特定的“提携策略”,直接解决问题。然后采用其他实践持续减少“启动时间”。 大多人在加入新公司时都会经历一些入职的程序。你在项目使用的那一套有多有效呢? 关于作者
Patrick Kua是ThoughtWorks公司的软件开发工程师、培训导师和教练。Patrick热情地为他所在的团队创造价值,对于那些尽情享受生活的人, Patrick也会热情对待。他相信,如果能把喜欢的事情和事业结合到一起,就会变得更好。在过去三年半的时间里,他指导、领导并参与了很多实践敏捷的团 队。 查看英文原文:A Leaner Start: Reducing Team Setup Times |
|