IMPROVE DISTRIBUTED TEAM PRODUCTIVITY

Transcription

1 IMPROVE DISTRIBUTED TEAM PRODUCTIVITY BREAKTHROUGH EFFICIENCIES IN SOFTWARE DEVELOPMENT Software development organizations that rely on multisite teams face specific challenges that, when not anticipated or controlled, can expose projects to unacceptable levels of risk. This paper discusses how Borland StarTeam helps organizations manage the risk inherent in software development projects that use remote teams. A Borland White Paper February 2005

2 TABLE OF CONTENTS Introduction Infrastructure challenges facing remote teams The replication model for distributed teams Multisite repositories: duplication of costs and project management complexities The centralized repository approach Single repository challenges Managing risk using Borland StarTeam Improved communication, cooperation, and collaboration with the Borland StarTeam caching model....5 Conclusion About Borland

3 Introduction In the world of software development, true success happens when software delivery becomes a predictable, manageable, and repeatable process. By its very nature, however, software development is rife with changes and modification requests, fixes, and information breakdowns throughout the development lifecycle causing delays that lengthen the application development process. Shifting priorities demand rapid response times from the software development organization, creating constant pressure to refocus resources and deliver more in less time. Without a managed business process in place to anticipate and control uncertainties, organizations face unacceptable levels of risk that can negatively affect project time, budget, and asset security. The need to expand the available talent pool and achieve cost efficiencies has led to an increase in offshoring and outsourced software development. Thanks to a networked world, geographically dispersed software development teams can be linked together to work as a single unit. However, as the distances between locations grow and different time zones come into play, tight coordination of work distribution and information dissemination becomes more difficult. Add the challenge of communication and collaboration across geographic and cultural barriers, and the global team struggles to remain unified. To ensure that the collective development team is as effective as possible, a managed business process is required to simplify and reduce the risk in the software development process, regardless of the geographic complexities presented by remote teams. Borland StarTeam is the change and configuration management solution designed to address these challenges. Infrastructure challenges facing remote teams The goal of efficiency reigns supreme in software development: the more efficient the process, the less time must be spent reworking or reconciling differences, and the faster the build cycles. When accessing project assets from multiple geographic locations, development teams face the simultaneous challenges of working from the same code base and faithfully broadcasting recent changes to that code. Keeping these teams working in unison can be daunting in a fast-paced environment in which multiple revisions of software are being created. An unreliable transatlantic virtual private network (VPN) connection between sites can add to the complexity of interoffice communication especially when occasional outages can range from minutes to hours. Faced with these challenges, how can a company maximize remote team productivity? A common approach to this issue is to distribute multiple copies of the repository and synchronize them. Alternatively, a central repository can provide team members with costeffective access to information. Let s examine how both approaches bring particular benefits and risks to the software development lifecycle. The replication model for distributed teams The replication model provides distributed teams with access to information by establishing separate instances of identical source code repositories on geographically dispersed servers and scheduling regular intervals of synchronization between them. This model affords faster access to data, particularly large project files, from a local repository than when accessing the same information from a remote repository over a slower, long-distance network. 3

4 Distributed teams using separate, synchronized repositories also benefit from high accessibility. Because the local repository is working in isolation (except when synchronization occurs), it will not be affected by a lack of long-distance access caused by a poor or downed network connection. Multisite repositories: duplication of costs and project management complexities There are some risks, however, to implementing multisite replication. Organizations often discover serious trade-offs and costs that are not initially obvious. Administrative costs often dramatically increase, posing a threat to project budgets replicated sites mean replicated expenses. In addition to supplemental software site licenses, each remote site requires additional hardware that generates administration, backup, monitoring, and general maintenance expenses. The security of project assets also can become compromised when centralized control of user rights is scattered across multiple sites. Surprisingly, replication creates its own bandwidth and reliability issues. As more replicated repositories are deployed and project sizes grow, network demands increase because the instances of replication among the servers and the resulting synchronizations increase. Although the replication model is specifically designed to address performance issues, network bandwidth cannot keep up with constant file synchronization. Over time, this network bandwidth constraint puts the project lifecycle at risk. Replication also can create conditions that force costly project interruptions to resolve conflicts. For instance, two developers located at separate remote sites and working on the same file at the same time might introduce conflicting changes. Because they are using separate repositories, developers are unaware that they are creating a potential conflict until the files are merged. Sorting through data to resolve conflicts like this creates more work during synchronization and results in extended downtime when local repositories are not available, ultimately lengthening the development cycle. The centralized repository approach Alternatively, the centralized repository approach to managing and integrating software development across remote sites uses a single data warehouse to integrate all key lifecycle assets into a unified, centralized repository, leading to overall cost savings. With a single, centralized repository, the major expenses associated with infrastructure servers, high-capacity storage, high availability, and failover support are incurred only once. In addition, administrative expertise need not be duplicated at other sites. Process controls such as workflow rules are managed from one location to support project decisions and clearly assign responsibility. As in the previous example, if two developers at separate locations attempt to simultaneously work on the same code, project files can be locked from the central repository so that conflicts can be detected and resolved before updates are synchronized across the entire enterprise. These instances of dispute can be resolved as the work progresses rather than at the late stage of multisite synchronization. Centralized rules significantly decrease process interruptions and reduce the risk of project overruns. A centralized repository also simplifies critical administrative tasks such as security and backups. To help ensure that all project assets are securely stored, access, file modification, and user rights must be controlled according to predefined rules and from a single location, not multiple sites. Similarly, comprehensive backup procedures, restore processes, and disaster recovery plans are easier to manage when the infrastructure is streamlined through a centralized repository. 4

