敏捷实践关注运行时间，而非启动时间

    “学习”对于每一种敏捷方法论都是不可分割的一部分。其中大多数都关注于短期的反馈环、进行自我反省以及强调持续改进。

    但是，每个新进入项目的人在进入项目一段时间后，对学习的需求会变得大相径庭。

    对于新的团队成员来说，消化信息的过程通常会带来更多的问题。像在Scrum站立会议上说的“我昨天做了……”这种话，会触发新人更多的问题，比如“他们在说什么，这与我所了解的又有什么联系呢？”结对编程的效果也会有变化，如果结对的那个新人对整个项目有个大致的了解，效果会好些；但如果只是面对一个接一个的UserStory，效果就会很差，毕竟此时窥一斑而难以见全豹。我曾经见到过，当面对大量琐碎的信息碎片，也没有一条明确的线索将它们串连到一起时，很多团队的新员工都会感到很沮丧。

    新人需要学习的主要内容是关于项目的概貌（largercontext）。他们要找到应该了解的知识，逐步理解领域相关的词汇表，并融入团队及其文化。项目越复杂，加入的人数越多，这个阶段就需要持续更长的时间。

    了解了项目的概况之后，就要学习一些更加深入的知识了。有了概况中包含的信息，其他信息就变得更容易被接受了。每日站立会议、结对编程、测试驱动开发等这些敏捷实践，它们提供的所有信息只有放在一个更大的场景中才会真正有用。前述的这些敏捷实践并不会直接关注团队新成员的不同的学习需求。你应该怎么做？答案是：应用其他特定的实践来减少新团队成员的“启动时间”。
   
    利用“提携(onboarding)策略”减少使用时间

    下面简要地列出了一些技术，在我的团队中，新员工们发现这些有助于帮助他们掌握必要的上下文场景，来理解其他敏捷实践提供的信息：

    ◆预备Email

    在新员工加入前，给他们发一封Email，解释一下项目的背景，这样他们在正式工作前就可以先阅读一些资料，或者锻炼并学习与项目相关的技能和知识。

    ◆业务问题的大视野

    开一个会，告诉新成员项目背后的价值以及驱动力。让他们一点点地熟悉领域相关的术语，并把他们的工作放在一个更大的上下文环境中。

    ◆具化架构

    图表可以很好地用于将琐碎的概念放到更大的概念中。以此来将讨论聚焦在汇集知识和分析这些知识如何相互关联上面。

    ◆项目问题透明

    坦诚地公布团队已知的需要改进的领域。要关注如何提高、并制定计划，而不是一味地看到问题有多糟糕。

    ◆细小的任务

    将一件庞杂的工作划分为大量细小的任务，以便新的团队成员不需要很多麻烦就能理解项目团队成员正在做些什么。确保每项任务都能在相对独立的条件下完成。

    ◆互相学习

    让角色相似的人们一同工作，来分享他们学到的新知识和任何可能对其他人有用的技巧。这类会议应该集中在技能的学习与共享上。

    ◆从学生到老师

    尝试让新成员去帮助其他的团队成员。让新成员向其他的团队成员解释概念，这样既能巩固他们所学的知识，又能提高他们的思考方法。

    ◆尊重个人的差异

    让学习的过程适合每个人。使用图表、文档、CRC卡或者任何事物，帮助他们更好地构建出项目的整体图景来。

    ◆放手一搏

    给予每个成员以足够的空间，让他们在一个安全的环境里犯错。有些教训如果是自己学习的，印象将更加深刻。

    团队成员在不同项目间轮换不再困难

    敏捷实践强烈推崇“学习”，但是它们只关注减少“运行时间”，而非“启动时间”，因此对于团队的新成员来说，敏捷并不是非常有效。理解了新成员对学习的不同需求后，就可以使用一些特定的“提携策略”，直接解决问题。然后采用其他实践持续减少“启动时间”。

    大多人在加入新公司时都会经历一些入职的程序。你在项目使用的那一套有多有效呢？