<!-- RPW META DATA START --
<rpw name="MetaData" meta_value="anonymous" meta_name="element_type"></rpw>
<rpw name="MetaData" meta_value="guideline" meta_name="filetype"></rpw>
-- RPW META DATA END -->

<html>

<head>
<link rel="stylesheet" href="../../../rop.css" type="text/css">
<title>Guidelines:&nbsp;<rpw name="InsertPresentationName"></rpw></title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>


<body>

<rpw name="Warning"><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b><br></rpw>
<rpw name="Include">rpw/startBorder.rpw</rpw>
<rpw name="Warning"><br><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b></rpw>


<h1 class="banner"><a name="Top"></a>Guidelines:&nbsp;<rpw name="PresentationName">Adopting 
  XP Practices</rpw> <a name="XE_xp__adopting_practices"></a><a name="XE_adopting_practices__in_xp"></a></h1>
<p>XP is a set of synergistic practices. Because the practices depend upon each 
  other, people often wonder where they should start. In general, we recommend 
  that you stop and consciously decide to adopt as many of the XP practices as 
  possible.</p>
<p>However, if that induces too much stress, consider adopting the practices in 
  this order.</p>
<p><b><a href="../../../components/pc_xp_essentials/pc_xp_integration/co_continuous_integration.htm">Establish 
  a solid build process</a></b>. If you are not able to reliably build the software 
  you are working on, you can&8217;t really go further. Once you have a reliable 
  build process, make sure that you run whatever <a href="../../../components/pc_xp_essentials/pc_xp_testing/co_customer_tests.htm">tests</a> 
  you have prior to each checking.</p>
<p><b><a href="../../../components/pc_xp_essentials/pc_xp_programming/co_pair_program.htm">Pair 
  programming</a></b> is often a significantly different way of working for most 
  developers. It takes a little bit of time to get used to it, but as a team does, 
  they recognize that they are a much more powerful team because everyone&#8217;s 
  knowledge of the system grows rapidly. In addition, quality goes up because 
  there are two sets of eyes on all work as it is being done. When you adopt pair 
  programming, ideally you should have an <a href="../../../components/pc_xp_essentials/pc_xp_management/xp_open_workspace_guidelines.htm">open 
  workspace</a>.</p>
<p>As your team gets started with pair programming, you should adopt the <b><a href="../../../components/pc_xp_essentials/co_planning_game.htm">Planning 
  Game</a></b>. The Planning Game will help you identify good goals for your next 
  release, iteration, and day of work. At the end of your first iteration, you 
  will have a velocity that you can use to get a sense of how long it takes you 
  do do your work. As you do your planning, talk to your customer about producing 
  acceptance tests and being available to the team.</p>
<p>As you work together on your first iteration, try doing <a href="../../../components/pc_xp_essentials/co_test_driven_development.htm"><b>test-driven 
  development</b></a>. It will feel strange at first. If it doesn&#8217;t, you 
  are probably doing it wrong. Over time, it will feel like a more natural way 
  to develop software. Recognize that, at first, your velocity will be rather 
  low. This is a side effect of the learning process. Over the next few iterations 
  your speed will increase.</p>
<p>As you move forward, learn how to <a href="../../../components/pc_xp_essentials/pc_xp_programming/co_refactoring.htm"><b>refactor</b></a> 
  and start to practice <a href="../../../components/pc_xp_essentials/co_collective_code_ownership.htm"><b>collective 
  code ownership</b></a>. Often collective code ownership is a little scary at 
  first, but as you pair, you will notice that everyone is learning what it takes 
  to work with the system. When people volunteer for tasks, they either volunteer 
  only for what they know how to do or for things that they can get help on from 
  a partner.</p>
<p>Once you have a few iterations under your belt, you will be able to understand 
  how the process works and how the different practices interact and support each 
  other. Finally, listen to the feedback coming from your team. That feedback 
  is critical and can be used to improve and adapt the process to your team&#8217;s 
  particular needs and problems.</p>


<p><br/><br/></p>

<rpw name="Warning"><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b><br></rpw>
<rpw name="Include">rpw/endBorderOmRat.rpw</rpw>
<rpw name="Include">rpw/endBorder.rpw</rpw>
<rpw name="Warning"><br><b>!RPW INCLUDE! DO NOT MOVE/MODIFY !RPW INCLUDE!</b></rpw>

</body>

</html>