【IT168 技术文章】

    扩展到分布式团队

    项目启动以后，一开始只有7个人，两星期一迭代。项目从一开始就计划着要用到印度的一些人力，所以从第一个sprint开始就有两个印度开发人员进入了团队。他们来到客户现场参与开发，用了六周时间熟悉领域知识、用户代表和团队其他成员。

    建立团队伊始，就要决定如何协作。我们跟所有团队成员一起——也包括印度同事——组织了一个“规范和章程 ”活动。我们定下来一些实践方式，如怎样做结对、用哪些工具、质量目标、每天的核心工作时间等等。然后在Wiki上记录下来。整个团队有了共识，事情就好 办多了。一旦这些共识需要修改，比如在回顾会议上提出改进，这些实践就要在wiki上更新，这样有新人加入的时候，他们看到的总是最新内容。

    在前几个迭代里面，团队成功地构建、测试、验证了组成系统核心的用户故事。这让客户很满意，尤其是跟过去相比，我们的进度更快，而且客户对项目的方向也有掌控权。

    几个迭代以后，我们就扩展了项目：印度的开发人员返回本国，然后我们在印度和荷兰都增加了资源，这样变成了两个Scrum团队，每个团队5个开发人 员，共享同一个测试人员。过后又变成了三个团队，一共三个测试人员。每个团队都既有印度员工，又有荷兰员工。这种方式让项目保持了很高的生产率和工作质量。

    那我们是怎样异地协同工作的呢？首先，我们频繁使用Skype。我们都有网络摄像头、耳机、麦克风，还有个大屏幕。所以我们既能一对一开会，也能全 体参会。这些都用的是现成的东西和免费软件。没多花多少钱，只是用UPS保证断电的时候也能继续开Skype会议，这样提高了印度那边的网络联系能力。其 次，只有在同一个地方的人才做结对。也就是说印度的人跟印度的人结对，荷兰的人跟荷兰的人结对。经验告诉我们，不管现在有了哪些工具，结对编程所需的交互 协作还是需要两个人坐在一起的。

    最后，我们用ScrumWorks记录谁在做什么事情，记录Sprint的进度。因为我们是分布式团队，所以这个比白板要好得多。在跟产品负责人讨论产品backlog的时候，ScrumWorks也起了很大作用。

    在实施这种分布式模型的时候，我们也战胜了很多困难。例如，产品负责人不习惯说英语。按照Scrum的说法，计划会议分成两部分，在第一部分中，产 品负责人给团队讲述用户故事，并且设置优先级。因为这种语言障碍的存在，这一部分的会就只让荷兰团队参加了。第二部分通常是大家讨论具体任务，做估算。这 部分是跟印度团队一起用Skype来完成的，说的是英语，产品负责人不参加。我们还多花一些时间来沟通第一部分会议的内容。Sprint演示也只在荷兰进 行。完成以后，荷兰团队再写封内部简报，告知印度团队——也包括公司其他人——演示的结果。事实证明，这个内部简报深受欢迎。