<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_Dfmk8MPiEdmbOvqy4O0adg" name="workspace,_0cEmAMlgEdmt3adZL5Dmdw" guid="_Dfmk8MPiEdmbOvqy4O0adg" changeDate="2006-09-21T15:22:51.449-0400" version="1.0.0">
  <mainDescription>&lt;p align=&quot;left&quot;&gt;
    On small teams, shared workspaces may work fine, but you must coordinate activities between team members to avoid
    conflicts.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    A better approach is for each developer to have a reasonably private area for the development and testing of their work
    products. This workspace should be insulated&amp;nbsp;so that destabilizing or conflicting changes made by others do not
    interfere with&amp;nbsp;progress. However, it should&amp;nbsp;not be isolated to the extent that&amp;nbsp;the developer's work is
    unavailable to the team.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    In addition, insulated&amp;nbsp;workspaces can be created for each test phase, such as integration testing and system
    testing. This approach to workspaces provides several benefits &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup_basic/guidances/supportingmaterials/references,_9ToeIB83Edqsvps02rpOOg.html&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;&gt;[WIB04]&lt;/a&gt;:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;p&gt;
            Developers can develop, test, and debug software changes without being affected by others team
            members'&amp;nbsp;changes until they are ready. When ready, developers can update their insulated environments to
            test the latest changes from other developers.
        &lt;/p&gt;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;p&gt;
            With separate workspaces for integration and system testing, a team could use a methodology that ensures
            changes have passed integration testing before other developers get them, thereby minimizing the time spent
            solving integration problems.&amp;nbsp; For example, if two team members check in incompatible changes without
            realizing it, and both changes are immediately available to everyone on the team, all team members&amp;nbsp;might
            waste time trying to resolve the broken build. Conversely, if both changes must pass integration testing before
            being distributed to others, the problem could be found and fixed by one person with minimal disruption to the
            team.
        &lt;/p&gt;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;p&gt;
            By setting up an integration area to collect and build the latest changes, the team can integrate early and
            often. That is a well-known best practice for reducing overall cost and time to deliver software projects.
        &lt;/p&gt;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;p&gt;
            The system test area, which is used for preparing releases, is insulated from developers' ongoing changes and
            contains only configurations that have passed integration testing. This lets you control the content of the
            release while still enabling developers to continue working.
        &lt;/p&gt;
    &lt;/li&gt;
&lt;/ul&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>