Distributed agile software development in different regions)

Remote distributed software development (Distributed Software Development) Refers to the development process of the same software project by multiple teams located in different geographic locations. This word is frequently used in various technical media.

Different from outsourcing, remote distributed software development is built between two teams with equal relations. It is usually the collaboration between different branches or offices of a company. Most of them do not have a game contract relationship. Outsourcing means that a company entrusts the development of its software system to another company or organization. The two are the relationship between Party A and Party B of the contract.

However, whether it is remote distributed software development or outsourcing, one end of the customer can be called on-site, and the other end can be called off-site, they can be divided into three types based on geographical locations: On-shore (on the shore, in the same country or in the same time zone), near-shore (near shore, in close countries and regions) and off-shore (off-shore, usually at a time difference of more than 8 hours ). See the following table.

Offsite	On shore	Near shore	Off shore
Distributed Development	Beijing Office-Xi'an office	India branch-China Branch	Silicon Valley Corporation-China or India Branch
Outsourcing Development	A company in Beijing-another company in Guangzhou	A company in Tokyo-another company in Dalian	A European company-another Chinese company

Organization of distributed development in different regions

There are many ways to organize distributed development in different regions. One of the most common is that the company distributes the complete team structure in two locations, with each team having a local project manager, demand analyst, developer, and test. At the same time, the company sets the project owner role to be responsible for communication and coordination between the two locations.

Some companies place demand analysts at the on-site end, developers, testers, and project managers stay on the off-site side, while maintaining regular demand analysts locally. Some companies also place testers and developers in different places. On the one hand, developers, on the other hand, use the time difference to test at night and timely feedback the test results on the next day.

Various organizational models have different application scenarios. However, they all focus onMicro-managementThat is, to strengthen project management and coordination in the local team, rather than directly managing the activities in both locations at the same time. At the same time, we also try to ensure that both teams have auxiliary roles, such as project coordinators, local project managers, and demand analysts.

Basic principle: Do your best to communicate

Communication is the biggest problem for software development in different regions. As the distance between people increases, the communication efficiency will be greatly reduced (seeAlistair Cockburn'sArticle), And the communication cost will be greatly improved. Most of the time, the on-site team cannot pass the correct requirements to the off-site team, which directly leads to a decline in product quality.

In order to avoid this situation, we should try every means to improve the communication effect. For example, project managers and team members both need to understand the working status of others. One trick is to use your MSN or y! The name suffix indicates the requirement for your work. And can communicate with colleagues at any time through IM.

Communication frequency and value diagram, Vincent massol, 2004

Daily scheduled meetings will become an important way of communication. If the team has a small number of people, you can describe your situation and questions in the teleconference system in the form of standing meetings. If there are a large number of people, one alternative is that each team conducts daily meetings on its own, and the Project Manager and demand analysis personnel of a project can hold other meetings for coordination.

If the time difference between the two teams is large, for example, the time difference between China's Beijing time and US east time is 12-3 hours, it is very difficult to have a direct teleconference. If you have three teams in different time zones, it is often impossible to find a suitable time for any meeting. For international companies, it is common to have conferences in several regions, but this is not suitable for the entire development team. In this case, the development status email is very useful every day. After the daily development ends, the Project Manager or members will write a one-day Summary based on the team's situation and send it to the remote team.

Barriers to communication often occur among strangers. If developers in two places are unfamiliar with each other, you can consider posting photos of both parties on the wall to increase familiarity. If feasible, conduct visual meetings and face-to-face meetings. Minimize strangeness and improve communication performance.

No communication method is comparable to face-to-face communication. During off-site development, the semantic context and environment at the on-site end that communicates with customers are easily lost at the off-site end. If the situation permits, the company should set up a regular travel and rotation system. Let some of the team members go to the other end. Let's see the colleagues who work together to understand the customer's needs and feel different environments.

Improvements in the agile development process

In the general agile process, there will be an initial stage at which you can understand development requirements and develop release plans. To conduct such an activity, the best way is to let everyone go on a business trip to the on-site end to understand the needs and build consensus. This will be of great help for subsequent development. If the number or cost is not feasible, at least all demand analysts and project managers, coordinators, and some testers should be dispatched to participate. For an iteration-level plan, project managers and demand analysts in two locations should carry out the plan meeting and make a decision in advance.

In daily project management, card walls are only applicable to in-house development. In remote development, in order for each team to understand the team's tasks, at least a card wall needs to be set up in both development rooms and kept in sync. You can use online tools to help with project tracking, suchMingleOrTRACAre both applicable online tools and online wiki or shared knowledge base.

The project coordinator should formulate a sound communication plan and mechanism. For example, the daily meeting and daily development status emails mentioned above, the weekly requirement exchange plan, and the problem proposal and response mechanism. These should be formulated as team rules to follow and revised as the actual situation changes. There are not many exchanges, but insufficient ones.

A sharedCodeA version control system is required. For example, create a Svn in the company intranet and use it through VPN. The on-site and off-site teams can establish their own continuous integration environments, but must maintain the consistency of the system environment. Both developers should ensure that the submission is integrated before leaving the office every day. In this way, the remote team can be prevented from being terminated by the failed integration.

Basic agile time is essential, such as testing, especially functional testing. On-site QA should set the acceptance criteria when the requirements are determined. A well-described acceptance condition will be helpful to developers. This is especially useful when the on-site end cannot answer questions in a timely manner.

At the end of each iteration, try to arrange a demo meeting for synchronization between two locations. Let everyone see the results of this iteration in the teleconference. The summary and review after iteration should also be carried out in two places. If the number of people and conditions are not allowed, they can be carried out separately, and the review results and improvement methods can be reported to each other.

Participation of offshore teams

In multiple teams, on-site members may gain access to customers, and their right to speak may be magnified, making on-site users tend to send ordered messages, directly assign the requirements and development progress, while ignoring the background and context of the requirements. In this case, the team at the off-site team may conflict with each other, resulting in project failure.

The solution is to increase the engagement of the off-site team. For example, personnel rotation should be carried out in an institutional manner, so that team members at both ends can have contact with each other and be familiar with each other. Organize activities of the two teams on a regular basis. If they are all in the same time zone, you can consider conducting weekly learning lunch. When you can see each other's videos, you can have dinner and give lectures together. The lecture content can be any topic, such as project-related technical decisions.

Do not ignore any comments and suggestions from the offsite team. In many cases, they can provide comments on the project from the other side. Encourage the offsite team to make decisions and initiate discussions to increase their engagement.

The initial purpose of implementing remote development is to reduce labor and operation costs. Some cross-Time Zone remote development can also improve time utilization efficiency and achieve 24-hour global development. However, remote development brings about high communication and management costs. Improper handling will directly lead to project or product failures.

In recent years, with the development of domestic software companies, there will be more and more remote development projects. The process of globalization will also allow foreign companies to carry out more similar development. Remote development projects will gradually develop and become common. It can be imagined that after many years, if a company does not have a team for remote development, it will be amazing.

Transferred fromHttp://blog.nona.name/200706247. html