In my previous post, Remote start up company software development. I have received a suggestion that XDSD will be useful in my case. The next question is how to do it?
Add a comment
|
2 Answers
As XDSD site explains, the methodology helps you to achieve high quality of developed software, when all team members are located remotely, without any central office. Actually, this is how the majority of open source products are being developed. There are four principles of XDSD:
Everyone gets paid for verified deliverables. The most difficult to achieve, especially when talking about management and architecture/design tasks. How exactly you can achieve this in your project depends on the tools you have in hands and your management skills.
Defects are planned and don't block delivery. Instead of "delivering bug-free software" (which is a big mistake in software development) you should plan how many bugs your product will have, discover them all, and fix them.
Quality-of-code metrics are CI gate conditions. Quality control has to be pro-active, instead of re-active. You should technically (!) disable an ability to add low quality code to the repository. How exactly you can do this - depends on available tools and instruments.
VCS commits to trunk are prohibited. Main stream of source code in repository (called
trunk) should be in read-only mode for everybody, except one person, who is responsible for quality control.
There is a strong believe that these principles lead to higher quality, when the team is "extremely distributed". There is not enough experimental data so far to prove the concept. The methodology is still in R&D phase, your contribution will be very welcome ([email protected]).
OK there are a few things which will help with this.
Firstly you need a central source control system which can be accessed from anywhere. This along with some online documentation (which could be in the source control system) should vie a new team member enough information to get going. Githib, unfuddle, et al are great at this.
You'll need clear channels of communication, I have worked with a distributed team which was constantly on a private irc channel. A lot of conversations can go on in here allowing people to read up on what has been said. Instant messenger should be discouraged in many cases as the information will be lost. If you can set up a bot to record what is said in the IRC channel for people who are not online even better.
A daily 'stand up' is also very important, this should be done using voice (or video) calls, it allows for the team to understand what each other are up to and how they are feeling it is vital for team cohesiveness. People who are not present will start to be forgotten about. This may be tricky if you have many time zones but even if it is last thing in the day for some people and early morning for others a quick chance to talk really helps.
You will also need online bug tracking but often the same tools which host the source can do this.
