分布式的敏捷方式是我们这样的提供离岸服务的合作伙伴的DNA

当团队位于不同的地方时，过度强调交流的重要性也不为过。每天，我们都与在美国和印度的团队开展站立会议。在每日例会中，每个人讨论他/她昨天完成了什么，他/她接下去要做什么以及目前进展中遇到的困难是什么。

比起缺少沟通，我们认为频繁的交流更重要。

在一天结束后，每位成员发送给Scrum Master 一份每日状态总结报告。这样一来，Scrum Master就能知道分布在不同时区的成员的工作进程，然后指导成员们根据变化的情况和需求，迅速做出适当的应变。

博朗团队一般使用电话会议系统加上GoToMeeting这种可以屏幕共享的工具或者视频会议系统来进行交流。通过使用这种方法开展sprint计划会议和回顾会议十分顺畅有效。

由于各团队分布在不同的时区，找出一个适合各时区开展会议的时间十分重要。找到一个要让每个时区的成员充分满意的时间是不可能的，不过，可以找出一个每个人都能接受的时间范围。

团队成员必须接受时间上的弹性化。

加州比上海晚15个小时，班加罗尔比上海晚2.5个小时，所以我们选择在上海的上午11:30开会（那是加州的晚上8:30，班加罗尔的早上9点）。如此一来，在美国的团队必须牺牲每晚的时间，上海的团队需要延迟吃午饭的时间，但这是所有人都可以接受的会议时间。

一些来自上海的工程师会时不时地飞去加州，一般产品经理和Scrum Master都在加州。这些在加州的工程师半天在当地工作，剩下半天用来与当地的团队交流，那正好也是上海的工作时间。

在特定的重要的项目期进行偶尔的驻场工作，是一种可以同时满足两地需求的方法。

这是一种有效的被称作混合的方式。产品经理通过这种方式，对项目是否完成可以做出判定以及加以评论。

团队不仅仅开发新的功能，而且还提供生产支持，尤其是在黑色星期五和网络星期一期间。

我们发现，指定1至2位专门提供支持服务的工程师是最有效的。

当不需要参与支持工作的时候，他们会参与开发新功能，但当支持任务来临时，他们是唯一的资源。这种方法使得他们的同级专注于开发新功能，积累支持服务的知识与实践。

持续的整合对于在分布式团队的模型下控制代码质量来说很重要。

博朗有一支专业的团队，专门检查来自SVN的代码，整合代码并且每天进行自动化测试。

如果有问题发生了，他们会检查出问题是由谁引起的。每个人，无论身处何处，一旦接到来自支持团队的电话，都有责任尽快修复自己的代码，从而能尽快通过代码整合以及自动化测试的检测。由于团队位于三个不同的地方，检查代码质量成了很重要的环节。

知识库系统积累的团队知识包括：需求，发布计划，设计文档，专业知识，测试案例，测试账号，API文档及其他。

最佳的实践方案是将所有团队的知识全部集中在一个系统中。

知识库不单单对美国团队，中国团队以及印度团队开放，也应该对同级的功能团队开放。如此一来，它确保了每个人对系统的了解是一样的，同时它还缩短了新成员的学习曲线。