I have done this as part of a distributed XP team sharing source code and stories across 3 sites, each site being 12 hours apart (Seattle, Bournemouth UK, and Singapore).
We found that it helps to get everybody physically together at the start of the project to establish standards and to build relationships.
We also found that it helps to have "ambassadors" - shipping different people around between teams to spread knowledge and build trust.
We were lucky to have three sites that were each 12 hours apart - so we could have a stand-up meeting first-thing in the morning and last thing in the evening. We called them "hand-over meetings" and did them over video-conference between the incoming team and the outgoing team.
We also found remote pair-programming worked - between a local pair and a remote pair (i.e. four people) but that it's very intense and draining and best done only for short periods of time when it's really critical to see what other people are doing remotely.
Without unit testing, most Agile methodology isn't all that useful. Being Agile is about being light and being able to respond to change quickly - unit testing is one of the main things that makes that work. Without unit testing, you'll never have the freedom to make changes without risking major breakage.
As you add tests, I would document your code. This, again, is critical for being able to change things, even more so when the team is distributed.
Once that's done, you can start implementing other methodology over time. Personally, I would have the entire team do this, and get started on having daily/weekly stand-ups (which work fine with a distributed team via conference calls, etc), where everyone describes what they've tested, how they're progressing, etc.
Start with a Continuous Integration (automated build). I used CruiseControl.Net. I had two builds set up: 1) an automated build after every check-in and 2) a test build to build on demand.
You have to improve your communication for a start. Yes, engineering practices are important, but the key to agile is communication. Email is not the most effective tool to coordinate an agile project, but there are not shortage of tools out there that can help.
We have had great success with Skype (mostly pm, but also normal phone), and also with tools like MS SharedView it is possible to demo and even pair programme across sites.
Once you start to communicate effectively and feel like a team, the rest will follow. Agile is all about inspecting and adapting, so try things out and have fun with it. Start with the daily stand up and move on from there. Regular retrospectives will help you identify you problems and improve.
If you are into tools: To be able to do pair-programming or synchronous code reviews remotely, you could try the eclipse plugin Saros, which enables collaborative editing (including support for driver/observer roles and following users through the code).
(Disclaimer: Saros is a project of my working group at Freie Universität Berlin)
发布评论
评论（6）
我作为分布式 XP 团队的一员完成了这项工作，在 3 个站点共享源代码和故事，每个站点相隔 12 小时（西雅图、英国伯恩茅斯和新加坡）。
以下是我们所做的一些文章：
我们发现它有助于在项目开始时让每个人都聚集在一起以建立标准并建立关系。
我们还发现拥有“大使”很有帮助 - 在团队之间派遣不同的人员来传播知识并建立信任。
我们很幸运，拥有三个相隔 12 小时的地点，因此我们可以在早上第一件事和晚上最后一件事举行站立会议。我们将其称为“移交会议”，并通过新任团队和离任团队之间的视频会议进行。
我们还发现远程结对编程是有效的 - 在本地配对和远程配对（即四个人）之间进行，但这种方式非常紧张且耗费精力，并且最好只在非常关键的短时间内进行。看看其他人在远程做什么。
旁白：Kent Beck 对使用 Eclipse 进行远程配对的人的建议：http://www.triversinstitute。 org/blog/?p=584
I have done this as part of a distributed XP team sharing source code and stories across 3 sites, each site being 12 hours apart (Seattle, Bournemouth UK, and Singapore).
Here are some write-ups of what we did:
We found that it helps to get everybody physically together at the start of the project to establish standards and to build relationships.
We also found that it helps to have "ambassadors" - shipping different people around between teams to spread knowledge and build trust.
We were lucky to have three sites that were each 12 hours apart - so we could have a stand-up meeting first-thing in the morning and last thing in the evening. We called them "hand-over meetings" and did them over video-conference between the incoming team and the outgoing team.
We also found remote pair-programming worked - between a local pair and a remote pair (i.e. four people) but that it's very intense and draining and best done only for short periods of time when it's really critical to see what other people are doing remotely.
Aside: Kent Beck's Advice for people using Eclipse to remote pair: http://www.threeriversinstitute.org/blog/?p=584
好吧，考虑到您指定的内容，我的第一个想法是：
将单元测试添加到源代码中！
如果没有单元测试，大多数敏捷方法都没有那么有用。敏捷意味着轻松并能够快速响应变化 - 单元测试是实现这一目标的主要因素之一。如果没有单元测试，您将永远无法自由地进行更改而不冒重大破坏的风险。
当您添加测试时，我会记录您的代码。这对于改变事物的能力至关重要，尤其是在团队分散的情况下。
一旦完成，您就可以随着时间的推移开始实施其他方法。就我个人而言，我会让整个团队这样做，并开始进行每日/每周的站立会议（通过电话会议等方式与分布式团队很好地合作），每个人都描述他们测试的内容以及他们的测试结果进步等等。
这至少会让你走上正确的轨道......
Well, my first thought, given what you specified:
Add unit tests to your source code!
Without unit testing, most Agile methodology isn't all that useful. Being Agile is about being light and being able to respond to change quickly - unit testing is one of the main things that makes that work. Without unit testing, you'll never have the freedom to make changes without risking major breakage.
As you add tests, I would document your code. This, again, is critical for being able to change things, even more so when the team is distributed.
Once that's done, you can start implementing other methodology over time. Personally, I would have the entire team do this, and get started on having daily/weekly stand-ups (which work fine with a distributed team via conference calls, etc), where everyone describes what they've tested, how they're progressing, etc.
That will at least get you on the proper track...
快速浏览一下此博客：
Have a quick browse through this blog:
从持续集成（自动构建）开始。我使用 CruiseControl.Net。我设置了两个构建：1）每次签入后自动构建，2）按需构建的测试构建。
Start with a Continuous Integration (automated build). I used CruiseControl.Net. I had two builds set up: 1) an automated build after every check-in and 2) a test build to build on demand.
首先你必须改善你的沟通。是的，工程实践很重要，但敏捷的关键是沟通。电子邮件并不是协调敏捷项目的最有效工具，但并不缺乏可以提供帮助的工具。
我们在 Skype（主要是 pm，但也有普通电话）方面取得了巨大成功，并且通过 MS SharedView 等工具，可以进行演示，甚至可以跨站点配对程序。
一旦你开始有效沟通并感觉自己像一个团队，其余的事情就会水到渠成。敏捷就是检查和适应，所以尝试并享受其中的乐趣。从每日站会开始，然后继续。定期回顾将帮助您发现问题并进行改进。
You have to improve your communication for a start. Yes, engineering practices are important, but the key to agile is communication. Email is not the most effective tool to coordinate an agile project, but there are not shortage of tools out there that can help.
We have had great success with Skype (mostly pm, but also normal phone), and also with tools like MS SharedView it is possible to demo and even pair programme across sites.
Once you start to communicate effectively and feel like a team, the rest will follow. Agile is all about inspecting and adapting, so try things out and have fun with it. Start with the daily stand up and move on from there. Regular retrospectives will help you identify you problems and improve.
如果您喜欢工具：为了能够远程进行结对编程或同步代码审查，您可以尝试 eclipse 插件 Saros，它支持协作编辑（包括对驱动程序/观察者角色的支持以及通过代码跟踪用户）。
（免责声明：Saros 是我在柏林自由大学工作组的一个项目）
If you are into tools: To be able to do pair-programming or synchronous code reviews remotely, you could try the eclipse plugin Saros, which enables collaborative editing (including support for driver/observer roles and following users through the code).
(Disclaimer: Saros is a project of my working group at Freie Universität Berlin)