5 Single repository challenges At the same time, centralized repositories introduce two challenges for distributed teams: performance and accessibility. When attempting to access a single repository, remote teams often are constrained by network bandwidth. As more clients try to access the server over the same network path, network congestion increases and performance drops. In addition, the greater the distance between sites, the less reliable the network can become. If the network goes down at the main office, remote teams can lose productive time until it is up and running again. Both the multisite replication approach and the centralized repository approach have drawbacks. But what if there were a way to achieve the benefits of both? Managing risk using Borland StarTeam Now there is a way to increase performance and accessibility across dispersed sites and still maintain security over project assets. By imposing discipline and process to minimize conflicts, software configuration and change management mitigates risk and increases productivity. StarTeam is the center of application lifecycle management and touches every stage of software development. Each phase of the project lifecycle is interconnected, and StarTeam provides a centralized repository with the speed and convenience of multiple server sites that can introduce measurable, increased efficiencies and security to remotely dispersed software development teams. By improving the communication that affects workflows, StarTeam can provide the most efficient means to maintain control and security with a single repository. The StarTeam approach for supporting distributed teams focuses on centralized repositories and addresses performance and accessibility challenges using the StarTeamMPX Cache Agent feature. When users can retrieve information from a local cache, the burden of additional network traffic and server bottlenecks decreases, and users save time. Ideally suited for long-distance, bandwidth-constrained networks, the StarTeamMPX Cache Agent reduces reliance on constant access to the repository. One way to alleviate network traffic is to reduce the demand on the repository in terms of the number of inquiries and responses. Because it is critical for teams to access updates before they begin work on files, requests for the most up-to-date files or change requests can bombard the server, causing network slowdowns, particularly over long-distance connections. StarTeam is designed to address network congestion by pushing updated information to StarTeam clients before they request it. This diminishes both peak network traffic and server processing by reducing the number of simultaneous requests sent to the server. StarTeam receives and stores the pushed updates and securely encrypts the new files until they are retrieved by users. Any number of Cache Agents can be deployed throughout the enterprise, providing multiple places from which files can be checked out and enabling system scalability as projects grow. Improved communication, cooperation, and collaboration with the Borland StarTeam caching model The StarTeam caching model addresses the performance and accessibility challenges of centralized repositories and enables organizations to better manage the risks associated with distributed team development. First, remote team members can access files very quickly, because files are checked out from a local source. Regardless of how far the team is located from the centralized repository or how many files are checked out, performance is improved. Unproductive time once spent waiting for data transmittal is freed for project work. Second, network bandwidth is conserved because each newly updated file is pushed only once from the StarTeam server to each remote location. Therefore, repository bottlenecks are reduced because the same file does not need to be repeatedly requested, or pulled, over the longdistance network. 5

6 Third, by reducing unnecessary downtime, application build times are accelerated. Time savings accrued through faster accessibility, increased network bandwidth, and diminished demand on the server (through decreased client/server round trips) add up to significantly faster build times that reduce the end-to-end application lifecycle. Fourth, all files stored by the Cache Agent are encrypted to ensure security. Clients can access only those files for which they have permission, and files are decrypted only as they are streamed to the client. Last, employing the StarTeamMPX Cache Agent allows less long-distance network dependency. When users check out new files from a local Cache Agent, the long-distance network is not used. Consequently, the of time required to access the file (significantly higher when retrieving large files over long-distance networks) is dramatically reduced, which also minimizes the susceptibility of being affected by a network outage. About Borland The Borland Software Delivery Optimization vision and product strategy, proven solutions, and best practices are based on more than 21 years of experience in understanding enterprise software development issues. Borland offers a best-of-breed solution set that automates the project estimation and planning process, ensuring constructive collaboration among key stakeholders within the planning process, including corporate executives, line of business managers, and software managers. For more information on StarTeam, or to request a trial, please visit Conclusion Without a managed business process in place to anticipate and control uncertainties, organizations face unacceptable levels of risk that can negatively affect project time, budget, and asset security. StarTeam 2005 helps organizations that use multisite teams manage risk in software development projects. StarTeam enables software project teams to collaborate more efficiently by improving communication and speeds project lifecycles by simplifying infrastructure challenges with a single repository approach. The StarTeamMPX Cache Agent feature enables remote teams to access files more quickly, reducing development downtime and increasing project efficiency. StarTeam can save administrative time, reduce the need for additional infrastructure, improve communication, and boost security. Made in Borland Copyright 2005 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. All other marks are the property of their respective owners. Corporate Headquarters: 100 Enterprise Way, Scotts Valley, CA Offices in: Australia, Brazil, Canada, China, Czech Republic, Finland, France, Germany, Hong Kong, Hungary, India, Ireland, Italy, Japan, Korea, Mexico, the Netherlands, New Zealand, Russia, Singapore, Spain, Sweden, Taiwan, the United Kingdom, and the United States