<?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.4/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-OuWRQbxXBGWox8SgcCr6sQ"
    name="xp_environment,3.754748120034442E-307" guid="-OuWRQbxXBGWox8SgcCr6sQ" changeDate="2005-12-06T07:25:25.664-0500">
  <mainDescription>&lt;a id=&quot;XE_xp__environment&quot; name=&quot;XE_xp__environment&quot;>&lt;/a>&lt;a id=&quot;XE_environment__in_xp&quot; name=&quot;XE_environment__in_xp&quot;>&lt;/a> &#xD;
&lt;p>&#xD;
    No process is an island. In other words, you can't expect to just take a process or process elements off a shelf and&#xD;
    use them without regard to their context.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    XP has certain key requirements of the &quot;environment&quot;; the physical, organizational, and business setting where it will&#xD;
    be applied.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Topics&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Physical&quot;>Physical Requirements&lt;/a> &#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                &lt;a href=&quot;#OpenWorkspace&quot;>Open Workspace&lt;/a>&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                &lt;a href=&quot;#Toolset&quot;>Uniform Toolset&lt;/a>&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                &lt;a href=&quot;#BuildMachine&quot;>Dedicated Build Machine&lt;/a>&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                &lt;a href=&quot;#VersionControl&quot;>Version Control Tool&lt;/a>&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Org&quot;>Organizational Requirements&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Business&quot;>Business Requirements&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Physical&quot; name=&quot;Physical&quot;>Physical Requirements&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;OpenWorkspace&quot; name=&quot;OpenWorkspace&quot;>Open Workspace&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    One key aspect of XP is a strong focus on communication. To communicate effectively, a team should have as few physical&#xD;
    barriers to each other as possible. The ideal XP programming environment is an open workspace filled with tables and&#xD;
    room for pairs of people to work together and maintain contact with their peers. For more details, see the &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../xp/guidances/guidelines/open_workspace.html&quot; guid=&quot;3.269440809144354E-305&quot;>open workspace guideline&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;Toolset&quot; name=&quot;Toolset&quot;>Uniform Toolset&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    XP works best when there are no artificial impediments to getting and giving help. If you have an open workspace with&#xD;
    five computers for production coding and each of them has a wildly different set of tools, some people will gravitate&#xD;
    to the machines that have the tools they like and feel uncomfortable moving to the machines that have unfamiliar tools.&#xD;
    Think about your own experiences. Do you feel hindered working in an unfamiliar IDE? How much does that impede you when&#xD;
    someone asks for your help. If, as a team, you adopt a uniform set of tools and keep your development machines&#xD;
    homogenous, you are making it far easier for people to give and receive help.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;BuildMachine&quot; name=&quot;BuildMachine&quot;>Dedicated Build Machine&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In XP, there are many different ways to do builds. However, the primary constraint is that all unit tests are run prior&#xD;
    to checking in any production code. In most situations, the easiest way to accomplish this is to have a dedicated build&#xD;
    machine. You can check in your code and trigger a build across the network or walk to the build machine and run the&#xD;
    build. Either way, having a dedicated machine gives you the advantage of having a common, pristine environment for your&#xD;
    builds.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;a id=&quot;VersionControl&quot; name=&quot;VersionControl&quot;>Version Control Tool&lt;/a>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    All software projects need version control tools; however, in XP we place a premium upon their usability. The ability&#xD;
    to be able to check out code without locking it is also valued. When a team writes pervasive unit tests and practices&#xD;
    collective code ownership, locking code for revision is often too pessimistic. It creates unncessary bottlenecks.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Org&quot; name=&quot;Org&quot;>Organizational Requirements&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Organizations adopting XP should be able to dedicate someone to act as the customer for each XP team. The customer role&#xD;
    in XP is critical. If the person who is acting as the customer has other responsibilities, it is best if those&#xD;
    responsibilities are subordinate to being available to the rest of the team.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In addition to having an available customer, organizations practicing XP should allow teams to be self-sufficient. In&#xD;
    organizations where many functions are supported by different groups (configuration management group, deployment group,&#xD;
    QA), the different functions can impede development if there are not mechanisms to allow each team to do what it takes&#xD;
    to finalize its iterations without waiting for other teams.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Business&quot; name=&quot;Business&quot;>Business Requirements&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    XP works best in situations where organizations can take advantage of variable scope. If a business creates a fixed&#xD;
    scope contract with a fixed end date, it can be hard to discern how long it really takes for a team to sustainably&#xD;
    develop good software.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    People in the organizations look at the schedule rather than the velocity data that XP produces. The result is all too&#xD;
    predictable. Software may be delivered on time, but it may also be buggy and a poor platform for future development. In&#xD;
    XP, we recognize that each team has a particular speed at which they can reliably develop software. That speed varies&#xD;
    from team to team. If a team is pushed faster than that speed, the results are often disasterous.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;br />&#xD;
    &lt;br />&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>