Most Read This Week
Working in a Distributed Development Team
Working in a Distributed Development Team
By: Gavin Brook
Nov. 11, 2003 12:00 AM
Think of the problems you encountered during your last project, then imagine the team spread across different floors or buildings, or even continents! The problems and pitfalls are greatly magnified to a point where development is severely hindered.
This is a typical distributed development team. The personnel involved in the project are unable to have direct face-toface communication. I will discuss common problems that can be encountered when working in this environment and talk about solutions that will greatly improve project development.
First, let's start by defining an example team. A global project has been proposed and the only problem is that some members of the team are based in the UK, and some in the U.S. This is not only multi-site it is also intercontinental, where time of day becomes a big issue. Figure 1 shows the organizational structure of our development team.
Figure 1: The organizational structure of the development team
The distribution of the staff means it is both difficult and expensive to all meet face-to-face, so solutions need to be found to facilitate a good working environment.
Definition and Design
Business is the driving force behind any project. A project is not even started unless there is benefit to the company, so it is up to the business to define what it actually wants and expects. Documentation is the core of a successful project. Without clearly defined goals and expectations, a project can begin to shift scope and flounder very early on in the development cycle.
For development to begin, a functional specification must be written. This defines the scope of a project - its goals and expectations. By writing this document in a nontechnical language, everybody involved in the project knows what is required. A poorly written specification means that there is a chance that somebody will misinterpret the requirements and unexpected results are assured. This not only causes friction between the business and development teams, but it can also jeopardize the project time line, as changes will inevitably need to be made.
The next document is the technical specification. This takes the functional specification and builds upon it, defining how the goals and expectations will be met. This is written in a language that clearly defines how the application will work, and is in enough detail for the development team to understand its implementation. By sitting down and thinking the requirements through, the development cycle can be defined and documented.
An important step to take after the creation of these two documents is sign off. The appropriate staff from key parties involved will review these documents and agree if they are a solid definition of the project. Without this sign-off step, when the project is further down the line and people's expectations have changed, chaos can ensue.
Let's take our global development team we talked about. Without solid documentation there is no standard, and each team will take a slightly different course. This can mean that the final outcome will be vastly different than what was initially envisaged. With good documentation, the two teams can work in unison and meet the project's requirements.
One of the most common things that has to be communicated is change. During the life cycle of the project, technical issues and changes in expectations arise that need to be accurately documented and communicated to everyone. There are many tools available that facilitate this. Personally, I use a very simple application that was developed in-house to track changes and issues. These applications can track the life cycle of all issues and distribute details to the appropriate people. This provides full auditing of the documentation and a history of changes.
I feel it's important to mention that no matter how helpful these tools are, without good data, they can become a hindrance. For the most part, changes should be written in a highlevel language so that everyone can easily understand what has changed. With technical reasons it is not always possible to break this down to easily understandable terms. Even so, I find it is good practice to always try to make it easy to read, as change affects everyone, including nontechnical staff.
The second line of communication is interdeveloper. In the case of our example team, the developers are split over two continents, in two different time zones. This means that the two teams may not be working at the same time, so good written communication is paramount. Not all projects are spread so far apart, but the principles apply equally to both.
A development plan is a definition of each part of an application, and a breakdown of how it is achieved. For instance, in the case of a FuseBox project, the application is broken down into a series of files containing displays, queries, and actions. A development plan for these types of projects will consist of a list of the application sections and their component files. Another benefit of producing a well-defined project plan is that it also gives a very good indication of the size of a project, and hence the development time.
From a clear development plan it is easy to define tasks and set priorities. With two or more separate teams, it is important that everyone knows what they need to do and when they need to have it done by. Collectively deciding task workloads and completion dates help plan out the whole application ahead of time. It is quite common for one team's work to depend on the other's. I find that leaving some less critical tasks unassigned allows developers to continue working in the event of any unexpected deviations from the plan. A complete plan allows the project to continue moving forward in the event of deviations or technical issues. I will discuss the former in the next section.
Time to Start
A FuseDoc is basically structured text, based on XML, that fully describes the file. The packet used in FuseDocs starts by defining the name of the file and what version of FuseDocs is being used (see Listing 1). Full details of XML are beyond the scope of this article, but there is a wealth of information available in books and on the Internet (for example, www.fusedoc.org). The next few lines in the packet describe the purpose of the file. It is written as though you are the page and you are describing your function. It has been designed this way so that everyone easily understands even though they are not the original developer.
The final section describes the inputs and outputs of the file. These are what are required to make that file function correctly within the application. By defining these, anyone can find out what is going into the file, and what is expected to be left out. A typical FuseBox application development cycle usually includes a cycle of just writing the FuseDocs for the application so that all the developers know how the application will flow. This is only a brief overview of FuseDocs, but there are many articles available about this and FuseBox.
For the open source route, a popular version control system is CVS. This can be downloaded freely (www.cvshome.org), and is a very comprehensive system. It's flexible and has more features than most people will need. The only real downside is that it is driven by a command line. This makes it quite cumbersome to use and unfamiliar to people used to graphical interfaces. There are other open source projects that provide graphical interfaces, and these can be quite varied in their operation. If you have the time, download a copy and try it out.
Commercial packages tend to have richer graphical interfaces, and can be much easier to use. PCVS is one such package that is commonly used. This provides client and Web interfaces, and has the added benefit of support. It is similar in functionality to CVS, and as such is quite comprehensive. Another package is SourceSafe. This is produced by Microsoft and is usually included in all of its development environment distributions.
All these packages have several things in common. They all support multiple users, archive changes to each version, and have the ability to mark a file "is locked". This means someone is working with the file and the software will not allow you to enter changes unless you are the person who locked it. This is particularly important when several people are working on a project. Once the correct changes have been made, the file is checked back and unlocked. Another major benefit of these systems is that they allow you to roll back to previous versions. This means if a mistake is made, the previous version from the archive can be retrieved. These benefits alone mean that version control should be a key part of any project.
There are several methods of communication available that enhance these best practices and allow a feeling of solidarity. E-mail is probably the most important, as it's available to almost everyone these days. Instant messaging can be extremely beneficial, especially if the teams are working at almost the same time. When used for business purposes it can save considerable amounts of time, as most people will answer an instant message more quickly than an email. Conferencing is another key practice that should be established, and is easily done through a variety of systems. The ability to talk to many people remotely is invaluable, allowing a "virtual" meeting. These systems can also come with whiteboard facilities, as well as application sharing. The latter allows you to demonstrate applications collectively, whereby everyone sees what you are doing with an application.
Whatever the structure of your team, these concepts apply to all. The key to success is communication. Without it, these projects are going to be severely hindered, or even doomed to failure.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads