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